It’s not that the existing version negotiation mechanism doesn’t work; the problem is that implementers got it wrong. Similarly, implementers can mess up the new negotiation mechanism. Especially since we have to support it at the same time as the old one.
Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: Friday, June 3, 2016 6:40 AM To: Dave Garrett <davemgarr...@gmail.com> Cc: tls@ietf.org Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] My opinion on this hasn't really changed since the last time. This seems like it's more complicated and it's not clear to me why it won't lead to exactly the same version intolerance problem in future. -Ekr On Thu, Jun 2, 2016 at 9:17 PM, Dave Garrett <davemgarr...@gmail.com<mailto:davemgarr...@gmail.com>> 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/058ff1518508b094b8c9f1bd4096be9393f20076 (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. Do we want to consider scrapping the old version negotiation method again? Dave
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
