Re: [TLS] backwards compatiblity philosophy and MCSV

[Nelson B Bolyard <[e-mail]>]

Chris Newman wrote:
>> 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.
> 
> Agree.

+1

[snip]

>> 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 agree with Chris.

On 2009-12-04 17:19 PST, Marsh Ray wrote:
> I would put an SSLv3 extension-intolerant server in category 2 along
> with SSLv3 itself.

I wouldn't.

[big snip]

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

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.

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

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