On Fri, 2016-06-03 at 00:17 -0400, Dave Garrett wrote: > Allrighty then; time to dust off and rebase an old changeset I was > fiddling with last year on this topic: > https://github.com/davegarrett/tls13-spec/commit/058ff1518508b094b8c9 > f1bd4096be9393f20076 > (I cleaned up a bit when rebasing, but it probably needs some work; > was just a WIP branch, never a PR) > This was the result of prior discussions on-list about TLS version > intolerance. The gist of the proposal: > 1) Freeze all the various version number fields. > 2) Send a list of all supported versions in an extension. (version > IDs converted to 16-bit ints instead of 8-bit pairs) > 3) Use short (1 or 2 value, based on hello version) predefined lists > for hellos from old clients not sending the extension. > 4) Compare lists to find highest overlap, avoiding guesswork or > problems with noncontinuous lists. > 5) Forget the old mess of version intolerance existed.
I had originally similar thoughts, but doesn't that introduce a 4th version negotiation mechanism? We already have the current version negotiation mechanism(1), the extension mechanism(2), the ciphersuite negotiation(3), and we are getting a new version negotiation mechanism based on extensions(4). Note that (1),(2) and (3) aren't getting away if we introduce (4). The code will stay in implementations for more than a decade. A simpler proposal is: Consider TLS 1.3 as a feature, and negotiate it using an empty extension. If the extension is present a server assumes TLS 1.3. regards, Nikos _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
