Subject: [TLS] Last Call: <draft-ietf-tls-ssl2-must-not-03.txt> (Prohibiting SSL Version 2.0) to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 01 Dec 2010 05:55:03 -0800

The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document:
- 'Prohibiting SSL Version 2.0'
  <draft-ietf-tls-ssl2-must-not-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2010-12-15. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tls-ssl2-must-not/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tls-ssl2-must-not/

No IPR declarations have been submitted directly on this I-D.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 2 Dec 2010 09:31:14 +0700

Section 3 says "TLS clients MUST NOT send SSL 2.0 CLIENT-HELLO messages."
and "TLS servers MUST NOT negotiate or use SSL 2.0" and later "TLS servers
that do not support SSL 2.0 MAY accept version 2.0 CLIENT-HELLO messages as
the first message of a TLS handshake for interoperability with old clients."
Taken together, I find these statements quite confusing, if not outright
self-contradictory.  Maybe, a "However" might fix the problem, though: 

	TLS servers MUST NOT negotiate or use SSL 2.0; however, TLS servers 
	MAY accept SSL 2.0 CLIENT-HELLO messages as the first message of a 
	TLS handshake in order to maintain interoperability with legacy 
	clients.

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 01 Dec 2010 21:01:48 -0800

> 	TLS handshake in order to maintain interoperability with legacy 

Glen,

There is no contradiction among the statements, but they may be confusing (I
can't tell anymore since I've gone through the drafts several times).  The
idea is that:

   - no TLS client should ever negotiate SSL 2.0; therefore there is never
     a need for it to send an SSL 2.0 CLIENT-HELLO

   - servers, however, need to interoperate with older software that might
     send an SSL 2.0 CLIENT-HELLO even though it supports SSLv3 or later,
     so it's OK for them to accept that message as long as the resulting
     version is not SSL 2.0.

The reason it is OK to accept CLIENT-HELLO is because it can carry the SCSV
cipher suite value used to plug the renegotiation security hole (RFC 5746).

Mike

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 02 Dec 2010 00:24:17 -0500

> cipher suite value used to plug the renegotiation security hole (RFC 5746).

Why is that relevant?  The draft only retires SSL 2.0, for reasons
unrelated to the renegotiation issue.

-- 
Matt

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 01 Dec 2010 21:49:49 -0800

> unrelated to the renegotiation issue.

If you couldn't put the SCSV into the CLIENT-HELLO, then it would not
be OK for servers to accept that message; it would have to be a MUST
NOT.

Mike

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 02 Dec 2010 01:02:14 -0500

> be OK for servers to accept that message; it would have to be a MUST

You have just said the same thing again.  Why?  What potential security
problem be prevented by the server not accepting a SSL 2.0 CLIENT-HELLO?

-- 
Matt

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 01 Dec 2010 22:15:20 -0800

> problem be prevented by the server not accepting a SSL 2.0 CLIENT-HELLO?

I'm not sure why you're objecting to my comment.

We are deprecating SSL version 2.0.  However, we are allowing the
continued acceptance of the SSL 2.0 CLIENT-HELLO by TLS servers.

It would be irresponsible for us to do that if it left open the
renegotiation hole that was closed via the RenegotiationInfo
extension (and SCSV), and I wouldn't support it if that were the
case.

I was merely pointing that out.

Mike

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 02 Dec 2010 09:22:03 +0100

> I was merely pointing that out.

Indeed but this is an argument not mentioned in the document at all.
Maybe a paragraph of security considerations could be added (or is it
too late?), that will mention that certain (current or future)
security-related extensions is not possible to be supported by an SSL 2
hello message, although this is not the case with SCSV.

Merely as an argumentation on why accepting SSL 2 hello messages is a
may.

regards,
Nikos

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 2 Dec 2010 21:01:23 +0700

Michael D'Errico [mailto:[email-masked]] writes:

> can't tell anymore since I've gone through the drafts several times).

Maybe I just don't understand the word "use".  It seems like if a server
accepts a protocol message it's using the protocol...

...

---

From: Marsh Ray <[email-masked]>
Date: Thu, 02 Dec 2010 12:11:17 -0600

On 12/02/2010 08:01 AM, Glen Zorn wrote:
>
> Maybe I just don't understand the word "use".  It seems like if a
> server accepts a protocol message it's using the protocol...

Hard to argue with that logic...but... :-)

The Client Hello message is the first message sent in the protocol. Its
format changed completely from SSLv2 to what is used by SSLv3 thorough
TLS 1.2.

