Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV

Martin Rex <mrex@sap.com> Fri, 11 December 2009 16:58 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D6FB3A69FE for <tls@core3.amsl.com>; Fri, 11 Dec 2009 08:58:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.193
X-Spam-Level:
X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffEwVnGJkeAE for <tls@core3.amsl.com>; Fri, 11 Dec 2009 08:58:08 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 3F8FC3A67A4 for <tls@ietf.org>; Fri, 11 Dec 2009 08:58:08 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBBGvrQe000396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Dec 2009 17:57:53 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912111657.nBBGvqCC015029@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com
Date: Fri, 11 Dec 2009 17:57:52 +0100
In-Reply-To: <4B227458.9080007@extendedsubset.com> from "Marsh Ray" at Dec 11, 9 10:33:28 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Dec 2009 16:58:09 -0000

Marsh Ray wrote:
> 
> David-Sarah Hopwood wrote:
> > 
> > Why? What is the point of allowing the client to send an empty extension,
> > when a patched client MUST send the MSCV, and a patched server MUST use
> > *only* the MSCV to determine whether the client is patched? You'd just be
> > adding the option to send an extension that has no defined meaning.
> 
> I would like for the decisions we make today to allow the MCSV hack to
> be retired at some point in the future. MCSV represents extra complexity
> that we added as a concession for interoperability with obsolete and
> out-of-spec systems.  We all have to make compromises in life and
> protocol design, but it is better to do it in such a way that they
> eventually pass into history rather than build up over time.
> 
> Today there are many clients which never interoperate with
> extensions-intolerant servers. If at all possible, these should have the
> option of not sending the MCSV hack from the beginning.

Today there are many car owners that are not involved in car accidents,
we should get rid of liability insurances for cars.

The problem with this reasoning is, that you only know _after_ the
fact whether you needed it or not.

You're actually suggesting that Browser vendors split their codebase
in two (one with backwards interop and one without) for the gigantic
gain of saving 10 LoC in one of the then two different lines of code?


When browser vendors emphasize they know exactly when the last pre-trusted
RootCA cert they're shipping is dropped from their distribution, then
they boldly assume this is the time when no-one needs MD5-support anymore,
completely ignoring the much higher numbers of non-commercial CAs that a
lot of companies are using, self-signed certs, certs installed on
devices and more.  MD5 may be bad, but it is still better than nothing.

Removing vital functionality in a knee-jerk reaction just because
some implementer sees no more use for it in his personal environment
might not be a very good idea.

OK, if you're working for a software vendor and are looking for an
extremely extended Xmas vacation, this might be an option to make
it happen...

-Martin