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

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

On 2009-12-29 08:13 PST, tom.petch wrote:
>>> Nelson B Bolyard wrote:

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

Well, yes, it was my understanding that each handshake does indeed generate
a new secure channel with its own bindings.  Each has its own pair of
Finished messages, which are the identifiers of the bound channel (are they
not?) in the TLS channel binding proposal/draft/RFC (whatever it is today).
Therefore, it would seem wrong to me to allow a "TLS channel", identified
by the contents of one pair of finished messages, to be used to
identify/bind to another channel that was the result of another handshake.

In any case, I want to hang a name on that thing that changes with every
handshake.  Clearly the new renegotiation scheme creates another thing that
can survive renegotiations, and that should also have a name that is
distinct from the name for the thing I'm trying to name.

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

If "TLS Channel" more accurately describes that thing that survives
renegotiations, then I would withdraw my proposal to use that name for the
thing that changes with every renegotiation.  I am inclined to ask Nico to
make that call.

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

Maybe we'd find some more ideas for names in some old standards such as
ANSI X9.17

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

Regards,
/Nelson Bolyard