Re: [TLS] Confirming consensus about one

Martin Rex <mrex@sap.com> Wed, 27 January 2010 21:15 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 42FC33A6902 for <tls@core3.amsl.com>; Wed, 27 Jan 2010 13:15:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 scDSt2FUjetx for <tls@core3.amsl.com>; Wed, 27 Jan 2010 13:15:58 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 487AF3A688C for <tls@ietf.org>; Wed, 27 Jan 2010 13:15:55 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o0RLG77l028178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jan 2010 22:16:07 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201001272116.o0RLG69w008492@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com (Marsh Ray)
Date: Wed, 27 Jan 2010 22:16:06 +0100 (MET)
In-Reply-To: <4B60A132.4030007@extendedsubset.com> from "Marsh Ray" at Jan 27, 10 02:25:22 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Confirming consensus about one
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, 27 Jan 2010 21:15:59 -0000

Marsh Ray wrote:
> 
> Martin Rex wrote:
> > It is necessary to actually perform an old-renegotiaion successfully
> >   
> 
> It is impossible for an implementation of the SSLv3 or TLS specs to 
> perform an "old-renegotiaion successfully" unless your definition of 
> "success" accepts the possibility of a MitM remixing the plaintext.
> 
> Since SSL/TLS have promised to provide data integrity protection since 
> the beginning, everything which follows in your analysis is irrelevant.

You can call it "in an interoperable fashion", if you prefer that.
The IETF is all about interoperability, even though the security
area is known (and frowned upon) for providing the most feature-rich
set of policy options with the purpose of breaking^H^H^H^H^H^H^H^H limiting
or "constraining" interoperability.
 

It refers to interoperability where at least one of the TLS peers
implements one of the existing protocol SSLv3 or TLSv1.0->1.2 but
not the TLS extension RI update.

Providing the interoperability in the protocol is the task of
the IETF TLS WG, implementing interoperability with the installed
base correctly is the task for the TLS implementor,
and deciding and configuring whether interoperability with
old peers on renegotiation handshakes is necessary, is the task
of the consumer of the technology (configurable policy options).


-Martin