Re: [TLS] TLS 1.2 hash agility

> I spent [a lot of time] 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.

I came up with a few more ideas, unfortunately at the expense of
not being able to sleep:

   - The extension mechanism was added to TLS to enable the
     addition of functionality without needing to constantly
     change handshake message formats; so I would argue that
     any functionality that -can- be added using an extension
     -should- use an extension instead of modifying messages.
     (Yes, Signature had to change so messages will be
     different, but limiting the damage is a worthy goal.)

   - 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.

The only counter argument I could find is that the server's list
of acceptable algorithms might be different in different places.
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.  Then I would suggest
that signature_algorithms in CertificateRequest could be empty,
which would mean, "use the same list given in the server's
signature algorithms extension."

Mike

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