Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft

[Dave Garrett <[e-mail]>]

On Friday, December 26, 2014 01:11:39 pm Kurt Roeckx wrote:
> On the other hand if you do receive such a client hello you're
> likely talking to old software that most likely isn't support
> anymore and might have various security issues.  It might be a
> good indication of clients you prefer not to talk to.

My primary concern is that continuing to maintain official support for a 
deprecated format from an insecure protocol leaves a significant amount of 
complexity in place just to support woefully out-of-date implementations. I 
think that many people agree that one of the main goals of TLS 1.3 needs to be 
reduction of complexity. The more legacy features that are removed, the simpler 
the protocol will be, and the safer it will be to implement properly.

Refusing to connect to these old clients will also, hopefully, get some of them 
upgraded to new ones that actually work with modern protocols.

> It's saying that you should refuse a connection from a client that
> supports TLS 1.0 but set it up using a SSLv2 compatible client
> hello.  If TLS 1.0 is still acceptable, why would you refuse such
> a connection?

If there were a simple way to detect that, without having to support the old 
hello format, and reply with a simple refusal that triggered a negotiation using 
TLS, then that might be preferable. However, at some point it's just not worth 
it. You just have to cut off backwards compatibility, eventually.

Also, I'm not sure I agree that TLS 1.0 is still acceptable. Personally, I'd 
like to see an official deprecation and an attempt to force implementations to 
upgrade to at least 1.2 at some point. HTTP/2 should help here, I hope. (at 
least on the web) It would be nice to not have to panic and handle some fatal 
flaw in TLS 1.0 like had to be done for SSL 3.


Dave