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

[Martin Rex <[e-mail]>]

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

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.


A new TLS session is created when one of
  - the client does not propose TLS session resume at all
  - the server does not agree to TLS session resumption, and
    creates and returns a new/different session id and
    performs a full handshake
  - the client performs a renegotiate for an established
    session (usually upon request from the server) and
    the server goes through a full ssl handshake.


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.


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


-Martin