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
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.
spt
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf