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