Re: [TLS] New TLS version negotiation mechanism, take 2

[Dave Garrett <[e-mail]>]

On Friday, March 27, 2015 03:46:05 pm Xiaoyin Liu wrote:
> > > > + Only one extension with one fixed length value
> > > 
> > > But here you lose the benefit, as the client can't inform the server
> > > that it supports multiple TLS 1.3 drafts if the field is of fixed
> > > length.
> > 
> > Yes. If we'd like to go back to the list idea, I'm not wholly against
> > it.
> > 
> > In this mechanism, the client may support only one draft, but the
> > server may support multiple just fine.
>
> I support the list idea. Besides being able to support draft versions,
> there is another benefit. If, for instance, after TLS 1.5 is released,
> someone finds a weakness that only exists in TLS 1.4, which makes TLS 1.4
> insecure. But TLS 1.3 and TLS 1.5 are still secure to use, and TLS 1.5 is
> better than TLS 1.3. Then with this version negotiation mechanism,
> clients can very easily mitigate the TLS 1.4 vulnerability by removing
> TLS 1.4 from the supported version list. But with the current version
> negotiation, clients would have to either set highest client version to
> TLS 1.3 or set to TLS 1.5 but fallback to TLS 1.3 if servers try to
> negotiate TLS 1.4.
>
>I know this is quite unlikely to happen, but I don't think we can safely
>assume this will never happen.
>
>Also this mechanism enables implementations to skip versions for whatever
>reasons, such as that some versions are not widely negotiated, like TLS
>1.1 today.

This was my exact reasoning for my first proposal:
https://www.ietf.org/mail-archive/web/tls/current/msg15441.html

Brian Smith posted a detailed review here:
https://www.ietf.org/mail-archive/web/tls/current/msg15470.html

His argument against the list method is that:
1) The client should not be announcing support for old versions that may be weaker than its highest supported version, and that this constitutes an unnecessary security risk.
2) The added complexity of negotiating with potentially non-continuous version support lists is not worth the risk of implementors botching it.

Personally, every time the general argument that announcing specific versions of something gives an attacker too much information, I'm not really convinced. That said, I don't really oppose limiting announced information, either.

I don't think the added complexity would make things significantly more likely to break, but I don't dispute that it's a valid argument.

The complexity differences between the current proposal and a list based proposal are that:
a) The ClientHello version field would be frozen and meaningless in a list negotiation, whereas the current proposal recycles it in a manner that avoids clients offering TLS 1.2 without supporting it.
b) List negotiation would vary the size of the extension. An arbitrary list size limit would not be a bad idea. It would nonetheless increase bandwidth usage slightly.
c) Clients will undoubtedly not all send the lists ordered properly and servers will have to sort through it to hunt for a best match to negotiate.
d) On the plus side, a list based negotiation would not be checking any version ranges anymore. It would be only looking for the highest overlapping value between the client and server's lists.

I would also add the argument that TLS should not make it more than a few major versions into the future. (DTLS is another story, and there may not even be a need for a new version negotiation mechanism there) TCP needs to be replaced with something that is reliable, fast, and secure. Something QUIC based will probably be the start, eventually. Based on that logic, super future-proofing TLS is counter-productive.

Honestly, I think the list based route could be done cleaner, though. Yeah, we might not really need things generalized this much, and non-continuous version support may not in demand, but it might work better. I'm not really opposed to the single max version route either.

That said, as I think about and work on the current WIP changeset, I am noting pitfalls that need mentioning that I think can be side-stepped with a list based solution (which might end up with its own, of course :p ).


Dave