Re: [TLS] TLS 1.2 hash agility

>> This has two advantages over the extension:
>> 1. It works even if the client doesn't offer the extension.
> 
> You could make the extension mandatory for TLS 1.2 or later.  Even
> if it is not mandatory, if the client does not specify the extension,
> there are default capabilities that can be assumed.  If the server
> requires that the client authenticate with a certificate, and also
> that the default algorithms are unacceptable, it can abort the
> session immediately after ClientHello is received, which is an
> added performance benefit.

I realized half way through an all-day meeting that this performance
benefit does not depend on where you put the server's list of
signature algorithms; so it is not a valid argument for the server
extension.

>> 2. It puts the parameters for the certificate in the same place
>>    as the request for it.
> 
> While I agree that this is in general good design, my opinion is
> that the other factors outweigh it.  Gentlemen can disagree.

I spent the rest of the meeting trying to come up with other valid
reasons for using the extension to advertise the server's
capabilities, versus putting them in the CertificateRequest.  The
only thing I could come up with is that putting the list of
signature algorithms in the CertificateRequest is a change to the
format of that message, so it requires version-specific processing,
whereas if you use the server extension, the format of Certificate
Request is the same as previous TLS versions.

Mike

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