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

From: Eric Rescorla <[email-masked]>
Date: Sun, 25 Jan 2015 11:36:14 -0800

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
>

---

From: Kurt Roeckx <[email-masked]>
Date: Sun, 25 Jan 2015 21:03:27 +0100

On Tue, Dec 30, 2014 at 05:03:03AM -0500, Dave Garrett wrote:
> PR #105 remove SSL 2 backwards compatibility section & prohibit SSL negotiation

I have a small problem with it.  It says:
| Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-HELLO.
| Implementations MUST NOT negotiate TLS 1.3 or later using an SSL version 2.0 compatible
| CLIENT-HELLO. Implementations MAY accept an SSL version 2.0 compatible CLIENT-HELLO in
| order to negotiate older versions of TLS, however this is not recommended.
| Implementations MUST NOT send or accept any records with a version less than { 3, 0 }.

Doesn't that "or accept" prevent the previous sentence?  And isn't
the rest already covered by the first sentence?

Kurt

---

From: Dave Garrett <[email-masked]>
Date: Sun, 25 Jan 2015 18:14:36 -0500

> the rest already covered by the first sentence?

The SSL2 CLIENT-HELLO format can be used with TLS 1.0 (version {3,1}).

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

Regardless of what versions are in play, the SSL2 format is not allowed to be sent.
It can optionally still be accepted by servers, however, only for backwards compatibility.

> | order to negotiate older versions of TLS, however this is not recommended.

The old format can be used to negotiate TLS 1.0-1.2, but not 1.3+ or SSL.
Servers are not required to support this and can ignore them if preferred.

> | Implementations MUST NOT send or accept any records with a version less than { 3, 0 }.

Nothing stating a version for SSL2 or any bogus versions below SSL3 are allowed.
A v2 format hello with a TLS 1.0 version is unfortunately permitted.
Dropping support for this is an open issue:
https://github.com/tlswg/tls13-spec/issues/113

The minimum version tolerated here is for SSL3 due to the requirement to accept
record layer versions of any {3,X} for backwards compatibility. Hello record layer
versions mean pretty much nothing in current practice.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Sun, 25 Jan 2015 18:33:50 -0500

On Sunday, January 25, 2015 02:36:14 pm Eric Rescorla wrote:
> consensus on PR#105, but not (yet?) on PR#107.

I don't recall any objections to #107, but not much discussion either.

To sum it up here, in addition to some editorial changes:

1) Fixes initial ClientHello record layer version to { 3, 1 } (TLS 1.0) & mandates
all other record layer versions to match negotiated version.
(Brian's suggestion)

In SCSV discussion, evidence was given that this improves interop by 5.3%
for TLS 1.3 & an additional 1.5% for TLS 1.2:
http://www.ietf.org/mail-archive/web/tls/current/msg15141.html

2) Mention some other interop concerns along side existing notes.

3) Cite RC4 prohibition pending RFC.

4) "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."
(only a SHOULD, and only if available; language up for negotiation if needed)

5) Explicitly prohibit EXPORT ciphers and any others <100 bits.
(100 bit line is arbitrary; could be 112 if preferred)

Dave

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 26 Jan 2015 21:25:22 +0100

> The SSL2 CLIENT-HELLO format can be used with TLS 1.0 (version {3,1}).

I think there is some misunderstanding of how an SSLv2 client
hello works, or I'm not understanding what you're trying to say.

In SSLv2 the bytes of the record header are:
0: record length MSB, & 0x7f (or & 0x3f)
1: record length LSB
<optional padding length>

And for the record data:
<optional mac data when encrypted>
0: message type (1, client hello)
1: highest supported version MSB
2: highest supported version LSB
[...]

Since SSLv3 this has changed.  It looks like:
0: record content type (22, handshake)
1: record protocol version major
2: record protocol version minor
3: record length msb
4: record length lsb

And then in the fragment you have:
0: handshake type (1, client hello)
1: handshake length MSB
2: handshake length
3: handshake length LSB
4: highest supported version major
5: highest supported version minor
[...]

I don't see how you're going to fit an SSLv2 client hello in an
SSLv3 or TLSv1 record.  Please note that for SSLv2 there is only 1
version field while with SSLv3 there are 2.

You could of course argue that there is no record protocol version
in SSLv2.

> A v2 format hello with a TLS 1.0 version is unfortunately permitted.

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.

Kurt

---

From: Dave Garrett <[email-masked]>
Date: Mon, 26 Jan 2015 18:31:36 -0500

On Monday, January 26, 2015 03:25:22 pm Kurt Roeckx wrote:
> 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.

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

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 27 Jan 2015 01:50:29 +0100

> nothing against adding redundancy here.

I guess if you really want you could go and put {3, 0} in the
record layer (so an SSLv3 client hello) and put {2, 0} in the
Client Hello.  In theory that should work if both support SSLv3
but for some reason want to talk SSLv2, but I doubt that it's
going to work in practice.  I also don't think that anybody is
going to do that.  I'm perfectly happy with that part of the
current text, and I did already interprete that as not allowing
the negiotation of SSLv2.

> understanding this; I do too. :/

I was part of that thread.  I think we need to support the SSLv2
client hello because their are still too many clients out there
that use it to set up TLS 1.0.  If you say we should drop TLS 1.0
support I'm happy to also drop the SSLv2 client hello support.

Anyway, I only had a problem understanding what you mean with:
| Implementations MUST NOT send or accept any records with a version less than { 3, 0 }.

So now I'm thinking that you're saying that you're not allowed to
use the SSLv3 record format and put SSLv2 in the record layer
version.  I'm not sure why you think anybody would do that or that
it's going to work, it's clearly not what you want to do in case
you want to send an SSLv2 compatible client hello.  But then
people might do all kinds of strange things and I doubt that will
stop them from doing it.

Kurt

---

From: Joseph Salowey <[email-masked]>
Date: Tue, 27 Jan 2015 08:42:22 -0800

> all other record layer versions to match negotiated version.
[Joe] I think this makes sense.  I added to comments to the PR.  I propose
to move the bit about the server accepting versions {3,x} to the same place
and change the wording of the existing test to say:

"The client MUST set the version to {3, 1} for the initial ClientHello."

> (100 bit line is arbitrary; could be 112 if preferred)
[Joe] draft-ietf-uta-tls-bcp-08 recommends 112 so we probably would match
that.

>
> Dave
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Sean Turner <[email-masked]>
Date: Tue, 27 Jan 2015 12:21:03 -0500

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 Tue, Dec 30, 2014 at 2:03 AM, Dave Garrett <[email-masked]> wrote:
> CLIENT-HELLO usage into its own issue, as there is clearly no consensus on this
> 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. :/
> 
> The first has all SSL backwards compatibility changes. In addition to RFC 6176
> 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.
> 
> The second PR has more general backwards compatibility section improvements,
> 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.
> Both PRs update the Informative References as needed, which I've hopefully done
> correctly.
> 
> 
> Dave
>

---

From: Ira McDonald <[email-masked]>
Date: Tue, 27 Jan 2015 12:33:14 -0500

Hi Sean,

With respect, "are NOT RECOMMENDED" is a passive voice
synonym for active voice "SHOULD NOT" (and terrible English).

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Tue, Jan 27, 2015 at 12:21 PM, 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:
>
> 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:
>
> 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.
>

---

From: [email-masked] (Martin Rex)
Date: Tue, 27 Jan 2015 19:49:04 +0100 (CET)

Joseph Salowey wrote:
> Dave Garrett <[email-masked]> wrote:
> 

The primary reason why several implementors goofed the TLS version
negotiation in TLSv1.0 is that lack of clarity in the language.

If your above statement refers to the client_version member of the
ClientHello handshake message, please say so.

The record layer version number is entirely independent from
ClientHello.client_version, and for additional safety, it should be
explicitly mentioned what requirements, if any, exist for the record
layer protocol version of a record that carries the initial ClientHello
of a connection.

The original idea behind the TLS protocol version negotiation was that
the TLS handshake hash protects the entire handshake, and dirty hacks
like the downgrade dance that contemporary browsers are doing, would
be entirely unnecessary.

It would be a pretty stupid idea for the TLSv1.3 protocol specification
to withdraw TLS protocol negotiation protection from TLS clients, that
for whatever reason, see a need to offer pre-TLSv1.0 protocols to servers.

Defining an _implied_ set of features, that a TLS client sending/using a
backwards-compatible ClientHello offering TLSv1.3 in ClientHello.client_version
(or whatever alternative negotiation scheme the TLS WG chooses to use),
would be *MUCH* more reasonable.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Tue, 27 Jan 2015 20:20:38 +0100 (CET)

Sean Turner wrote:
> 
> 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.
> 

A description similar to this caused the TLS version negotiation problems.
The structure members in the handshake message PDUs are called
ClientHello.client_version and ServerHello.server_version.

If the above paragraph is meant to apply to the structure members
(client_version, server_version) of the respective TLS handshake message PDUs
(ClientHello, ServerHello), then please use the names of these structure
members for disambiguation.

We really should retain the TLSv1.2 requirement that TLS v1.3 servers
MUST accept any version number (3,x) at the TLS record layer for TLS
records sent before ServerHello in a TLS handshake on a new connection.

