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

["tom.petch" <[e-mail]>]

----- Original Message -----
From: "Nelson B Bolyard" <[e-mail]>
Sent: Friday, December 25, 2009 1:23 AM

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

I think that nailing a term to this concept is an excellent idea.

As Marsh just said, and Nico amplified on 7Dec09, channel bindings
refers to the first such thing as long as subsequent renegotiations are bound to
the first (which the fixes under discussion would do); if they are not bound,
then each handshake would generate a new secure channel with its own bindings
which makes the use of 'channel' for 'thing' a bit flaky.

Back on 2Nov09, Nico seemed to refer to this thing as a TLS connection (and
cited Larry as using the term security context for the same concept).

But then, on 2Dec09, Eric agreed that TLS connection and TCP connection
were one-to-one which, since renegotiation can occur within a TCP connection,
would rule out TLS connection for this thing.

Plenty of synonyms in Roget (vide 'junction') but I would go for
(TLS|security) context.

Tom Petch

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