Re: [TLS] TLS 1.2 hash agility

[Mike <mike-list at pobox.com>]

> > At the risk of being redundant, I assert that making this extension
> > symmetric and allowing the server to respond with its own list of
> > supported algorithms, is better than having the server send its
> > list every place where it is needed (now and in the future).  Send
> > it once in ServerHello, and use it where it's needed.
>
> There is only one place where it's needed: CertificateRequest.

That is true at the moment, but if a future addition to the protocol
also requires a signature, you will need to send the list twice.

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

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

Mike

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