The TLS record that carries ServerHello is the first TLS record where
the version of the protocol is well defined for the server, i.e. the sender
of the record(s) that carry ServerHello.  For the client (recipient
of the ServerHello), the version becomes known only after it has started
parsing the ServerHello handshake message.  It is still unknown to the
client when it is receiving the TLS record that carries ServerHello.

-Martin

---

From: Joseph Salowey <[email-masked]>
Date: Tue, 27 Jan 2015 14:45:47 -0800

On Tue, Jan 27, 2015 at 10:49 AM, Martin Rex <[email-masked]> wrote:

> > > 1) Fixes initial ClientHello record layer version to { 3, 1 } (TLS
> 1.0) &
> > > mandates
[Joe] The text above is from the section describing the record protocol and
is referring to the version in the record layer of the protocol.  I agree
that it would be better to be explicit about this as it has generated
confusion in the past.

> for whatever reason, see a need to offer pre-TLSv1.0 protocols to servers.
[Joe] Agree, this is not what is being proposed.

> would be *MUCH* more reasonable.
[Joe] I'm not sure what you mean.

---

From: Dave Garrett <[email-masked]>
Date: Tue, 27 Jan 2015 18:00:06 -0500

> "The client MUST set the version to {3, 1} for the initial ClientHello."

Language changed and {3,X} backward compatibility sentence added.

> [Joe] draft-ietf-uta-tls-bcp-08 recommends 112 so we probably would match

No objection. Updated.

> ClientHello handshake message, please say so.

The language is proposed for within the version field definition for the record
layer version.

Would we want a paragraph somewhere explicitly mentioning possible
confusion between record layer version, hello version, & negotiated version?

> members for disambiguation.

Yes, Eric asked for that same change. I updated the PR a couple days ago.

Dave

---

From: Florian Weimer <[email-masked]>
Date: Wed, 28 Jan 2015 13:25:44 +0100

On 01/27/2015 12:31 AM, Dave Garrett wrote:
> using an SSL version 2.0 client hello.

But if you do this, the handshake uses SHA-1 only, per section 7.4.1.4.
 So while it was possible to negotiate a fully-fledged TLS 1.1
connection starting from an SSL 2.0 Client Hello, that's no longer
possible with TLS 1.2—you'll end up with likely weaker handshakes in
some cases (OID || SHA-1 in the ServerKeyExchange signature vs MD5 ||
SHA-1 in TLS 1.1 and earlier or, say, OID || SHA-256 with the extension
and TLS 1.2).  Sending the supported_signature_algorithms extension is
optional according to the specification, but not optional in the spirit.

-- 
Florian Weimer / Red Hat Product Security

---

From: [email-masked] (Martin Rex)
Date: Wed, 28 Jan 2015 21:42:36 +0100 (CET)

Florian Weimer wrote:
> Dave Garrett wrote:
>> 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.
> 

rfc5246 section 7.4.1.4?
I think you are misreading the TLSv1.2 specification.

The use of SHA-256 for the TLSv1.2 PRF and for the handshake message
hash that goes into the the Finished handshake message depends only
on the chosen cipher suite and the protocol (v1.2), and is independent
from whether the client sent a signature algoritm extension and what
algorithms were listed in that extension.

https://tools.ietf.org/html/rfc5246#section-7.4.9

There are several serious design flaws (resulting in serious weaknesses)
in the TLSv1.2 signature algorithm extension, however.  TLSv1.2 is the
only TLS protocol version where (rsa,md5) is a valid signature algorithm
for creating "digitally-signed" PDUs (ServerKeyExchange and
CertificateVerify), and that was a terribly stupid decision.
Even (rsa,sha1) is significantly weaker than what every prior TLS
protocol version, including SSLv3 had been using (rsa,sha1+md5).

Since the TLSv1.2 signature algorithm extension semantics have been so
terribly misspecified, it will take quite a while before TLSv1.2 clients
can safely remove (rsa,sha1) from ClientHello (unless they continue
doing reconnect fallbacks after handshake failures, aka downgrade dances).

I would not have imagined something as broken as the TLSv1.2 signature
algorithms extension would (a) get proposed and (b) get standardized,
but it happened, as you can see in rfc5246.  When I noticed the
brokenness when reading rfc5246, I hoped that implementors would
recognize the obvious security problem and refuse to implement it.
Well, some hearts don't miss a single bleed.

-Martin

---

From: Florian Weimer <[email-masked]>
Date: Thu, 29 Jan 2015 11:01:57 +0100

> protocol version, including SSLv3 had been using (rsa,sha1+md5).

Yes, that's what I meant, or more precisely, the {rsa,sha1} default in
case of a missing TLS extension (which includes SSLv2 Client Hello case).