On 12/3/10 3:27 PM, Sean Turner wrote:
On 12/3/10 2:58 PM, Martin Rex wrote:
Glen Zorn wrote:
Martin Rex wrote:
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...
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}.
Maybe you could spell these things out in the draft just as you have
above?
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.
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}.
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf