Looks good to me. Hope this helps. ~gwz > -----Original Message----- > From: Sean Turner [mailto:turners@xxxxxxxx] > Sent: Saturday, December 11, 2010 4:36 AM > To: tls@xxxxxxxx; ietf@xxxxxxxx > Cc: mrex@xxxxxxx; Glen Zorn > Subject: Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-not-03.txt> > > 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf