Subject: Re: [TLS] consensus on backwards compatibility changes

From: Eric Rescorla <[email-masked]>
Date: Thu, 12 Feb 2015 11:42:52 -0800

I have merged PR#105. I am awaiting chair guidance on PR#107.

-Ekr

On Tue, Jan 27, 2015 at 9:21 AM, Sean Turner <[email-masked]> wrote:

> 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 <[email-masked]> 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 <[email-masked]>
> 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Dave Garrett <[email-masked]>
Date: Thu, 12 Feb 2015 17:14:53 -0500

PR#107 rebased. I believe all comments have all been addressed.

https://github.com/tlswg/tls13-spec/pull/107/files

To recap the changes:
* ClientHello record layer version fixed to {3,1}
* other record layer versions explicitly required to be negotiated version
* note some security considerations & other suggestions from Brian
* some editorial fixups
* cite RC4 prohibition draft in backwards compatibility
* explicitly forbid ciphers <112 bits for backwards compatibility
* added the line:
"If an implementation negotiates usage of TLS 1.2, then negotiation of cipher
suites also supported by TLS 1.3 SHOULD be preferred, if available."

Dave

---

From: Michael Clark <[email-masked]>
Date: Fri, 13 Feb 2015 10:24:37 +0800

> suites also supported by TLS 1.3 SHOULD be preferred, if available."

Comments as an observer.

1). Contention on setting the ClientHello record layer version to { 3, 0
} or { 3, 1 } in TLSv1.3

-: The version of the protocol being employed.  This document
-  describes TLS Version 1.3, which uses the version { 3, 4 }.  The
-  version value 3.4 is historical, deriving from the use of {3, 1}
-  for TLS 1.0.  (See {{record-layer-1}}.)  Note that a client that
-  supports multiple versions of TLS may not know what version will
-  be employed before it receives the ServerHello.  See
-  {{backward-compatibility}} for discussion about what record layer
-  version number should be employed for ClientHello.
+: The version of the protocol being employed in the current record.
+  TLS clients MUST set this version to { 3, 1 } for the initial ClientHello.
+  For the ServerHello and all other TLS records this MUST be equal to the negotiated version.

* In support of https://github.com/tlswg/tls13-spec/issues/113 and SSLv3
deprecation with haste
* Observe approximate consensus for TLSv1.3 implementation to not
negotiate protocol versions lower than TLSv1.0 with >= 128 bit cipher suites
* Text mentions information leakage. Argue that sending { 3, 1 } { 3, 4
} qualifies as information leakage.
* Spec can be explicit that it is NOT RECOMMENDED for TLSv1.3 clients to
negotiate SSLv3 { 3, 0 } not to be conflated with the record layer lower
bound.
* Believe ClientHello { 3, 0 } { 3, 4 } may be more guarded.
* The record layer version is not to be conflated with the minimum
negotiated TLS protocol version (from the same reasoning we deduce this
as information leakage).
* If a server sees ClientHello { 3, 0 } { 3, 4 } it knows the
ClientHello binary structure changes are additive since { 3, 0 } as it
is the record layer binary compatibility boundary.
* Given TLSv1.0 is a best practice for a protocol lower bound (separate
from TLSv1.3); then a TLSv1.3 client can safely assume servers will be
extension tolerant with ClientHello { 3, 0 } { 3, 4 } .
* Argue that setting the record layer version to { 3, 0 } leaks less
information given it is the record layer binary compatibility boundary
(not to be conflated with the minimum supported TLS version).
* Observation is that { 3, 0 } { 3, 4 } at the record layer would not be
incompatible with a client not supporting versions lower than TLSv1.0 {
3, 1 }
* If TLSv1.3 ClientHello is { 3, 1 } { 3, 4 } then so be it; however not
pivoting record layer version on backwards incompatible binary changes;
leads to { 3, 2 } { 3, 5 } and more information leakage.
* The fact that an SSLv3.0 server can parse the first part of the
ClientHello is not relevant to the choice of record layer lower bound
for the TLSv1.3 ClientHello.

Please note these as observations not recommendations. If there is
approximate consensus for { 3, 1 } at the record layer then I am in the
minority on the *pinned* value; prefer it to the minimum supported
backwards compatible record layer version; given an alert indicates a
buggy server. Please do not read this as support for SSLv3 backwards
compatibility.

Flip side:

* { 3, 1 } can be regarded as the binary compatibility pivot point due
to its extension support. In that case I favor { 3, 1 }
* The only argument for { 3, 0 } supports servers that are tolerant of
unknown data after the compression methods (in addition to cipher suite
tolerance).

Flip side:

* This tolerance is not a bug. TLS requires extension and version
tolerance as it is the forwards compatibility mechanism
* This is unknown hello data in view of SSLv3.0 servers that are not
even going to be supported
* { 3, 0 } leaks less information no matter what the protocol lower
bound of the client is

