Re: [TLS] Server Signature Algorithms

[Michael Gray <mickgray at au1.ibm.com>]

"Michael D'Errico" <mike-list at pobox.com> 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
> TLS at ietf.org
> https://www.ietf.org/mailman/listinfo/tls