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

Nelson B Bolyard <> Tue, 29 December 2009 22:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AACE93A69ED for <>; Tue, 29 Dec 2009 14:29:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.209
X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_35=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VWRU9axDvX-U for <>; Tue, 29 Dec 2009 14:29:19 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id CD5EC3A69B7 for <>; Tue, 29 Dec 2009 14:29:18 -0800 (PST)
Received: (qmail 20228 invoked from network); 29 Dec 2009 22:28:56 -0000
Received: from unknown ( by ( with ESMTP; 29 Dec 2009 22:28:56 -0000
Message-ID: <>
Date: Tue, 29 Dec 2009 14:28:49 -0800
From: Nelson B Bolyard <>
Organization: Network Security Services
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre
MIME-Version: 1.0
To: IETF TLS Working Group <>
References: <> <> <> <051b01ca88a1$e6bc6920$0601a8c0@allison>
In-Reply-To: <051b01ca88a1$e6bc6920$0601a8c0@allison>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Naming that TLS session/connection instance thing
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Dec 2009 22:29:19 -0000

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

/Nelson Bolyard