The number one job of the Hello messages (in any protocol) is generally 
to negotiate the version of the protocol used for all subsequent 
messages. Everything else in the Hello message is, in a sense, put there 
as an optimization to save some round trips.

Since the ancient v2 servers obviously couldn't understand one bit of a
v3 or later Client Hello (some would break quite badly), there was an 
option in the SSLv3 spec to lead off the handshake with a v2-compatible 
Client Hello. A direct transliteration of the v3 Client Hello message to 
a v2 was defined The only reason that worked was because the v3 Hello 
didn't introduce any significant new information (when it was first 
defined).

So it is, in fact, possible to use a SSLv2 Client Hello message with
later protocols, even if neither endpoint is willing to speak SSLv2 for
the actual connection. There is a significant percentage of handshakes 
today which lead off with a v2 Hello, even though the vast majority of 
servers support TLS 1.0.

The renegotiation problem required a means to signal at least one new
flag (roughly, "I'm patched") in the initial Hello message. This is
probably still fresh on everyone's minds, so the fact that a means was
found to signal this bit in the SSLv2-format Client Hello message still
feels relevant. If it had not been possible to squeeze that extra flag
in, the text we have been discussing would be much different.

On 12/01/2010 08:31 PM, Glen Zorn wrote:
> Section 3 says "TLS clients MUST NOT send SSL 2.0 CLIENT-HELLO
> messages." and "TLS servers MUST NOT negotiate or use SSL 2.0" and
> later "TLS servers that do not support SSL 2.0 MAY accept version
> 2.0 CLIENT-HELLO messages as the first message of a TLS handshake for
> interoperability with old clients." Taken together, I find these
> statements quite confusing, if not outright self-contradictory.

I don't see any problem with them. Sometimes the wording in RFCs reads a 
bit like a bullet-point list of standalone requirements that got 
formatted into a paragraph. I find this style to actually be quite 
comforting when you go to implement something. You can turn it into an 
implementation checklist with less chance that you might lose something 
written between the lines.

> Maybe, a "However" might fix the problem, though:
>

I do like your wording better. But I don't think it's enough of a 
technical improvement to necessitate change during last call.

- Marsh

---

From: Joe Salowey <[email-masked]>
Date: Thu, 2 Dec 2010 10:25:07 -0800

Hi Glen,

In reading the text and I'm not exactly sure where the confusion or contradiction comes in.  I think your suggested text is fine, but I'm not sure how it improves things.  If I understand your point correctly accepting an SSL 2.0 hello as the first message in the TLS handshake is an example of using at least part of SSL 2.0, so we should indicate that this is an exception to the MUST NOT use SSL 2.0 directive.  Is this your concern?

Thanks,

Joe

On Dec 1, 2010, at 6:31 PM, Glen Zorn wrote:

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

---

From: Martin Rex <[email-masked]>
Date: Thu, 2 Dec 2010 19:46:29 +0100 (MET)

Glen Zorn wrote:
> > messages."

With "negotiate" I meant returning a ServerHello handshake message with
that version number (neither an SSL 2.0 SERVER-HELLO, nor an SSLv3
ServerHello with a server version of { 0x02,0x00 }).

With "use" I meant to successfully complete the handshake and start
exchanging application data protected under protocol version {0x02,0x00}.

The Server accepts the SSL 2.0 CLIENT-HELLO protocol data unit (PDU),
but not the SSL 2.0 protocol.  If there are no SSLv3 or TLS cipher
suites in that CLIENT-HELLO, or if the (version) field of the
SSL 2.0 CLIENT-HELLO does not indicate at least 3.0, then the server
still MUST abort.

-Martin

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 3 Dec 2010 11:44:18 +0700

Martin Rex [mailto:[email-masked]] writes:

> server

Maybe you could spell these things out in the draft just as you have above?

> but not the SSL 2.0 protocol.  

I see.  Perhaps the distinction between PDU and "protocol" is just too
subtle for me, but assuming (maybe too generously ;-) that I'm not a total
moron, others might find it a little bit confusing as well.

> If there are no SSLv3 or TLS cipher

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 3 Dec 2010 12:10:57 +0700

Joe Salowey [mailto:[email-masked]] writes:

> Hi Glen,
> 
> In reading the text and I'm not exactly sure where the confusion or
> contradiction comes in.  I think your suggested text is fine, but I'm
> not sure how it improves things.  If I understand your point correctly
> accepting an SSL 2.0 hello as the first message in the TLS handshake is
> an example of using at least part of SSL 2.0, so we should indicate that
> this is an exception to the MUST NOT use SSL 2.0 directive.  Is this
> your concern?

