Re: [TLS] Naming that TLS session/connection instance thing

[Nelson B Bolyard <[e-mail]>]

On 2009-12-24 15:22 PST, Michael D'Errico wrote:
> Nelson B Bolyard wrote:
>> In a posting in another thread today, Marsh Ray wrote:
>>
>>> Just keep in mind the many-to-many relationship between sessions and
>>> connections. A connection may handle multiple sessions (generally at
>>> different times) and a session may be on multiple connections
>>> (simultaneously or separated in time). An instance of a session on a
>>> connection is referred to as a "connection state".
>> It's also the thing to which a "TLS channel binding" binds, is it not?
>>
>> Believing that it is, I propose that we name it a "TLS channel".
>>
>> Does that proposal cause anyone here any great pain?
> 
> No pain, but I'd like some clarification.
> 
> I assume that if you make an initial connection to a server and perform
> a full handshake, you have created a new, independent TLS channel.
> 
> But now if you make another TCP connection to the same server and resume
> that session, has a new TLS channel been created?  Or is it the same one?
> 
> Also, let's say you just connected and performed a full handshake,
> creating a new TLS channel.  If you then renegotiate with the server
> using a full handshake, has a new TLS channel been created?  Or is it
> the same?
> 
> If you connect, full handshake, and then renegotiate using an old session
> (session resume), has a new TLS channel been created?  Does it depend on
> whether the resumed session was the original session on this connection?
> What if a session from an unrelated connection was resumed?
> 
> Thanks for any insight.

The "thing" on which I wanted to hang the name "TLS channel" is (in some
sense) defined by a cipher and a MAC and a pair of cipher keys and MAC
keys.  It is uniquely identified (IINM) by the contents of a pair of TLS
Finished messages, which is probably why the TLS channel binding proposal
wants to use the contents of the pair of TLS Finished messages as its
identifier (IINM).

Every handshake creates a new one, regardless of whether the handshake is
an initial negotiation or a renegotiation, and regardless of whether it
does a full or abbreviated handshake (assuming that the client and server
do not reuse their "client random" and "server random" values, of course).

I believe this is the thing to which Marsh was referring in his comment
which I quoted in my original posting.  Marsh, please let us know if it
is not.  (Oh, and winces duly noted. )