RE: [TLS] Last Call: <draft-ietf-tls-ssl2-must-not-03.txt>

["Glen Zorn" <[e-mail]>]

Looks good to me.

Hope this helps.

 ~gwz

> -----Original Message-----
> From: Sean Turner [mailto:[e-mail]]
> Sent: Saturday, December 11, 2010 4:36 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; 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