Yup.

...

---

From: Martin Rex <[email-masked]>
Date: Fri, 3 Dec 2010 20:58:40 +0100 (MET)

Glen Zorn wrote:
> Martin Rex wrote:

I'm sorry, my explanations were misleading.  I explained what I meant
when I wrote these statements that ended up in the document.

  http://www.ietf.org/mail-archive/web/tls/current/msg07091.html

The author/editor of this I-D is Sean Turner.

> moron, others might find it a little bit confusing as well.

I do agree that the "specification" part is extremely brief.
The best way to adjust this (as we are in IETF Last Call for this
document) is to propose a specific replacement/update text.  :)

The distinction is not so much about the difference between "PDU" and
"protocol", than it is about "active" and "passive" and the general
IETF principle of "Be liberal in what you accept, and conservative
in what you send".

So we don't want servers to "actively" (=send out) SSL 2.0 protocol,
but continue to be liberal in what they accept, e.g. "SSL 2.0 CLIENT-HELLO
as the first message of an SSLv3 or TLS handshake".  At least while
there is _no_known_ security problem associated with this particular
behaviour, because it improves interoperability with the installed
base.

-Martin

---

From: Sean Turner <[email-masked]>
Date: Fri, 03 Dec 2010 15:27:14 -0500

> The author/editor of this I-D is Sean Turner.

I've got no problem with providing additional clarifying text.  How 
about we add the following (some minor tweaks to what you suggested) to 
explain what we mean by use and negotiate (send seems clear):

"negotiate" means returning a ServerHello handshake message with that 
version number (neither an SSL 2.0 SERVER-HELLO, nor an SSLv3 
ServerHello with a server version of { 0x02,0x00 }).

"use" means to successfully complete the handshake and start exchanging 
application data protected under protocol version {0x02,0x00}.

spt

---

From: Sean Turner <[email-masked]>
Date: Fri, 10 Dec 2010 16:35:39 -0500

On 12/3/10 3:27 PM, Sean Turner wrote:
> I've got no problem with providing additional clarifying text. How about
> we add the following (some minor tweaks to what you suggested) to

So it's been proposed that I better integrate the text after the bullets 
into the bullets and better explain negotiate and use.  I'm game.

For the client, all I've ever wanted to do is change the "TLS 1.2 
clients SHOULD NOT support SSL 2.0" to a MUST NOT.  For me, client 
support meant sending SSL 2.0 CLIENT-HELLO, accepting SSL 2.0 
SERVER-HELLO, and then proceeding using SSL 2.0 records.  I can see that 
people might not make the leap that client support meant accepting the 
SSL 2.0 SERVER-HELLO and using SSL 2.0 records because the above-quoted 
sentence was in a warning that discussed 2.0 CLIENT-HELLOs.

For servers, my thinking has evolved. I'm now at the point where I'd 
like to have TLS servers not have to support SSL 2.0 SERVER-HELLOs and 
SSL 2.0 records after the handshake (RFC 5246 is clear that TLS 
1.*/SSLv3 servers can accept a SSL 2.0 CLIENT-HELLO).

If we prohibited TLS client's sending SSL 2.0 CLIENT-HELLO and TLS 
servers sending SSL 2.0 SERVER-HELLO, then I'd be happy because clients 
won't send SSL 2.0, servers won't respond with SSL 2.0, and therefore 
clients won't end up agreeing to send SSL 2.0 records and the server 
won't have to do SSL 2.0 records.

How the following replacement text for Section 3:

Because of the deficiencies noted in the previous section:

* TLS Clients MUST NOT propose SSL 2.0 to a TLS server by sending
   an initial SSL 2.0 CLIENT-HELLO handshake message with protocol
   version { 0x02, 0x00 }.

* According to [RFC5246] Appendix E.2, TLS Servers, even when not
   implementing SSL 2.0, MAY accept an initial SSL 2.0 CLIENT-HELLO
   as the first handshake message of a SSLv3 or TLS handshake.

   [RFC5246] allowed TLS servers to respond with a SSL 2.0
   SERVER-HELLO message.  This is no longer allowed.  That is, TLS
   Servers MUST NOT reply with a SSL 2.0 SERVER-HELLO with a protocol
   version of { 0x02, 0x00 } and instead MUST abort the connection,
   i.e., when the highest protocol version offered by the client is
   { 0x02, 0x00 } the TLS connection will be refused.