Conclusion

* Would rather accept ClientHello { 3, 0 } { 3, 5 } and send ServerHello
{ 3, 4 } { 3, 4 } and not have ClientHello { 3, 0 } { 3, 5} create
alerts that lead to downgrade attack vectors
* independently from the choice of site operators and clients to drop
support for SSLv3.0. i.e. pin the ClientHello record layer at { 3, 0 }
* Not in favor of pinning ClientHello record { 3, 1 }. { 3, 0 } should
be allowed.
* BCP 188

2.) "Negotiating with buggy servers"

+### Negotiating with buggy servers
+
+Some server implementations are known to implement version negotiation
+incorrectly. There are buggy TLS servers that simply close the connection
+when a client offers a version newer than it supports. Also, it is
+known that some servers will refuse the connection if any TLS extensions are
+included in ClientHello. Interoperability with such buggy servers is a complex
+topic beyond the scope of this document, and may require multiple connection
+attempts by the client.

* Primary observation. This section is at odds with the consensus for
TLSv1.3 implementation to not negotiate anything lower than TLSv1.0 { 3,
1 } with >= TLSv1.2.
* While the protocol lower bound may not be in scope for the TLSv1.3
spec; the security concern for bugger servers should be; a small number
of buggy servers lead to clients with attack vectors
* Buggy servers should not be named or supported in a security protocol
draft.

As an observer I would prefer to see this text changed from this:

    "and may require multiple connection attempts by the client."

to something like this:

    "and may require multiple connection attempts by the client, however
it is NOT RECOMMENDED that clients make multiple connection attempts as
this provides a vector for downgrade attacks"

or change the title to:

### Negotiating with version and extension intolerant servers

---

From: Dave Garrett <[email-masked]>
Date: Thu, 12 Feb 2015 22:28:01 -0500

> negotiate SSLv3 { 3, 0 } not to be conflated with the record layer lower

https://tlswg.github.io/tls13-spec/#rfc.appendix.E.2

SSL negotiation total prohibition was committed earlier today.

> * Believe ClientHello { 3, 0 } { 3, 4 } may be more guarded.

{3,1} is current practice for some clients at the moment. General goal is to fix it to something static that works and makes sense. If we wish to avoid information leakage, the best value is whatever is already used commonly.

> prefer it to the minimum supported
> backwards compatible record layer version

Agreed. It depends on if you consider SSL3 or TLS1 to be that minimum.

> to its extension support. In that case I favor { 3, 1 }

My reasoning as well.

Either version number is acceptable. The "best" value could be empirically determined by surveying servers for which gets the least intolerance when attempting to negotiate 1.3.

> this provides a vector for downgrade attacks"

That block of text is pre-existing, just moved. A NOT RECOMMENDED line sounds appropriate if nobody objects. Insecure fallback is being phased out by Mozilla, at least, and it was never really a good idea.

Alternatively, I could just drop the whole paragraph/subsection. This set of changes are to attempt to address this concern better, so maybe they're sufficient without this buggy servers bit?

Dave

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 13 Feb 2015 08:48:44 +0100

On Thu, 2015-02-12 at 22:28 -0500, Dave Garrett wrote:
> {3,1} is current practice for some clients at the moment.
                               ^^^^
Well said. For some. That is, not all.

regards,
Nikos

---

From: Dave Garrett <[email-masked]>
Date: Fri, 20 Feb 2015 13:45:51 -0500

I've made some editorial improvements to PR 107. I've rewritten a few little bits of prior existing text and simplified the sectioning. I've also fixed some section linking. Insecure fallback is now explicitly listed as "NOT RECOMMENDED" as suggested by Michael Clark.

There is one new remaining issue to discuss that was brought up by David Benjamin on GitHub. Essentially, we want to make sure that the wording of what versions are to be used in the record layer is precise, including error cases, such that implementations are consistent here. I'd like to see what the opinion of the list is on the topic.

Current PR 107 wording for the record layer version field:
------------------------------
TLS clients MUST set this version to { 3, 1 } for the initial ClientHello.
For the ServerHello and all other TLS records this MUST be equal to the negotiated version.
------------------------------

My current consideration (not yet in PR):
------------------------------
Prior to version negotiation, this value MUST be { 3, 1 }. This includes the ClientHello, records sent during negotiation, and errors aborting the negotiation.
After version negotiation, this MUST be equal to the negotiated version. This includes the ServerHello and all following records.
------------------------------

I explicitly mention records and errors so as to make sure records in EarlyDataExtension are included. Maybe just call it out by name instead? Anyone think of some better wording here?

Once we can agree on the wording of this, I think this set of changes should be ready unless someone else has a concern that has not been addressed.

Dave

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 20 Feb 2015 21:04:29 +0200

> Current PR 107 wording for the record layer version field:

What about HelloRetryRequest?

-Ilari