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

Martin Rex <mrex@sap.com> Wed, 16 December 2009 15:30 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 E6F8E3A69CE for <tls@core3.amsl.com>; Wed, 16 Dec 2009 07:30:21 -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 si+Jm1PAXYXh for <tls@core3.amsl.com>; Wed, 16 Dec 2009 07:30:20 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 876423A69DE for <tls@ietf.org>; Wed, 16 Dec 2009 07:30:18 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBGFU1RM001427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 16:30:01 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912161530.nBGFU0av027619@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com
Date: Wed, 16 Dec 2009 16:30:00 +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 virwal05
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: Wed, 16 Dec 2009 15:30:22 -0000

Marsh Ray wrote:
> 
> 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.

MCSV is a very plain and simple backwards interoperability option,
and it will, in fact, make implementations easier (less code),
less bits-on-the-wire and more robust.


There is not only the wire-protocol to consider, but also the semantics
that TLS implementations have been providing to applications in the
installed base.  When an application has been requesting SSLv3 from
its TLS implementation in the past, then it probably did not distinguish
it's motivation for doing so -- whether it's a desire to _not_ use
TLS extensions, whether it's a desire to not use a higher protocol
version in the ClientHello, or whether the application knows that
it is trying to connect to an extensions-intolerant server.

The fact is, that we have established a specific semantic and
level expectation for such a request from the application,
and it would be very unwise to lightheartedly change such behaviour
in the installed base of largely unknown usage scenarios.

Doing the negotiation about updated implementations with
MCSV + ServerHelloExtension only will have the least amount
of impact on semantics and expectations in the installed base,
while providing all the functionality we need to protect
unsuspecting communication peers.

-Martin