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

From: Sean Turner <[email-masked]>
Date: Tue, 14 Sep 2010 10:54:51 -0400

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.

spt

---

From: Martin Rex <[email-masked]>
Date: Wed, 15 Sep 2010 03:55:28 +0200 (MEST)

> 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. 

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Sep 2010 19:20:37 -0700

At 3:55 AM +0200 9/15/10, Martin Rex wrote:
>A "SHOULD NOT" without a rationale appears not compliant with rfc-2119

I get a chance to agree with Martin!

>   version 2.0 CLIENT-HELLO messages.

Sounds good to me.

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 15 Sep 2010 15:54:21 +1200

Martin Rex <[email-masked]> 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.

Peter.

---

From: Marsh Ray <[email-masked]>
Date: Wed, 15 Sep 2010 01:57:47 -0500

On 09/14/2010 10:54 PM, Peter Gutmann wrote:
> Martin Rex<[email-masked]>  writes:
>
> [...] Without a clear MUST

I 100% agree on the goal of getting everyone exchanging the modern, 
extension-compatible Hellos. I also think that the "tough love" approach 
is sometimes needed to move these things forward, particularly where 
they diminish security.

I'm thinking though that this document is kind of an unusual case.

For example, if you're not compliant with RFC 791 (Internet Protocol), 
you can't exchange packets over the internet. If you don't implement RFC 
793 (Transmission Control Protocol), you can't talk with most network 
services. Likewise, if you don't implement most of RFC 2246 (TLS 1.0) 
and some related standards, you won't be doing any shopping online.

But if draft-turner-ssl-must-not-02 becomes RFC NNNN, that means...

If you don't implement RFC NNNN, then you _can_ successfully continue to 
interoperate with some set of servers? With no inherent sacrifice of 
performance or security?

Conversely, if you _do_ implement this future RFC NNNN, you must now 
cease interoperating with previously legitimate requests.

So what is the expected consequence to a vendor for _not_ implementing 
this possible future RFC? It's not something that the vendor misses out 
on, like the big party going on over in TCP port 443. Certainly no 
prospective customer is going to push them for support of RFC NNNN.

Why would any vendor implement this spec unless they were planning to 
follow its recommendations for their own set of reasons anyway?

We've all vented to our co-workers (and spouses) at one time or another: 
"that goshdarn vendor will just never add support for RFC such-and-such 
even though it was standardized years ago, if only they took standards 
compliance more seriously!" Could it be that publishing a set of SHOULDs 
and MUSTs that are likely to be summarily disregarded has the potential 
to, um, erode the authority of the standards process a little bit?

It's not like implementers had jumped to add support for all the 
optional extensions when they were first defined. Today only a tiny 
fraction of TCP port 443 servers implement TLS 1.1 or 1.2 (827 and 11 
out of 607,249 respectively 
http://blog.ivanristic.com/Qualys_SSL_Labs-State_of_SSL_2010-v1.6.pdf).

It's been said that the only way we will move old protocols forward is 
to find some killer security hole in the old version. It also seems to 
be ever more frequently repeated that "SSL is irreparably broken". But 
I'm not so cynical. (Sorry, it doesn't happen often. :-) Perhaps folks 
could be enthusiastic again about upgrading if they expected it to bring 
new and improved functionality which even served their short term 
self-interest a little. You know, like the old times.

I could see that it might be helpful to give an engineer some official 
support for removing some attack surface that nobody's really using 
anyway. In this case, could that need be equally served by an 
informational RFC?

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Sep 2010 12:21:34 +0200

> never going to get rid of these things.

I disagree about "never". There is really just one client left "in the wild" that sends as SSLv2 ClientHello, and that client is 10 years old.

As XP-without-service-packs drifts into obscurity, the MUST NOT will become appropriate. For now, following the MUST NOT in HTTPS servers means that 20% of browsers won't connect.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 15 Sep 2010 06:10:02 -0600

On 9/15/10 12:57 AM, Marsh Ray wrote:

> Today only a tiny

The operative question here seems to be: what fraction of TLS clients
send SSL 2.0 ClientHello messages?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Martin Rex <[email-masked]>
Date: Wed, 15 Sep 2010 16:20:46 +0200 (MEST)

> 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

---

From: Russ Housley <[email-masked]>
Date: Wed, 15 Sep 2010 09:06:51 -0400

> o TLS servers SHOULD NOT accept SSL 2.0 ClientHello messages.

I do not object, but at the same time, I think that we are all aware of
the places that SSL 2.0 is not as good as we would like.

I'd rather not redo this discussion in a few years to change "SHOULD
NOT" to MUST NOT."  I wonder if we can agree on an end date:

o TLS servers SHOULD NOT accept SSL 2.0 ClientHello messages today, and
  TLS servers MUST NOT accept SSL 2.0 ClientHello messages after <date>.

Russ

---

From: Martin Rex <[email-masked]>
Date: Wed, 15 Sep 2010 21:26:45 +0200 (MEST)

> never going to get rid of these things.

 client MUST NOT negotiate or use SSL 2.0  is fine with me
 client MUST NOT send SSL 2.0 CLIENT-HELLO is fine with me
 server MUST NOT negotiate or use SSL 2.0  is fine with me

but

 server SHOULD NOT accept SSL 2.0 CLIENT-HELLO as the first message
 of a TLS handshake is not sensible and is in clear
 conflict with rfc2119 section 6.

What is written in new RFC affects new implementations at best,
and no amount of cursing, praying and MUST NOT-specifying is going
to change the behaviour of the installed base.  So the only effect
this change could result in is interop problems with a fraction
of the installed base.

The only time when this is permissible per rfc-2119 section 6 is
when retaining this feature on the server would cause harm to
this server -- and there is no harm for the server to accept
an SSL 2.0 CLIENT-HELLO as the first message of a TLS handshake.

Mind you that the existing specification already leaves it to
the discretion of implementors, vendors and server admins to
cause these interop problems if they choose to be so mean.
But the current spec does not unreasonably suggest to do this.

The OEM SSL implementation that we started shipping in 2000/2001
never contained an implementation of SSLv2, but it did contain the
option for the server to accept a SSL 2.0 CLIENT-HELLO as the first
message of an SSLv3 handshake (as described in rfc-5246 appendix E.2),
and for the client side to send an SSL 2.0 CLIENT-HELLO as the first
message of an SSLv3 handshake.

Our servers have since been accepting SSL 2.0 CLIENT-HELLOS as the
first handshake message.  There is no point for clients that don't
even implement SSLv2 to send an SSL 2.0 CLIENT-HELLO, other than
testing with the server side, so hardwired the client to never
send an SSL 2.0 CLIENT-HELLO for our apps in 2001.  This
matches rfc-5246 appendix E.2 just fine.

AFAIK, Firefox had been sending SSL 2.0 CLIENT-HELLO by default
up until 3.0.[0123?] versions and prior.  I'm still using a few
Linux Installations with Firefox 2.0 and one with Firefox 1.5 today.
(with no plugins, active content disabled and only for a small number
 of sites, behind a home NAT and a junkbuster that adjust User-Agent:),
and I'm likely going to use it like that for a couple of more years,
and there would be no benefit to waste several days to upgrade these
environments.  They're magnitudes safer than Joe Averages Windows with
MSIE with active content, plenty of plugins (acrobat,shockwave,flash)
ICQ, Messenger and surfing the entire internet.

Actually, with every day going by, the risks associated with
my old installations decrease further, while the risk of fairly new
installations are monotonically increasing every day.

-Martin

---

From: Geoffrey Keating <[email-masked]>
Date: 15 Sep 2010 13:27:12 -0700

>    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.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 16 Sep 2010 23:13:59 +0200

>  conflict with rfc2119 section 6.

This is exactly my preference too.  Thanks for expressing it so clearly.

/Simon