Note that the number of servers that support this above-mentioned "MAY 
accept" implementation option is declining, and the SSL 2.0 CLIENT-HELLO 
precludes the use of TLS protocol enhancements that require TLS 
extensions. TLS extensions can only be sent as part of an (Extended) 
ClientHello handshake message.

spt

---

From: Marsh Ray <[email-masked]>
Date: Fri, 10 Dec 2010 17:09:17 -0600

>> application data protected under protocol version {0x02,0x00}.

How could you ever "use" it without "negotiating" it first?
It seems like a distinction without a difference in this document.

> clients SHOULD NOT support SSL 2.0" to a MUST NOT.

Sounds good to me.

> For me, client

 >RFC2246: TLS 1.0 clients that support SSL Version 2.0 servers
 >RFC2246: must send SSL Version 2.0 client hello messages [SSL2].

IMHO, this is statement on its own is ambiguous to the point of being 
wrong. The problem is that is muddies up the essential distinction:
The term "SSL Version 2.0" refers to a completely different thing
than an "SSLv2-format compatible Client Hello message".

But it is cleared up in subsequent wording:
 >RFC 2246: TLS servers should accept either client hello format if

This uses the word "format" to make that critical distinction.

RFC2246: they wish to support SSL 2.0 clients on the same
RFC2246: connection port. The only deviations from the Version 2.0
RFC2246: specification are the ability to specify a version with a
RFC2246: value of three and the support for more ciphering types
RFC2246: in the CipherSpec.

It's really imprecise to talk about a "Version 2.0 Client Hello" message 
because one of the primary purposes of the initial hello message 
exchange is to negotiate exactly which protocol will be used for all 
subsequent messages (i.e., the "protocol version").

The Client Hello, in effect, has its own protocol version which has 
evolved somewhat independently over the years:

SSLv2
SSLv2 with SCSV
SSLv3/TLS
SSLv3/TLS with SCSV
SSLv3/TLS with extensions

> 1.*/SSLv3 servers can accept a SSL 2.0 CLIENT-HELLO).

Isn't an "SSL 2.0 SERVER-HELLO" is equivalent to negotiating the use of 
the SSL 2.0 protocol? Isn't that the thing for which we're trying to put 
the final nail in the coffin?

> won't have to do SSL 2.0 records.

Really all you have to do is prohibit the client from sending an 
SSLv2-compatible client hello.

It may not hurt to reiterate that this implies that the server will not 
be subsequently negotiating the use of SSL 2.0 either. But the client 
hello messages and the server hello messages have completely different 
considerations, so there's no point in trying to make the language 
symmetric.

> an initial SSL 2.0 CLIENT-HELLO handshake message with protocol

How about

"TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT-HELLO 
message format. Clients MUST NOT send any client hello message which 
specifies a protocol version less than { 0x03, 0x00 }. As previously 
stated by the definitions of all previous versions of TLS, the client 
SHOULD specify the highest protocol version it supports."

> as the first handshake message of a SSLv3 or TLS handshake.

"TLS servers MAY continue to accept client hello messages in the version 
2 client hello format as specified in TLS [RFC2246]. Note that this does 
not contradict the prohibition against actually negotiating the use of 
SSL 2.0."

> SERVER-HELLO message.

I don't see where it says that explicitly.

I would have interpreted RFC5246 as being mostly irrelevant once each 
endpoint learns that the highest mutually-supported version was 
something less than TLS 1.2.

AFAICT, this is the first document in the SSL/TLS evolution that 
attempts to mandate behavior WRT earlier versions of the protocol.

> This is no longer allowed. That is, TLS

Would "is less than { 0x03, 0x00 }" be a better condition? Not that many 
clients are likely to send { 0x02, 0xFF }, but we might as well prohibit it.

- Marsh

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 11 Dec 2010 10:34:04 +0700

Looks good to me.

Hope this helps.

 ~gwz

> -----Original Message-----
> From: Sean Turner [mailto:[email-masked]]
> Sent: Saturday, December 11, 2010 4:36 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; Glen Zorn
> Subject: Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-not-03.txt>
> 
> about

---

From: Sean Turner <[email-masked]>
Date: Mon, 13 Dec 2010 14:45:36 -0500

> SHOULD specify the highest protocol version it supports."

I don't have objections to this.

> not contradict the prohibition against actually negotiating the use of

I'd only add a pointer to the specific place in 5246, which somebody 
else asked for.

> I don't see where it says that explicitly.

5246 does not say this explicitly, or at least I couldn't find it 
either.  I definitely inferred that it was allowed.

> clients are likely to send { 0x02, 0xFF }, but we might as well prohibit

It would line up better with the change to the 1st bullet.

spt