Re: [TLS] consensus on backwards compatibility changes

We believe that what’s reflected in PR #105 reflects list consensus.  But, we (as chairs) have a couple of thoughts:

0) We both hate “MAY” requirements language.  We’d prefer that the following be reworded (this is just a starting point):

OLD:

 Implementations MAY accept an SSL version 2.0 compatible
 CLIENT-HELLO in order to negotiate older versions of TLS,
 however this is not recommended.

NEW:

 Implementations are NOT RECOMMENDED to accept an
 SSL version 2.0 compatible CLIENT-HELLO in order to
 negotiate older versions of TLS.

note that the using “NOT RECOMMENDED” also means we need to add that to the 2119 language clause but we can do that later.  Basically:

s1.1: OLD:

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [RFC2119].

NEW:

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT”,
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED”,
 "MAY", and "OPTIONAL" in this document are to be interpreted as described
 in RFC 2119 [RFC2119].

1) We’d like to make it crystal clear in the SSL3.0 text whether you’re talking about the hello version or record version. We’re pretty sure that “protocol version” in the following is the hello version but we think that should be made clear.

 Implementations MUST NOT send a ClientHello or ServerHello with
 the protocol version set to { 3, 0 } or less. Any endpoint receiving a
 Hello message with the protocol version set to { 3, 0 } MUST respond
 with a "protocol_version" alert message and close the connection.

spt

On Jan 25, 2015, at 14:36, Eric Rescorla <ekr@rtfm.com> wrote:

> Based on reading the mailing list, it seems to me that there is rough consensus
> on PR#105, but not (yet?) on PR#107.
> 
> Chairs,
> I'd like to merge PR#105. Do you agree that there is consensus? If so,
> I will merge.
> 
> Can you please advise on how you would like to proceed on PR#107?
> 
> -Ekr
> 
> 
> 
> 
> On Tue, Dec 30, 2014 at 2:03 AM, Dave Garrett <davemgarrett@gmail.com> wrote:
> Per Brian's suggestion, I've split the topic of full prohibition of SSL v2
> CLIENT-HELLO usage into its own issue, as there is clearly no consensus on this
> yet. It would be really nice if some real-world stats on how much this is
> actually used could be provided. (I think continued acceptance of it is
> illegitimate, but hard data is harder to argue with)
> 
> Issue #113 Prohibit SSL v2 CLIENT-HELLO entirely
> https://github.com/tlswg/tls13-spec/issues/113
> 
> I have heard notable support for this, including Eric, but I do concede there
> might be too much desire for infinite backwards compatibility to reach consensus.
> I'm still hopeful we can come to an agreement that two decades is a sufficient
> deprecation period. :/
> 
> I have two PRs for the backwards compatibility section.
> 
> The first has all SSL backwards compatibility changes. In addition to RFC 6176
> SSL 2 language, I've added SSL 3 negotiation prohibition as per Martin's
> suggestion (based on the current I-D). The v2 hello documentation is cut out,
> but seeing as it's only valid for prior versions, prior RFCs can be referenced
> if needed.
> 
> PR #105 remove SSL 2 backwards compatibility section & prohibit SSL negotiation
> https://github.com/tlswg/tls13-spec/pull/105
> 
> The second PR has more general backwards compatibility section improvements,
> prohibition of RC4 (also based on its current I-D), and Brian's ClientHello
> version freeze proposal. Currently, I have the ClientHello version listed as a
> "MUST", but I leave for the possibility that a "SHOULD" might be appropriate if
> other tactics for dealing with buggy servers should continue to be permitted.
> Feedback from Microsoft, Oracle, or anyone else implementing alternate
> workarounds here would be greatly appreciated.
> 
> PR #107 revise backwards compatibility & fix ClientHello version
> https://github.com/tlswg/tls13-spec/pull/107
> 
> Note that the SSL3 & RC4 language based on current drafts is of course
> contingent on those being passed successfully, though this is generally
> expected.
> 
> Both PRs update the Informative References as needed, which I've hopefully done
> correctly.
> 
> 
> Dave
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls