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

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

----- Original Message -----
From: "Marsh Ray" <[e-mail]>
Subject: Re: [TLS] Naming that TLS session/connection instance thing

> Nelson B Bolyard wrote:
> > 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.
>
> "Connection state" doesn't sound all that bad now. Probably I've been
> looking at it too much!
>
> > Clearly the new renegotiation scheme creates another thing that
> > can survive renegotiations,
>
> I don't think it creates a new thing, it just fulfills a guarantee that
> everyone thought had been there all along.
>
> > and that should also have a name that is
> > distinct from the name for the thing I'm trying to name.
>
> Everybody in the world (except us with our heads in the protocol specs
> and the implementation code) thinks of this as an "SSL socket" or "TLS
> connection".
>
> TLS is a "connection oriented" protocol, and the specs repeatedly use
> the term "connection" in talking about them.
>
> >> 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,
>
> It doesn't sound like it to me. "Channel" sounds deeply ambiguous and
> I'm still not sure that it's even the right concept.
>
> > 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
>
> The goal was not to create a new thing, but to fix an existing thing.
> Perhaps we don't need to find new names, but standardize the existing
> usage. Hmmm, except that strangely there really wasn't much need to
> refer to an "instance of a session on a connection", so it never really
> developed a good term.

But....
The lengthy threads over the past eight weeks have tripped over the
lack of terminology several times and there has also been some consensus
that RFC5246 and its predecessors are not as easy to follow as they
might be for their use of session, connection, renegotiation, rehandshake,...
(And I still think that there is an ambiguity in the I-D that I struggle
to communicate because of this lack).  And Nico has said he wants
this clarified as part of channel binding suggesting that
"draft-altman-tls-channel-bindings, which defines (or soon will) the term ought
to update RFC5246" (3Dec09)

We already have thing1, thing2, thing3, ... we are not creating anything new,
we just do not have terms for them, which costs time in misunderstandings
and, perhaps, makes defects such as the current one harder to spot.

For myself, I have litle concern as to what we call this if only we could
agree on a name; connection state would be fine (as would section, link...) .

And then we should go on to agree a name for the thing that - with the fix -
survives renegotiations; etc.  Nico may have Secure Channel lined up for
that.

Tom Petch

> >> Plenty of synonyms in Roget (vide 'junction') but I would go for
> >> (TLS|security) context.
>
> "Context" is what the MS SSPI calls it, but that is an extremely general
> interface which supports all kinds of auth packages. I think "context"
> ends up being an overly general name, to the point of meaninglessness.
>
> Regardless, I feel we should be prepared to ship the fix even if we
> don't have the nomenclature perfected. I believe in the importance of
> good names more than most, but in this case it's not worth holding up
> the protocol fix for even one more day for things that can be addressed
> in future documents.
>
> - Marsh
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls