On Thursday, 21 July 2016 16:04:25 CEST Dave Garrett wrote: > On Thursday, July 21, 2016 06:42:52 am Hubert Kario wrote: > > On Wednesday, 20 July 2016 19:30:27 CEST Martin Rex wrote: > > > Any ClientHello with > 200 Cipher suite code points indicates fairly > > > insane > > > Client behaviour, so rejecting it is _perfectly_sane_ server behaviour. > > > > and which part of the standard says that it is "_perfectly_sane_" server > > behaviour? > > On this specific type of issue, I agree with Martin here that sanity checks > for over-the-top configurations are reasonable, however we should be > standardizing this, not having every implementation do this ad hoc. We > really should go through a list of these sort of implementation break > points and start picking arbitrary lines to add to the spec. They don't > have to be ideal numbers; just something better than an upper limit of > 2^15-2 suites (2 bytes each; 2^16-2 max sized vector) would be nice, for > this example. Yes, certain fields have to stay open-ended, namely > extensions, but reasonable limits should be added where appropriate.
I don't think that limiting the client hello by just under 2^16 bytes will help much. For memory-limited applications, simply not noting the presence of unrecognised/unsupported ciphers is an easy and robust way of handling huge cipher lists. So limiting it doesn't help much. As you've pointed out, extension list needs to stay unlimited. There's nothing else - session_id already is tiny and compression_methods is just a drop, everything else has static sizes. I'm quite sure that if I were sending a huge extension or many big extensions, the percentage of servers that are incompatible to them would be similar, if not worse. A relatively small 3KiB client hello already causes issues and this is not exactly something impossible to achieve with just TLSv1.2 and session tickets. (I'll try to have more concrete numbers on Monday) -- 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
