On Jul 20, 2016 10:31 AM, "Martin Rex" <m...@sap.com> wrote: > > Hubert Kario wrote: > > Martin Rex wrote: > >> > >> 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) > > You're seriously confusing things here. > > Any ClientHello with > 200 Cipher suite code points indicates fairly insane > Client behaviour, so rejecting it is _perfectly_sane_ server behaviour.
The IANA registry contains > > Trying to support theoretical encoding size limits is a stupid idea, > because it leads to endless security problems. Imposing sane sizes > plus a safety margin is solid implementation advice. No, using languages that permit memory safety violations leads to problems. Somehow I doubt you would call avoiding those languages sane implementation advice. Yes, a device with 8kbyte RAM could have a problem with large Client Hellos, but I doubt that is the issue here. > > Large stuff that doesn't need to be exchanged in abbreviated handshakes > should *NEVER* be included in ClientHello, because of the performance > penalties this creates (Network bandwidth for TLS handshake, > and TCP slow start). > > > > > >>> 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). > > Please recheck with a vanilla (aka extension-free) ClientHello that > has ClientHello.client_version = (3,3), to recognize all TLSv1.2-intolerant > implementations in your counts. Since TLS 1.0 servers have been instructed to ignore extensions, which finally got used in TLS 1.2. Hardly matters exactly what causes the problem. > > > >> > >> 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. > > Nope, not really. Limiting PDU sizes to reasonably sane sizes is > perfectly valid behaviour. X.509v3 certificates can theoretically include > CAT MPEGs and amount to megabytes. A TLS implementation that limits > the certificate chain (i.e. the TLS Certificate Handshake message) to > a reasonably sane size with safety margin, say 32 KBytes in total, > is acting totally reasonable. Anyone who creates an insane PKI deserves > to loose, and deserves to loose quite badly. Unless we specify minimum sizes that must be handled, this creates difficult interop problems, particularly when sizes need to be expanded. That size is less then one SPHINCS signature for instance. > > > -Martin > > _______________________________________________ > 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
