On Tuesday 07 June 2016 17:36:01 Yoav Nir wrote: > I’m not sure this helps. > > I’ve never installed a server that is version intolerant. TLS stacks > from OpenSSL, Microsoft,
are you sure about that Microsoft part? there is quite a long thread on the filezilla forums about TLS version tolerance in IIS: https://forum.filezilla-project.org/viewtopic.php?f=2&t=27898 > Java, and most any implementation we can > name have been version tolerant forever. tls version intolerance is only one thing, then we have: * old-ish Java is intolerant of 2048 bit DH key share * many versions of OpenSSL are intolerant to very big Client Hello messages (over ~1500 bytes) * old-ish IIS is intolerant to placing RC4 ciphersuites very low in order and so on... > Certainly none of us can > name any implementation that at any point had a version out that was > tolerant (or implementing) TLS 1.2 but intolerant of TLS 1.3. I don't know for sure what ebay.com is running, but it certainly is TLS 1.3 intolerant tls_prober[1] identifies it at Microsoft IIS 7.5 > And these are the same implementations we’re likely to participate in > a bakeoff or run the suite we create in the hackathon. if bugs get fixed, then we have achieved something 1 - https://github.com/WestpointLtd/tls_prober > Yoav > > > On 7 Jun 2016, at 5:22 PM, Kyle Rose <kr...@krose.org> 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? > > > > Kyle > > > > On Jun 7, 2016 2:00 AM, "Peter Gutmann" <pgut...@cs.auckland.ac.nz > > <mailto:pgut...@cs.auckland.ac.nz>> wrote:> > > Dave Garrett <davemgarr...@gmail.com <mailto: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 <mailto:TLS@ietf.org> > > https://www.ietf.org/mailman/listinfo/tls > > <https://www.ietf.org/mailman/listinfo/tls> > > _______________________________________________ > > 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
