Re: [TLS] TLS 1.2 hash agility

>>    - There is a potential performance benefit on the client
>>      side: if the client requires better algorithms than the
>>      defaults and the server either doesn't reply with the
>>      extension, or if the list doesn't contain an acceptable
>>      algorithm, then the client can abort the connection
>>      immediately after parsing the ServerHello message.  It
>>      can avoid the need to parse the Certificate message to
>>      determine how it was signed.
> 
> As you indicated in your previous message, this is not in fact
> an advantage.

It is a different benefit (for the client, not the server), so
yes it is an advantage.

>> The only counter argument I could find is that the server's list
>> of acceptable algorithms might be different in different places.
> 
> And yet, I mentioned several other reasons in my previous message:
> 
> - Locality of information.

For CertificateRequest, yes, but by putting it there, the client
has to parse the Certificate to figure out if it is signed with
an acceptable algorithm.  If the server's list of acceptable
algorithms was passed in a ServerHello extension, the client
would be able to determine if it should even bother.  (That is
the benefit I referred to above.)

> - It works even if the client does not offer the extension.

A client that does not offer the extension doesn't support any
advanced algorithms.  If it did, why wouldn't it tell the server?

>> Even if so, the client can benefit from knowing the server's
>> certificate signature algorithms up front, so having the server
>> respond with the extension is useful.
> 
> I don't see any significant value in this.

In the end, it is your specification, so all I can do is present
my point of view....

Mike

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls