Re: [TLS] New TLS version negotiation mechanism extension

[Dave Garrett <[e-mail]>]

On Sunday, March 08, 2015 01:39:47 pm Dave Garrett wrote:
> A basic proposal for a new TLS version negotiation mechanism for TLS 1.3+. It'll be needed to handle draft implementations, if desired, and I think it might just be wanted for all negotiation. TLS 1.3 version intolerance is currently surveyed to be in the ~1.5% range [1]. The simplest method is to do so via a new mandatory extension, as has been suggested by people before.

On Tuesday, March 10, 2015 10:08:27 am Brian Smith wrote:
> I agree that that seems like the best way forward.
[...]
> Anyway, I support your proposal, if it is simplified.

On Friday, March 27, 2015 03:46:05 pm Xiaoyin Liu wrote:
> I support this version negotiation proposal, but I prefer the old one, i.e. listing all supported TLS versions.

Ok, I've written out the bulk of main changes that would be needed to do both potential new methods:
#1: an extension providing full lists of version support which the server find the highest common value of
#2: an extension using basically the same method as previously, but bumping the value to the extension

For others on the mailing list, the reasons for this are the irritatingly high rate of TLS 1.3+ version intolerance that would seriously hamper adoption of a new version, as well as the desire to negotiate draft versions to get widespread testing (similar to how HTTP/2 did things).

My initial idea was for method #1, however upon scrutiny by Brian and myself, I decided to work on fleshing out #2. The potential complexity did sound like a larger risk. After doing so, I think that whilst #2 ~sounds~ simpler because it's very similar to the current negotiation method, in reality, #1 is far more straightforward and has fewer potential pitfalls in implementing.

I have two WIP branches, one for each method:
#1: https://github.com/davegarrett/tls13-spec/compare/patch-3...davegarrett:EVN
#2: https://github.com/davegarrett/tls13-spec/compare/patch-3...davegarrett:NVN

(compare links because patch-3/PR#107 is approved, but not yet merged into trunk)

Comparing between the two branches, the main difference is that whilst the list method has more info for the server to deal with, it's simpler to handle and explain in fewer words more clearly. With the simple proposed value, the server has to pick the highest version it supports less than the proposed version. When throwing draft versions into the mix, a server needs to make sure not to offer an draft version if the client did not offer support for one. (alternatively we could have another extension for drafts, but that's more complicated overall and I really want a single method that gets properly tested prior to release) In enumerating the pitfalls I see, the errors that need to checked for in the list method can be explained more simply. I can lay out the entire list based algorithm in a handful of lines of pseudocode, whereas for the simple proposed value method it's a sprinkling of "MUST" instructions throughout the spec. This completely new method also ensures that nobody just uses whatever old algorithm they had with potentially problematic changes to handle the new. Note, that while I say "completely new", I mean new to TLS versioning. It's similar to ALPN in concept.

Note that in the current version of #2 (NVN branch) I'm recycling the hello version to use as a min_version to add the ability for servers to never even offer to downgrade further than the client wants. This could be dropped to simplify things, though I don't think it's worth it. The draft of #1 (EVN branch) does not need anything like that to have the server pick a viable version every time (if one exists), and can also handle non-continuous supported version lists easily. (e.g. support 1.2 and 1.4 but not 1.3, and have a 1.4 server negotiate 1.2 instead of offer 1.3 and fail) In that case, the hello version is frozen. Both branches rename the ServerHello version to negotiated_version to make it clear what it actually means. (with PR #107, the record layer version is also frozen)

So, now I think #1 is the way forward, after giving #2 a shot. Still a WIP, but any feedback would be greatly appreciated.


Dave