Re: [TLS] Thoughts on Version Intolerance

[Hubert Kario <[e-mail]>]

On Wednesday, 20 July 2016 14:49:03 CEST Kyle Rose wrote:
> > 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
> 
> When the failures are limited to obscure implementations, and/or popular
> ones with a hope of being updated, I'm in the "fix your shit" camp.
> 
> When a substantial fraction of the internet breaks, this approach is less
> clearly the right one because it can result in the never-ending downgrade
> dance, or in limited deployment of new versions/ossification. I hope (with
> no real evidence) that given the strong level of involvement of the major
> browsers in 1.3 development that advantage goes to the client.

I think that implementing complex binary cryptographic protocols is simply 
hard.

At the same time many corner cases are not encountered in day to day use, many 
failures are completely silent (TLS POODLE).

Which means that many implementers stop working on their TLS stack as soon as 
they can connect to default OpenSSL instance or to google.com, or can process 
hello message from Internet Explorer/Chrome.

While I think that the standard should be more strict, and the section D.4. we 
know from RFC 5246 should be much longer in the TLSv1.3 document, it won't 
matter if the implementers won't read the thing.

And from what I can see, people that implemented the servers that 90% of Alexa 
top 1 million sites use, simply haven't recognized that section D is 
important. Let alone tested that their implementation actually follows it!
-- 
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