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