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

Nicolas Williams <Nicolas.Williams@sun.com> Wed, 04 November 2009 18:30 UTC

Return-Path: <Nicolas.Williams@sun.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 E23133A67B0 for <tls@core3.amsl.com>; Wed, 4 Nov 2009 10:30:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.045
X-Spam-Level:
X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 xaGWR7m7oV8v for <tls@core3.amsl.com>; Wed, 4 Nov 2009 10:30:16 -0800 (PST)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id A9D103A62C1 for <tls@ietf.org>; Wed, 4 Nov 2009 10:30:16 -0800 (PST)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA4IUb7m011778 for <tls@ietf.org>; Wed, 4 Nov 2009 18:30:37 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nA4IUauX003722 for <tls@ietf.org>; Wed, 4 Nov 2009 11:30:37 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA4IJ8Wu008272; Wed, 4 Nov 2009 12:19:08 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA4IJ8T2008271; Wed, 4 Nov 2009 12:19:08 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Wed, 4 Nov 2009 12:19:08 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: mrex@sap.com
Message-ID: <20091104181907.GZ1105@Sun.COM>
References: <20091103222451.GK1105@Sun.COM> <200911040116.nA41GTLP006808@fs4113.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200911040116.nA41GTLP006808@fs4113.wdf.sap.corp>
User-Agent: Mutt/1.5.7i
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
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 18:30:18 -0000

On Wed, Nov 04, 2009 at 02:16:29AM +0100, Martin Rex wrote:
> 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.

The desired semantic is that tls-unique channel bindings are a channel
binding in the RFC5056 sense, for a "TLS channel", with this particular
feature (from the I-D):

   o  Channel binding type: unique

(which RFC5056 defines).

See my follow-up, just now, that begins with that same text.

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

The latter: the client's Finished message from a handshake that is not
protected by any other TLS connection, and regardless of whether the
handshake is a session resumption handshake.

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

No.  This is not about whether the client or server are authenticated.
Authentication in the TLS layer is irrelevant to the channel binding.

We want to be able to bind to anon-anon TLS connections.

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

Re-negotiation is not an issue: it suffices to use a channel binding for
the "first" connection, meaning: a connection whose handshake is not
protected by another connection, and NOT meaning: the one that
established a session that is being resumed.