Re: [TLS] consensus on backwards compatibility changes

[Dave Garrett <[e-mail]>]

On Monday, January 26, 2015 03:25:22 pm Kurt Roeckx wrote:
> I don't see how you're going to fit an SSLv2 client hello in an
> SSLv3 or TLSv1 record.

You don't. Please see the TLS 1.2 spec, RFC 5246 E.2. The deprecated
format is specified and instructed to be sent "directly on the wire, not
wrapped as a TLS record".

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

These changes are in direct reference to that existing spec.

> So you're saying that things that implement TLS 1.3 MUST NOT
> support negiotating SSLv2?  If that it what you mean, please say
> that instead.

| Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-HELLO.

The first sentence is sufficient to prohibit negotiating SSL2 entirely. I've also cited RFC 6176.
If you think this needs yet more, I guess I could stick a "and must not be negotiated"
onto the two lines citing RFC/I-D prohibitions, if you think it needs to be more clear. I have
nothing against adding redundancy here.

With regard to this topic, please see the previous discussion on list. (the "drop obsolete
SSL 2 backwards compatibility" thread) Implementers have specifically pushed back against
dropping all SSL 2 stuff, in particular because they think it is valid to still negotiate TLS 1.2
using an SSL version 2.0 client hello. I can understand why you'd have trouble
understanding this; I do too. :/

I'd much rather have an even simpler SSL backwards compatibility section with the sum
of the text being "NO", but there is not yet consensus on this.


Dave