On Tuesday 07 June 2016 10:22:20 Kyle Rose wrote: > 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?
I have two approaches I'm working on, they are missing a nice interface though. The first one is: https://github.com/tomato42/tlsfuzzer and aims to be a comprehensive test suite and the other one, simpler (aimed only at detecting incompatibilities) is cscan that lives here: https://github.com/tomato42/cipherscan/tree/cscan-2 Both require just python and have minimal dependencies. > 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 -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
