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

[Marsh Ray <[e-mail]>]

tom.petch wrote:
> From: "Marsh Ray" <[e-mail]>
>> 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

No kidding.

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

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

> (And I still think that there is an ambiguity in the I-D that I struggle
> 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
> 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)

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.

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

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!

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

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

- Marsh