On Wednesday, 20 July 2016 12:14:01 CEST Martin Rex wrote: > Hanno Böck wrote: > > Checking application/pgp-signature: FAILURE > > > Hubert Kario <hka...@redhat.com> wrote: > >> so it looks to me like while we may gain a bit of compatibility by > >> using extension based mechanism to indicate TLSv1.3, > > Forget TLS extensions, forget ClientHello.client_version. > Both in fundamentally broken, and led to Web Browsers coming up > with the "downgrade dance" that is target&victim of the POODLE attack. > > We know fairly reliably what kind of negotiation works just fine: > TLS cipher suite codepoints.
please re-read my mail, they don't: 49% (6240) are intolerant to a Client Hello with no extensions but big number of ciphers that bring its size to 16388 bytes) 91.5% (11539) are intolerant to a Client Hello with no extensions but a number of ciphers that bring it well above single record layer limit (16.5KiB) > > I'm now also collecting some data and have some preliminary > > suspicion on affected devices. My numbers roughly match yours that we > > are in the more or less 3% area of 1.3 intolerance. > > The TLSv1.2 version intolerance is already a huge problem, > and I'm not seeing it go away. Acutally Microsoft created an > awfully large installed base of TLSv1.2-intolerant servers > (the entire installed base of Win7 through Win8.1 aka 2008R2, 2012, 2012R2). > > > I would really like to see the TLS WG improving the situation > rather than keep sitting on its hands. The problem has been well-known > since 2005. And the "downgrade dance" was a predictably lame approach > to deal with the situation, because it completely subverts/evades the > cryptographic protection of the TLS handshake. it's not IETF's fault that the implementers add unspecified by IETF restrictions and limitations to parsers of Client Hello messages or that they can't handle handshake messages split over multiple record layer messages, despite the standard being very explicit in that they MUST support this -- 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
