Subject: [TLS] backwards compatiblity philosophy and MCSV (was Re: Last Call: draft-ietf-tls-renegotiation)

From: Chris Newman <[email-masked]>
Date: Fri, 04 Dec 2009 15:54:16 -0800

--On December 2, 2009 20:30:09 +0100 Martin Rex <[email-masked]> wrote:
> I wrote up my proposal after realizing that some people just did
> not care about the obvious and serious disruptive nature for the
> interoperability in productive environments and existing usage scenarios
> of the original proposal which contained this:
>
>   4.3. SSLv3
> 				
>     SSLv3 does not support extensions and thus it is not possible to
>     securely renegotiate with SSLv3.

The crux of the philosophical difference we are having is how we treat 
backwards compatibility.

My position:

1. Backwards compatibility with IETF standards track RFCs is important.
2. Backwards compatibility with widely deployed critical software is 
important, although there are caveats if that software/maker demonstrated 
bad faith or if the accommodation mechanism is too expensive or heuristic.
3. Other forms of backwards compatibility are usually a bad thing.  They 
create code bloat and specification complexity that increases maintenance 
cost, necessary domain expertise training costs, and allows the standard to 
drift away from a clean architecture into a jumble of special cases.  Also 
rewarding vendors that ship incompliant implementations by accommodating 
them by default simply leads to more incompliant implementations and 
standards drift which is bad for consumers and the industry.

I'm now convinced there's enough SSLv3 out there that it falls into 
category 2, so the old section 4.3 was not acceptable -- we at least need 
to allow the RI extension to be added to SSLv3 implementations.  But 
extensions-intolerant servers fall into category 3 in my estimation unless 
I see compelling evidence they fall in category 2.

I used to be more willing to move things to category 2 when doing design 
work.  But after experiencing staff contractions during the tech bubble 
burst and recent recession, the cost of backwards compatibility baggage has 
become so clear to me that I set a high bar to put anything in category 2. 
Also I place a high value on extension mechanisms as every successful IETF 
protocol that lacked one eventually had to add it as a core protocol 
feature (POP, SMTP, TLS, LDAP, etc).  A protocol without clean 
extensibility is at best mis-designed and the sooner that is fixed, the 
better for all consumers of the protocol.

You seem to believe backwards compatibility is unquestionably a good thing, 
at least when fixing a security vulnerability.  We disagree on that point 
and I'm not likely to change my philosophy given my experience.

Right now I oppose MCSV but can live with the compromise in 
draft-ietf-tls-renegotiation-01 because I can choose not to generate that 
special case in my software and believe it will eventually go away.  If you 
want my support for MCSV, provide sufficient evidence to convince me that 
extensions-intolerant SSLv3 servers fall into category 2.  Otherwise we 
simply hold different positions and further discussion is pointless.

		- Chris

---

From: Marsh Ray <[email-masked]>
Date: Fri, 04 Dec 2009 19:19:59 -0600

Chris Newman wrote:
> important, although there are caveats if that software/maker
> demonstrated bad faith or if the accommodation mechanism is too
> expensive or heuristic.
> create code bloat and specification complexity that increases
> maintenance cost, necessary domain expertise training costs, and allows
> the standard to drift away from a clean architecture into a jumble of
> special cases.

Agree.

> Also rewarding vendors that ship incompliant
> implementations by accommodating them by default simply leads to more
> incompliant implementations and standards drift which is bad for
> consumers and the industry.

It's just this one message, Client Hello, is a special case because it
affects other systems as well. They get stuck in some slow failure
timeout mode which is a fate worse than, well, a fast failure.

It's a public health issue, like buying clean needles for junkies.

Getting these patches widely deployed can only help to get these crusty
old servers fixed or retired. The only way to ensure they're applied
everywhere is if they don't have any upgrade-ordering dependency (see
the recent great email from Michael Gray).

> category 2, so the old section 4.3 was not acceptable -- we at least
> need to allow the RI extension to be added to SSLv3 implementations. 
> But extensions-intolerant servers fall into category 3 in my estimation
> unless I see compelling evidence they fall in category 2.

I would put an SSLv3 extension-intolerant server in category 2 along
with SSLv3 itself.

A server that negotiates to TLS though that doesn't at least ignore
extensions properly? Category 3, but it needs to be patched anyway.

> burst and recent recession, the cost of backwards compatibility baggage
> has become so clear to me that I set a high bar to put anything in
> category 2.

Brokenness is a luxury we can ill afford.

> Also I place a high value on extension mechanisms as every
> successful IETF protocol that lacked one eventually had to add it as a
> core protocol feature (POP, SMTP, TLS, LDAP, etc).

Good in the lessons learned department.

>  A protocol without
> clean extensibility is at best mis-designed and the sooner that is
> fixed, the better for all consumers of the protocol.

