Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time]

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 <krose@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" <pgut001@cs.auckland.ac.nz
> > <mailto:pgut001@cs.auckland.ac.nz>> wrote:> 
> > Dave Garrett <davemgarrett@gmail.com 
<mailto:davemgarrett@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

Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time]

Attachment: signature.asc