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

Nicolas Williams <Nicolas.Williams@sun.com> Tue, 03 November 2009 22:35 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 A7F363A6831; Tue, 3 Nov 2009 14:35:06 -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 FdgmYQNaDAHg; Tue, 3 Nov 2009 14:35:05 -0800 (PST)
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id CB86C3A67D6; Tue, 3 Nov 2009 14:35:05 -0800 (PST)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA3MZNxi006393; Tue, 3 Nov 2009 22:35:23 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 nA3MZNQN029500; Tue, 3 Nov 2009 15:35:23 -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 nA3MNrrf007585; Tue, 3 Nov 2009 16:23:53 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA3MNrtr007584; Tue, 3 Nov 2009 16:23:53 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Tue, 3 Nov 2009 16:23:53 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: mrex@sap.com
Message-ID: <20091103222352.GJ1105@Sun.COM>
References: <20091030223647.GO1105@Sun.COM> <200911021459.nA2Exi67028763@fs4113.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200911021459.nA2Exi67028763@fs4113.wdf.sap.corp>
User-Agent: Mutt/1.5.7i
Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org
Subject: Re: [TLS] 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: Tue, 03 Nov 2009 22:35:06 -0000

On Mon, Nov 02, 2009 at 03:59:44PM +0100, Martin Rex wrote:
> Nicolas Williams wrote:
> > 
> > Another problem that Larry has is that in his implementation what I call
> > a "TLS connection" is called a "security context", and if the
> > application re-handshakes (e.g., to authenticate a user) then the result
> > is a second security context -- we need to be extra clear that it's the
> > client Finished message from the _first_ "security context" that we're
> > after.
> 
> OooopS.
> 
> The session that results from a re-handshake is an entirely new and
> independent session from what it started from, it does NOT modify
> the state of the original session (as identified by its TLS session ID).

What "oops"?  We need to identify one, and only one, client Finished
message to use.  The name of the thing that that message is related to
is only relevant to writing the text for this channel binding type's
definition.

> Many SSL protocol stacks, however, will perform the re-negotiation
> with the same "context" or API handle -- giving the application caller
> impression that the original session is modified.  TLS does _NOT_
> have capabilities to modify a session, however.  It will either
> resume a cached session as proposed by the client as-is, or it
> will go through a full handshake and create a new session
> that is entirely independent from previous sessions.
> 
> The TLS specs do not describe API semantics, however, only the
> network protocol and TLS session state, so your terminology is
> IMHO confusing.

All of that is irrelevant.

> > 
> > My proposal, then, is this:
> > 
> > OLD:
> > 
> >    Description: The client's TLS Finished message (note: the Finished
> >    struct) from the first handshake of the connection (note: connection,
> >    not session, so that the channel binding is specific to each
> >    connection regardless of whether session resumption is used).
> > 
> > NEW:
> > 
> >    Description: The client's TLS Finished message (note: the Finished
> >    struct) from the first handshake of the application's TLS connection.
> > 
> >    NOTES:
> > 
> >    a) If a session is resumed, the client's TLS Finished message from
> >       the session resumption handshake is to be used;
> > 
> >    b) If a client does multiple TLS handshakes in sequence, each
> >       protected by the previous one, then the client's TLS Finished
> >       message from the first/outermost TLS connection is to be used;
> > 
> >    c) By "TLS connection" we refer to the TLS connection state, not to
> >       any notion of connection of any underlying transport protocols
> >       (such as TCP, UDP, SCTP, etcetera).
> > 
> > I'm not sure that we can make it any clearer.
> 
> 
> b) sounds wrong to me.  A renegotiate results in a entirely
> new and independent session.

That a renegotiate does that is irrelevant.  What is relevant is that we
want the first Finished message.

> It might be easier to _NOT_ key on the finished message, but on the
> master secret instead.

Too late for that.

Nico
--