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

Chris Newman <Chris.Newman@Sun.COM> Fri, 04 December 2009 23:54 UTC

MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-disposition: inline
Content-type: text/plain; CHARSET="US-ASCII"; format="flowed"
Date: Fri, 04 Dec 2009 15:54:16 -0800
From: Chris Newman <Chris.Newman@Sun.COM>
Sender: Chris.Newman@Sun.COM
To: mrex@sap.com
Message-id: <5B460507C5B45BE8C29D4E33@446E7922C82D299DB29D899F>
Cc: tls@ietf.org
Subject: [TLS] backwards compatiblity philosophy and MCSV (was Re: Last Call: draft-ietf-tls-renegotiation)
Precedence: list

--On December 2, 2009 20:30:09 +0100 Martin Rex <mrex@sap.com> 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

[TLS] backwards compatiblity philosophy and MCSV … Chris Newman
Re: [TLS] backwards compatiblity philosophy and M… Marsh Ray
Re: [TLS] backwards compatiblity philosophy and M… Nelson B Bolyard