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

[Nicolas Williams <[e-mail]>]

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