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

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 24 Dec 2009 15:07:49 -0800

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?

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 24 Dec 2009 15:22:28 -0800

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

Mike

---

From: Marsh Ray <[email-masked]>
Date: Thu, 24 Dec 2009 17:32:09 -0600

Merry Chrismas, all.

> Believing that it is, I propose that we name it a "TLS channel".

/me winces

> Does that proposal cause anyone here any great pain?

To me, the term 'channel' seems to be heavily overloaded and it comes
with a nonzero amount of baggage from the channel binding work.

It doesn't "speak to me" as a precise thing the way (for example)
"connection state" does. It sounds like a term which people will place
their own meaning on and feel like they understand it, and other people
will do the same with slightly different meanings.

That said, I don't really have a better suggestion right now.

- Marsh

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 24 Dec 2009 16:23:37 -0800

> What if a session from an unrelated connection was resumed?

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

---

From: Marsh Ray <[email-masked]>
Date: Thu, 24 Dec 2009 18:46:05 -0600

Nelson B Bolyard wrote:
> Finished messages,

Yeah, that.

> which is probably why the TLS channel binding proposal

Last I read it, the channel bindings proposal considered the "channel"
to be identified by just the first pair of finished messages on the
connection and it held constant across subsequent renegotiations.

> do not reuse their "client random" and "server random" values, of course).

Now that wouldn't be very random of them.

> is not.

OK then, I won't let you know that I think it is.

> (Oh, and winces duly noted. )

- Marsh

---

From: "tom.petch" <[email-masked]>
Date: Tue, 29 Dec 2009 17:13:02 +0100

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

> wants to use the contents of the pair of TLS Finished messages as its

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

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 29 Dec 2009 10:33:00 -0800

> Plenty of synonyms in Roget (vide 'junction') but I would go for

Please don't use "context" to try to describe anything.  It is an
extremely overused term, and has a very vague meaning.  Plus there
are software libraries that call their data structures contexts,
which would cause confusion if that context was not identical to
whatever you start calling a context in the TLS spec.

Mike

---

From: Nelson B Bolyard <[email-masked]>
Date: Tue, 29 Dec 2009 14:28:49 -0800

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

> 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 

Regards,
/Nelson Bolyard

---

From: Marsh Ray <[email-masked]>
Date: Tue, 29 Dec 2009 16:56:10 -0600

Nelson B Bolyard wrote:
> 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

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.

> 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

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.

>> Plenty of synonyms in Roget (vide 'junction') but I would go for 

"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

---

From: "tom.petch" <[email-masked]>
Date: Thu, 31 Dec 2009 09:33:51 +0100

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

> refer to an "instance of a session on a connection", so it never really

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

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Marsh Ray <[email-masked]>
Date: Thu, 31 Dec 2009 10:54:38 -0600

tom.petch wrote:
> lack of terminology several times

No kidding.

> and there has also been some consensus

My impression is that there are a variety of reasons for that. For
example, many people have started to think about renegotiation and
session resumption seriously for the first time and there is an
inevitable learning curve.

It may help to have a paragraph in the spec just reiterating the
differences and some more detail in the glossary section. But at some
point, the RFCs are standards documents, not tutorials. They needs to
have the raw info that someone who's willing to invest months or years
into the spec to implement it correctly. Too much redundant explanation
tends to get in the way and runs the risk of introducing conflicting
statements.

The terms 'session', 'connection', and 'renegotiation' are adequately
described. The term 'rehandshake' should probably be replaced with a
more consistent term like 'renegotiation'.

> to communicate because of this lack).

It would be good to get that figured out. We can follow up off list if
you're concerned about the "DoS" on this list (as some have described it).

> And Nico has said he wants

With all due respect to the Channel Bindings work, we really really need
the renegotiation fix to be considered separately. The CB activity has
been going on for years and has a significant history. The RI fix has to
be safe, effective, and shippable yesterday.

The problem I see with 'connection state' is it's current definition:

> A TLS connection state is the operating environment of the TLS Record
>    Protocol.  It specifies a compression algorithm, and encryption
>    algorithm, and a MAC algorithm.  In addition, the parameters for
>    these algorithms are known: the MAC secret and the bulk encryption
>    keys for the connection in both the read and the write directions.
>    Logically, there are always four connection states outstanding: the
>    current read and write states, and the pending read and write states.
>    All records are processed under the current read and write states.

This verbiage is necessary because it describes the operation of the
protocol. Unfortunately, it doesn't really capture the idea of "an
instance of a session on the connection".

Maybe that's an inherently unclear notion due to the design of TLS.
After all, an unlimited amount of data can be transferred while the
client is in one connection state and the server is in another!

> survives renegotiations; etc. Nico may have Secure Channel lined up
> for that.

Everybody has always referred to that as a "TLS connection".

- Marsh