Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt call comments (st Call:

Martin Rex <Martin.Rex@sap.com> Wed, 04 November 2009 01:16 UTC

Return-Path: <Martin.Rex@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 CD7143A67A3 for <tls@core3.amsl.com>; Tue, 3 Nov 2009 17:16:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.204
X-Spam-Level:
X-Spam-Status: No, score=-6.204 tagged_above=-999 required=5 tests=[AWL=0.045, 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 GHe-L5QL2SNe for <tls@core3.amsl.com>; Tue, 3 Nov 2009 17:16:11 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id B99783A62C1 for <tls@ietf.org>; Tue, 3 Nov 2009 17:16:10 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA41GUFc019667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Nov 2009 02:16:30 +0100 (MET)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200911040116.nA41GTLP006808@fs4113.wdf.sap.corp>
To: Nicolas.Williams@sun.com
Date: Wed, 04 Nov 2009 02:16:29 +0100
In-Reply-To: <20091103222451.GK1105@Sun.COM> from "Nicolas Williams" at Nov 3, 9 04:24:51 pm
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] [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt call comments (st Call:
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, 04 Nov 2009 01:16:11 -0000

Nicolas Williams wrote:
> 
> On Mon, Nov 02, 2009 at 04:55:48PM +0100, Simon Josefsson wrote:
> > Martin Rex <Martin.Rex@sap.com> writes:
> > 
> > > It might be easier to _NOT_ key on the finished message, but on the
> > > master secret instead.
> > 
> > That was my conclusion as well, hence
> > http://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-00
> > which uses the TLS PRF interface.
> > 
> > For -02 I also added hashing the Finished message, to match the
> > semantics for connection/session (regardless of its definition) of
> > draft-altman-tls-channel-bindings, but I'd prefer to avoid it
> > completely.
> 
> I don't agree.  That it's easier to speak of the master secret is not
> enough.  The Finished message's construction provides better binding of
> the entire negotiation (up to that Finished message), and that's why we
> chose it.
 

I have not yet understood what semantics you and Larry are actually
looking for.

Is it (1)
about binding to a specific incarnation of a TLS session
over one single network connection, then TLS PRF would be OK.
Using the Finished message of the TLS handshake (independent
of whether it was a full handshake or a resume) would be
equivalent.


Or is it (2)
about binding to a particular full TLS handshake (and the
authentication of one of both peers in that full TLS handshake),
so that it can be used on several parallel connections and with short
interruptions of the network connection, provided that TLS session
caching is used and works correctly.


TLS session renegotiation reshuffles the cards, so any kind of
channel binding or TLS PRF usage must be deferred until
the urge for renegotiation among the peers has been fully
saturated/quenched to both peers satisfaction.


-Martin