Re: [TLS] TLS 1.2 hash agility
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TLS] TLS 1.2 hash agility



At Thu, 27 Sep 2007 07:18:38 -0700,
Mike wrote:
> 
> > 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.)

No, I don't agree with this claim about the purpose of the
extension mechanism. Some things are appropriately done
in extensions, some should be part of the main protocol.
It's a *bad* idea to move as much as possible into extensions.




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


> 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.
- It works even if the client does not offer the extension.


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

-Ekr



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




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.