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

[Martin Rex <Martin.Rex at sap.com>]

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

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.

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

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

-Martin