Subject: Re: [TLS] Server Signature Algorithms

From: Michael Gray <[email-masked]>
Date: Mon, 2 Nov 2009 06:50:02 +1000

"Michael D'Errico" <[email-masked]> wrote:

> There are now at least 3 instances where a TLS client needs to know the
> server's list of supported signature algorithms:
>
>     1. to compute the signature for the CertificateVerify message
>     2. to compute the hash of the handshake messages in (1) without
>        having to hold onto all of the messages
>     3. to compute hashes for the proposed cached information extension
>
> Rather than duplicate the list for each of these and any future needs,
> it makes sense to send it once in a server hello extension.
>
> The simplest option would be to use the existing signature algorithms
> extension and make it symmetrical.  But if there is a deployed client
> out there that aborts a connection if it receives a signature algorithm
> extension, then a secondary option would be to create a new server-
> signature-algorithms extension which is identical in structure to the
> existing extension.
>
> I would add that when the server sends its list of algorithms in the
> extension, then it MUST NOT send a different list in the certificate
> request message; in fact it SHOULD send an empty list.  TLS 1.3 can
> decide whether to eliminate the list from CertificateRequest.

Currently our toolkit when operating as a client will abort the handshake
on this condition due to RFC 5246 in 7.4.1.4.1 saying: “Servers MUST NOT
send this extension”.

We could change our code to optionally (e.g. a non strict mode) accept
receiving the extension from a TLS Server as that would be IMHO relatively
harmless.  The problem I see would be if we enabled our Server side code to
optionally send this extension, that would open the door for existing TLS
Clients to abort the handshake.  We have no idea which Client (vendor) type
may be involved in a handshake and what revision of the implementation in
this area they might support i.e., there is no way for the Client to
indicate that it will tolerate the Server sending the extension.  IMHO It
is unfortunate version information is not included in each extension.  So
while I agree that this sounds a good move I would be concerned as to the
impact on system availability should any Server now be configured to start
sending this extension.  IMHO I think the horse might have already bolted
in this case :-(

Mick

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 01 Nov 2009 13:34:08 -0800

So instead of changing the existing signature_algorithms extension,
nothing would break by creating a new server_signature_algorithms
extension.  Client support would be advertised by sending an empty
extension to the server.  The server would show support by replying
with its list.

In this case, the server can leave the signature algorithms list in
CertificateRequest empty since it knows the client accepted its list
in the server hello extension.  The server MUST NOT send a different
list in CertificateRequest, since the client may have used the
information to start computing the hash for CertificateVerify and
thrown away the previous handshake messages.

Mike

---

From: Martin Rex <[email-masked]>
Date: Mon, 2 Nov 2009 17:56:36 +0100 (MET)

Michael Gray wrote:
> on this condition due to RFC 5246 in 7.4.1.4.1 saying: “Servers
> MUST NOT send this extension”.

That isn't strict, that is anal.

It would safe to entirely ignore an extension that should not be present,
and this is what the general rule _implies_:

   "Be liberal in what you accept, be conservative in what you send out."

-Martin

---

From: Wan-Teh Chang <[email-masked]>
Date: Mon, 2 Nov 2009 10:02:41 -0800

> extension to the server.  The server would show support by replying

Michael: I agree this would be the safest solution which
eliminates the concern of breaking some TLS 1.2 implementation,
at the cost of adding a new TLS extension.

This would be an example of a "server-oriented" extension
described in Sec. 2.3, page 7 of RFC 4366.

Nikos: GnuTLS is one of the first TLS 1.2 implementations.
How does GnuTLS deal with this issue now?  Does it compute
hashes of all the hash algorithms it supports on the handshake
messages, or does it buffer the handshake messages until
the hash algorithm has been selected?

Wan-Teh

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 02 Nov 2009 21:11:11 +0200

> the hash algorithm has been selected?

This part was only recently implemented. The current behavior is to not
buffer messages in order to keep common code base for all TLS versions
(none of the SSL, or TLS protocols so far required such buffering).
What we do is hash all the handshake messages with SHA-1 and SHA-256 and
hope that those will be among the choices of the server.

This works but it is a time bomb. Once one sets up a server that
requests some signature algorithm not in this set we do not complete
handshake.

regards,
Nikos