Re: [TLS] Accept draft-turner-ssl-must-not-02 as WG item

[Geoffrey Keating <[e-mail]>]

Martin Rex <[e-mail]> writes:

> Sean Turner wrote:
> > 
> > Michael D'Errico wrote:
> > > Eric Rescorla wrote:
> > >> In Maastricht, we saw a presentation on draft-turner-ssl-must-not:
> > >>
> > >> http://tools.ietf.org/html/draft-turner-ssl-must-not-02
> > >>
> > >> The consensus in Maastricht was to adopt this as a WG item. If anyone 
> > >> objects please speak up now.
> > > 
> > > No objection to taking it on as a WG item, but I do have a concern
> > > with section 3:
> > > 
> > >    3. Changes to TLS
> > >       [...]
> > >        o TLS servers MUST NOT accept SSL 2.0 ClientHello messages.
> > > 
> > > I still see many SSLv2 ClientHellos, and none of them are SSLv2-only
> > > clients.  So at this point in time I think MUST NOT is too strong on
> > > the server side.  I don't think using an SSLv2 hello is a security
> > > problem since it supports the TLS_EMPTY_RENEGOTIATION_INFO_SCSV
> > > cipher suite value.
> > 
> > Unless anybody else objects I'll make the following swap:
> > 
> > OLD:
> > 
> > o TLS servers MUST NOT accept SSL 2.0 ClientHello messages.
> > 
> > NEW:
> > 
> > o TLS servers SHOULD NOT accept SSL 2.0 ClientHello messages.
> 
> A "SHOULD NOT" without a rationale appears not compliant with rfc-2119.
> 
> Personally I can not think of a reason to move away from what
> rfc-5246 appendix E.2 says.  AFAIK, the problem is strictly limited to
> negotiating and talking SSLv2.  Accepting an SSL v2.0 CLIENT-HELLO
> as the first message of an SSLv3 or TLSv1.x handshake precludes
> the sending of TLS extensions and negotiating a compression alg,
> but does not seem to cause any harm otherwise.
> 
> I would appreciate if the original wording of rfc-5246 Appendix E.2
> would be retained absent a convincing rationale to change it.
> 
> http://tools.ietf.org/html/rfc5246#page-89
> 
>    However, even TLS servers that do not support SSL 2.0 MAY accept
>    version 2.0 CLIENT-HELLO messages. 

We're really trying to get clients to change, correct?  There's no
harm in a server continuing to accept SSLv2 hellos if it can process
them.  So really we want to explain why clients should stop sending
them.

How about this straw-man text:

> A TLS sever MUST refuse to accept SSL 2.0 ClientHello messages if
> the server requires an extension.  Extensions that might be required
> for correct interoperability include the Server Name
> Indicator[RFC3546] if the server has multiple certificates with
> different names, ECC cipher suites information[RFC4492] if the
> server requires ECC, or signature algorithms if the server does not
> have a certificate which matches the default signature algorithms
> specified in [RFC5246] section 7.4.1.4.1.
> 
> It is anticipated that in future almost all servers will fall into
> one of the categories above due to greater use of elliptic curve
> algorithms, disuse of SHA-1 in certificates, and IPv4 depletion.