I'm a big fan of the idea of a very strict qualification suite, as well, to try to head off some of these problems before (faulty) implementations proliferate.
Hackathon? Kyle On Jun 7, 2016 2:00 AM, "Peter Gutmann" <pgut...@cs.auckland.ac.nz> wrote: > Dave Garrett <davemgarr...@gmail.com> writes: > > >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. > > I think that's the main contribution of a new mechanism, it doesn't really > matter whether it's communicated as a single value, a list, or interpretive > dance, the main thing is that there needs to be a single location where the > version is given (not multiple locations that can disagree with each other > as > for TLS < 1.3), and the spec should include a pseudocode algorithm for > dealing > with the version data rather than just "implementations should accept > things > that look about right". > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
