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

Nelson B Bolyard <> Fri, 25 December 2009 00:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE2253A694A for <>; Thu, 24 Dec 2009 16:23:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.506
X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Tkp16vUTWLXY for <>; Thu, 24 Dec 2009 16:23:35 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 80F2F3A67E3 for <>; Thu, 24 Dec 2009 16:23:35 -0800 (PST)
Received: (qmail 6163 invoked from network); 25 Dec 2009 00:23:17 -0000
Received: from unknown ( by ( with ESMTP; 25 Dec 2009 00:23:16 -0000
Message-ID: <>
Date: Thu, 24 Dec 2009 16:23:37 -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: <> <>
In-Reply-To: <>
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: Fri, 25 Dec 2009 00:23:36 -0000

On 2009-12-24 15:22 PST, Michael D'Errico wrote:
> Nelson B Bolyard wrote:
>> 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?
> 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.

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