Re: [TLS] Thoughts on Version Intolerance

[Hubert Kario <[e-mail]>]

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