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

[Dave Garrett <[e-mail]>]

On Monday, December 29, 2014 02:26:57 pm Martin Rex wrote:
> Server-side usage will be significantly adversely affected by a silly
> MUST NOT accept TLSv1.2 offered in SSL Version 2.0 CLIENT-HELLO

This is a semantical disagreement. The server will continue to work fine, just 
dropping v2 connection attempts. It's the client sending the v2 hello that will 
be disaffected. (it could be phrased from either perspective; the client 
initiates the connection, so I significantly prefer this one)

>    o  TLS servers MAY continue to accept ClientHello messages in the
>       version 2 CLIENT-HELLO format as specified in RFC 5246 [TLS1.2],
>       Appendix E.2.

Yes, in 2011 optional backwards compatibility was left in place. In 2015 I'm 
saying that it shouldn't be expected anymore. (or let's be realistic, 2016, when 
the slow to update get around to considering this)

> A SSL Version 2.0 CLIENT-HELLO offering TLSv1.2 is perfectly sufficient
> to negotiate the mandatory-to-implement TLSv1.2 TLS cipher suite:
> 
>   https://tools.ietf.org/html/rfc5246#section-9

Wrong reference? That's just the MTI cipher. SSL2 compatibility in TLS 1.2 is 
here:

https://tools.ietf.org/html/rfc5246#appendix-E.2

What it does say is:

"However, even TLS servers that do not support SSL 2.0 MAY accept
version 2.0 CLIENT-HELLO messages."

It's only sufficient if the server is willing to do so. It's not to be expected. 
This is a "MAY" and not a "SHOULD".

Clients MUST send v2 to connect to SSL2 servers, but that's it.

It is important to remember, however, that this section is not a valid reference 
as-is. RFC 6176 amends it.

https://tools.ietf.org/html/rfc6176

> > "TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT-
> > HELLO message format"
> 
> This applies only to *NEW* clients.

Please cite to me where it says that RFC 6176 only applies to new clients. (is 
there actually some other reference I'm missing that says that? that's certainly 
possible) It simply says:

"Updates: 2246, 4346, 5246"
&
"This document updates
the backward compatibility sections found in the Transport Layer
Security (TLS)."

Thus, anything that implements any of the updated TLS 1.x RFCs is expected to 
implement this amendment in full.

If there's some policy I'm missing here, please do point it out. However, I'm 
under the impression that this is fairly unambiguous and SSL2 is not to be 
considered acceptable anywhere. This does not seem like a controversial position 
to take in 2015.

> > With both SSL2 & SSL3 prohibited, there should be no v2 hellos.
> 
> But there still are plenty of them around in the installed base.
> 
> > Put bluntly, any environment that actually HAS v2 hellos is already
> > ignoring IETF RFCs.
> 
> Behaviour of the installed base is well known to be unaffected by documents
> published by the IETF (or any other organization, or government).

I certainly can't disagree with that. I can disagree that it should be the 
overriding force in deciding what to do next.

-----

Let me sum things up this way. There are two categories here:

A) Obsolete implementations that are insecure and supported by nobody.
B) Obsolete implementations that are at least maintained by some group.

Category B is the enterprise situation. Their IT & the software they use 
maintains this old stuff in some way. Disabling SSL2 & SSL3 is not an 
unreasonable expectation for continued maintenance if their desire is to switch 
servers over to TLS 1.3 capability. If they don't want to adopt TLS 1.3 servers 
yet, they are not affected until they do. TLS 1.3 clients would only fail to 
connect to SSL only servers. Complying with intervening RFCs is simply a 
requirement to implement the new RFC.

Category A is forsaken. There is no expectation of a secure connection with 
those clients. Dragging along backwards compatibility forever for them would be 
irresponsible. If they break, they will have to be replaced with something that 
continues to work. If this was half the population of the Internet, then yeah, 
we'd have to pathetically work around them, but that is not the case. Modern 
clients are fine here and have more than enough widespread use. If IE6 breaks, 
nobody can argue in good conscience that TLS 1.3 should be modified to 
accommodate that. And again, it is entirely possible to click a few checkboxes 
in its security options to fix the issue. (IE has generally had decent 
configurability here) I don't know about you, but I'd like to see a world where 
the only pages old versions of IE can connect to are ones that let you download 
a new browser or at least upgrade its security slightly.

Is there some specific real-world case this opposition is coming from? An 
argument to defend a specific widely used client, with justification for its 
continued use, would be far more persuasive. Simply "ahh, but Java 6" doesn't 
feel like a particularly useful argument when Java 7 & 8 are long since 
available. Give me significant hard numbers and I'll certainly change my opinion 
to a "SHOULD NOT" rather than a "MUST NOT" for all but pure TLS 1.3 connections. 
(the idea that TLS 1.3 should be negotiatable via an SSL2 hello is insane)


Dave