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

Nicolas Williams <Nicolas.Williams@sun.com> Wed, 28 October 2009 21:05 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 C38F828C104; Wed, 28 Oct 2009 14:05:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.018
X-Spam-Level:
X-Spam-Status: No, score=-6.018 tagged_above=-999 required=5 tests=[AWL=0.028, 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 SzRPAwTuo+Ml; Wed, 28 Oct 2009 14:05:36 -0700 (PDT)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id C0A223A6989; Wed, 28 Oct 2009 14:05:35 -0700 (PDT)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9SL5pHS023180; Wed, 28 Oct 2009 21:05:51 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9SL5oIa039884; Wed, 28 Oct 2009 15:05:51 -0600 (MDT)
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 n9SKsOxx002768; Wed, 28 Oct 2009 15:54:24 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9SKsO3P002767; Wed, 28 Oct 2009 15:54:24 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Wed, 28 Oct 2009 15:54:24 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: mrex@sap.com
Message-ID: <20091028205423.GG1105@Sun.COM>
References: <20091028163322.GO1105@Sun.COM> <200910282049.n9SKnSdG000971@fs4113.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200910282049.n9SKnSdG000971@fs4113.wdf.sap.corp>
User-Agent: Mutt/1.5.7i
Cc: channel-binding@ietf.org, sasl@ietf.org, tls@ietf.org
Subject: Re: [TLS] [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, 28 Oct 2009 21:05:36 -0000

On Wed, Oct 28, 2009 at 09:49:28PM +0100, Martin Rex wrote:
> Nicolas Williams wrote:
> > 
> > Here, then, is my proposed clarification:
> > 
> >    Description: The client's TLS Finished message (note: the Finished 
> >    struct) from the first handshake of the TLS session.
> > 
> > (Yes, I changed "connection" to "session", followed by this:)
> > 
> >    Clarification: If a connection resumes a previous session, then the
> >    Finished message to use is that of the new session, not the one from
> >    the original session.  If a session has multiple handshakes and,
> >    therefore, multiple client Finished messages, the first client
> >    Finished message of that session is the one to use as the tls-unique
> >    channel binding.
> 
> This description/terminology about resume/previous/new/original session
> is confusing and wrong.
> 
> 
> If a TLS session is resumed, then the result is always the SAME session,
> which is indicated by the use of the SAME session id (and internally,
> by the use of the same underlying master secret).

Yes, I know.  That's why we had written "connection" instead of session!
But now Larry finds that confusing as well.

> A cached TLS session can be resumed quite often and simultaneously is
> parallel (which leads to multiple parallel/forked sessions).
> 
> The session keys are newly re-derived for each connection and each
> session resume, and they should be unique because of the client
> random and server random that go into the session key derivation
> of every new connection (=resumed session).
> 
> A resumed TLS session will also NOT exchange (and therefore not verify)
> any certificates.

Indeed.  But it does exchange Finished messages.  That's crucial here.

> Since the finished messages of the tls handshake cover the
> client random and server random of the SSL handshake, the finished
> messages are going to be unique for each connection, even for
> two resumes of the same session.

Exactly.  That's what we want.

> >                      From an application programming interface (API)
> >    perspective, the client's Finished message is saved in the contextual
> >    object handle that the client and server applications obtain when
> >    they initiate or resume a TLS session; later, when the applications
> >    request the tls-unique channel binding, the TLS implementation
> >    retrieves the saved first client Finished message from that context
> >    handle.
> 
> Asking the TLS protocol stack to memorize the original finished message
> sounds awkward to me.  The thing that the ssl session cache is already
> memorizing for a session is the master secret, so maybe deriving something
> from that would be better suited for the purpose than a requirement to
> store the original finished message.

Argh, I've managed to confuse you too.  I mean EXACTLY this: it's NOT
the client Finished message from the _session_ that is being resumed
(when one is), but the one for the connection.

Martin,

I appreciate your help, but we really need to hear from Larry, because
I'm all confused, and as a result I'm confusing you too.

Larry, can you please clarify?

Nico
--