Re: [TLS] Server Signature Algorithms

[Michael D'Errico <[e-mail]>]

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



Michael Gray wrote:
> "Michael D'Errico" <[e-mail]> 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