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. 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.
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf