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

[Nicolas Williams <[e-mail]>]

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