Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-not-03.txt>

Sean Turner <> Mon, 13 December 2010 19:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9295828C123 for <>; Mon, 13 Dec 2010 11:44:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.519
X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zpt1Gr+N4YD0 for <>; Mon, 13 Dec 2010 11:44:02 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 75CB728C0EB for <>; Mon, 13 Dec 2010 11:44:02 -0800 (PST)
Received: from [] by with NNFMP; 13 Dec 2010 19:45:38 -0000
Received: from [] by with NNFMP; 13 Dec 2010 19:45:38 -0000
Received: from [] by with NNFMP; 13 Dec 2010 19:45:38 -0000
Received: (qmail 71627 invoked from network); 13 Dec 2010 19:45:37 -0000
Received: from thunderfish.local (turners@ with plain) by with SMTP; 13 Dec 2010 11:45:37 -0800 PST
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
X-YMail-OSG: 0GY8xAgVM1lj2tp5K8BiPYAVSWBgzCMlt3fONclSXIFeZrU Nx4_ziBt9Xbgp7m86pNOJd.ClRXTHNUZUADm0tqdT4ull3ieC.a.YRvrOo3a w3mgTJZSGOKXukEhhXKwXXYFP4Ya1D6VbCKzB4yok_NRMffg7RT9JqVC6D.M HDtu6FsCHX9Gkl1jwOE4Ik12RCIdOkWZuL7Jx7CuC3y8e4Gh8bAsKuDP8NtX bkXaWGmnnrpn3Z.LJTbkHsfXt9BGwdDrdbAoKwPayeXgM.UBkqIUesfnxOO3 NXwNNK.OMMekP7Ew4KviCl5F6gaQxG4qKM8hQVCT90XgpiEEA7IaheCLimIe DLCSXlCdhBkf95eFjTykdGeFtqfqbso.oBLVByJ1_g4c-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <>
Date: Mon, 13 Dec 2010 14:45:36 -0500
From: Sean Turner <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Marsh Ray <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Glen Zorn <>,,
Subject: Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-not-03.txt>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Dec 2010 19:44:03 -0000

On 12/10/10 6:09 PM, Marsh Ray wrote:
> On 12/10/2010 03:35 PM, Sean Turner wrote:
>> On 12/3/10 3:27 PM, Sean Turner wrote:
>>> "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}.
> How could you ever "use" it without "negotiating" it first?
> It seems like a distinction without a difference in this document.
>> 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.
> Sounds good to me.
>> 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.
>  >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 with SCSV
> SSLv3/TLS with extensions
>> 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).
> 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?
>> 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.
> 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.
>> 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 }.
> 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."

I don't have objections to this.

>> * 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.
> "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."

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

>> [RFC5246] allowed TLS servers to respond with a SSL 2.0
>> SERVER-HELLO message.
> 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.

> 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
>> 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.
> 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.

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