On Monday, June 06, 2016 06:48:20 am Hubert Kario wrote: > What makes you think that a new version negotiation that works more or > less in the same way will _not_ be implemented incorrectly?
The list-based extension doesn't work in quite the same way. The current mechanism compares two values and picks the lower one. This new mechanism compares two lists and picks the highest mutually listed. Also note that I wish to officially drop any meaning from the version IDs such that we're using an arbitrary 16-bit serial number rather than two 8-bit major & minor numbers. The new supports discontinuous lists, e.g. support of 1.0, 1.2, & 1.4, but not 1.1 or 1.3, without risking accidental negotiation of a lower version that isn't desired. (if 1.3 is eventually declared less ideal than 1.2 or 1.4 due to some unforeseen problem, this gives us a safe mitigation, and it extends to arbitrary future scenarios) Also, as with any new system, we now have the ability to loudly stress to TLS 1.3+ implementers to not screw it up and test for future-proofing this time around. At a minimum, implementations will not be able to use the exact same code to negotiate in both systems and would have to go out of there way to add intolerance stupidly, rather than stumble into it stupidly again. Just sticking a new field in an extension lets implementers route it into the same code and risk the same mistakes; adding a bit of complexity here is an unfortunate cost of fixing this mess. Just adding a new _empty_ extension, as was more recently proposed, is something I think could also work ok. Again, if we're more likely to get consensus on that, I think it's viable too. The idea of a compliance test suite has come up before and I will again say: YES, PLEASE! I certainly don't claim anything proposed here is perfect, but nothing is or will be in a 20 year old protocol. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
