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

Nicolas Williams <> Wed, 28 October 2009 21:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C38F828C104; Wed, 28 Oct 2009 14:05:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.018
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 ([]) by localhost ( []) (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 []) by (Postfix) with ESMTP id C0A223A6989; Wed, 28 Oct 2009 14:05:35 -0700 (PDT)
Received: from ([]) by (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 []) by (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 []) 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 using -f
Date: Wed, 28 Oct 2009 15:54:24 -0500
From: Nicolas Williams <>
Message-ID: <20091028205423.GG1105@Sun.COM>
References: <20091028163322.GO1105@Sun.COM> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.7i
Subject: Re: [TLS] [sasl] lasgt call comments (st Call:
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


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?