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. 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. 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. >> >> 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. -Martin _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