It might be a little different for a crypto protocol. These things need
to be reviewed and certified, and making things too easy to reconfigure
on the fly or pass arbitrary data could raise questions.

> You seem to believe backwards compatibility is unquestionably a good
> thing, at least when fixing a security vulnerability.  We disagree on
> that point and I'm not likely to change my philosophy given my experience.

I think most of us see the exceptional nature of these circumstances.
The best philosophy in this case is adaptive pragmatism.

> draft-ietf-tls-renegotiation-01 because I can choose not to generate
> that special case in my software and believe it will eventually go
> away.

If we make the right decisions now, eventually it will.

> If you want my support for MCSV, provide sufficient evidence to
> convince me that extensions-intolerant SSLv3 servers fall into category
> 2.

Here goes:

>                           The SSL Protocol
>                             Version 3.0
>                   draft-freier-ssl-version3-02.txt
>...
> INTERNET-DRAFT                  SSL 3.0                November 18, 1996
>
>      struct {
>          HandshakeType msg_type;    /* handshake type */
>          uint24 length;             /* bytes in message */
>          select (HandshakeType) {
>              case hello_request: HelloRequest;
>              case client_hello: ClientHello;
>              case server_hello: ServerHello;
>              case certificate: Certificate;
>              case server_key_exchange: ServerKeyExchange;
>              case certificate_request: CertificateRequest;
>              case server_hello_done: ServerHelloDone;
>              case certificate_verify: CertificateVerify;
>              case client_key_exchange: ClientKeyExchange;
>              case finished: Finished;
>          } body;
>      } Handshake;
>...
>    The structure of the client hello is as follows.
>      struct {
>          ProtocolVersion client_version;
>          Random random;
>          SessionID session_id;
>          CipherSuite cipher_suites<2..2^16-1>;
>          CompressionMethod compression_methods<1..2^8-1>;
>      } ClientHello;
>...
>      struct {
>          ProtocolVersion server_version;
>          Random random;
>          SessionID session_id;
>          CipherSuite cipher_suite;
>          CompressionMethod compression_method;
>      } ServerHello;

These structures don't include any members for extension data.

I don't know about others, but when start coding something like this, I
like to copy and paste these definitions into my source file as line
comments and use those comments to frame a struct definition or parsing
code.

So here's what developers had to read and implement in order to ignore
Client Hello extensions:

>    Forward compatibility note:
>                   In the interests of forward compatibility, it is
>                   permitted for a client hello message to include
>                   extra data after the compression methods.  This data
>                   must be included in the handshake hashes, but must
>                   otherwise be ignored.

RFC 2246 TLS 1.0 (Jan 1999) adds the sentence:
>    This is the only handshake message for
>    which this is legal; for all other messages, the amount of data
>    in the message must match the description of the message precisely."

* It's just a "compatibility note" outside the formal structure definitions.

* No standard defines any structure for what the data might be, not even
a simple TLV format with an experimental numbering range. So even though
it says "it is permitted", still no one could use it.

* To properly support this it could amount to skipping ~2**24 bytes
(16MB) of data (uint24 length). Maybe later specs added some limitation,
or I'm not finding it? I wonder how many implementations today are
"fully standards-compliant" in this respect?

* There's no provision for extra data after Server Hello, so there
couldn't be any negotiation or confirmation of what you requested.

* No structure for this "extra data" was defined until RFC 3546 (TLS
Extensions) in June 2003 (6.5 years later). So TLS server
implementations designed before about 2004 probably had no compliant
clients with which to test that would send any data after the defined
ClientHello structure. All pre-Vista Windows OS's may be in this
category based on design date.

> Otherwise we simply hold different positions and further discussion
> is pointless.

Anyone that got this perfect back in 1996, I say "well done".

For those that didn't I have some sympathy.

But for those servers that have waited 6 or 13 years to fix it, jeez!
Well it's time to dust off that old compiler because we've got something
here that really needs patch patching (and you'll probably need to add
extension support).

- Marsh

---

From: Nelson B Bolyard <[email-masked]>
Date: Fri, 04 Dec 2009 17:50:14 -0800

>> the standard to drift away from a clean architecture into a jumble of

+1

[snip]

>> unless I see compelling evidence they fall in category 2.

I agree with Chris.

> I would put an SSLv3 extension-intolerant server in category 2 along

I wouldn't.

[big snip]

> But for those servers that have waited 6 or 13 years to fix it, jeez!

Exactly!  I had some sympathy for the ones that didn't get it perfect back
in 1998, which is why some products that use NSS have fallback.  But that
was 11 years ago!  My sympathy has long since run out.

> here that really needs patch patching (and you'll probably need to add

At the very least, add  the one line code change needed to ignore "extra
data after the compression methods" in client hellos.