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

[Martin Rex <[e-mail]>]

Peter Gutmann wrote:
> 
> Martin Rex <[e-mail]> writes:
> 
> >Personally I can not think of a reason to move away from what rfc-5246
> >appendix E.2 says.
> 
> I can.  That language has been in there more or less forever, and it's had
> pretty much zero effect in encouraging implementations to drop the SSLv2
> handshake (some implementations gradually have over time, but probably not
> because of text that says "well, you know, it would be really uncool if you
> kept sending SSLv2 hello's for the next twenty years").  Without a clear MUST
> NOT for the server to finally get clients to switch off SSLv2 hellos, we're
> never going to get rid of these things.

But that is a clear violation of the rfc-2119 terminology and
rfc-2119 section 6.

http://tools.ietf.org/html/rfc2119#section-6

   6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.


Having TLS-only servers accept an SSL 2.0 CLIENT-HELLO at the beginning
of a TLS handshake does not cause harm, as described in rfc-5246
Appendix E.2.

But disabling an existing support for SSL 2.0 CLIENT-HELLO acceptance
in a productive system has the clear potential to cause interoperability
problems.  And the way you describe the purpose of this change,
the intended purpose is specifically to cause interoperability problems.

I'm violently opposed to a rationale "the sole purpose is to create
interop problems for a fraction of the intalled base".


-Martin