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

[Marsh Ray <[e-mail]>]

On 09/14/2010 10:54 PM, 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.
>
> [...] 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.

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