Re: [TLS] sessions, contexts, etc.

"tom.petch" <cfinss@dial.pipex.com> Thu, 31 December 2009 13:42 UTC

Return-Path: <cfinss@dial.pipex.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7114A3A67FD for <tls@core3.amsl.com>; Thu, 31 Dec 2009 05:42:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.055
X-Spam-Level:
X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovUMWn3EtNzj for <tls@core3.amsl.com>; Thu, 31 Dec 2009 05:42:38 -0800 (PST)
Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 196A73A680B for <tls@ietf.org>; Thu, 31 Dec 2009 05:42:37 -0800 (PST)
X-Trace: 280924541/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.62/None/cfinss@dial.pipex.com
X-SBRS: None
X-RemoteIP: 62.188.105.62
X-IP-MAIL-FROM: cfinss@dial.pipex.com
X-SMTP-AUTH:
X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ar0EAPY4PEs+vGk+/2dsb2JhbACCWxh2hEqIS7VdjTsKgSOCLlYE
X-IronPort-AV: E=Sophos;i="4.47,482,1257120000"; d="scan'208";a="280924541"
X-IP-Direction: IN
Received: from 1cust62.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.62]) by smtp.pipex.tiscali.co.uk with SMTP; 31 Dec 2009 13:42:16 +0000
Message-ID: <000601ca8a16$bd002f60$0601a8c0@allison>
From: "tom.petch" <cfinss@dial.pipex.com>
To: Ravi Ganesan <ravi@findravi.com>, tls@ietf.org
References: <3561bdcc0912301646p65923143t1b138fb17b75d9@mail.gmail.com>
Date: Thu, 31 Dec 2009 13:36:07 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: Re: [TLS] sessions, contexts, etc.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "tom.petch" <cfinss@dial.pipex.com>
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Dec 2009 13:42:39 -0000

---- Original Message -----
From: "Ravi Ganesan" <ravi@findravi.com>
Sent: Thursday, December 31, 2009 1:46 AM

> Does something along these lines work as a pedagogical device? Nodes
> characterized by the parameters of relevance. A root node, three types of
> ways to spawn a child node. What a child inherits from parent, etc...
>
> At the end of a TLS handshake, the Client and the Server share six key
> pieces of information:
> (i) a session-id  /*Public information */
> (ii) a shared master-secret /*Secret. Known only to Client and Server */
> (iii) the client-random and /* May be public or secret */
> (iv) the server-random.  /*May be public or secret*/
> (v) authentication knowledge /* Namely, the Client MAY know that is has
> authenticated the Server (in practice this almost always is true). The
> Server MAY know that it has authenticated the Client (relatively rare in
> practice, but an important sub-category).
> (vi) renegotiation-information /*The newly introduced RI field at the end of
> the handshake. */
>
> When the  Client and a Server share NONE of the above six pieces of data,
> the Client will typically initiate a completely fresh session using the FULL
> handshake.  Such a session is called a ROOT session. A Client and a Server
> who have completed a ROOT session can engage in further handshakes to create
> new sessions, which in turn can create further sessions. Treating each
> session as a node in a graph we can get a tree rooted at the ROOT.

I fear that this muddies the waters.  You seem to be using session for
what Nelson would call - pro tem - 'that TLS session/connection instance
thing'.  I think this wrong as session already has a separate semantic.

> Each node can spawn a child node using three different techniques as
> follows:
>
> i) A node can create a child-node by performing an abbreviated handshake.
> Such an abbreviated-child inherits the session-id, the shared master-secret
> and the authentication-knowledge, from its parent (these CANNOT change). It
> gets new client-random, server-random and starts afresh with
> renegotiation-information.  This technique of spawning a child node is
> usually used for efficiency considerations (abbrv. handshake requires no PKI
> operations, which is why it cannot be used to update
> authentication-knowledge of the other end either).  The creation of such a
> child-node does NOT result in the previous node becoming inactive.
>
> ii) A node can create a child node by performing renegotiation, followed by
> a full handshake. Such a full-renego-child, starts afresh with new values

Again, I think this muddies the waters.  Renegotiation is not defined, but
the text in RFC5246 makes it clear to me that it starts with HelloRequest
or ClientHello and what is this last if not a handshake?  Abolish the word
renegotiation from this lexicon:-)  When we have the right terminology for
'that TLS session/connection instance thing', then we will be able to
characterise types of handshakes better and should have no need for it.

Tom Petch

> for all of the first five parameters. The only parameter which keeps it tied
> to this tree is the renegotiation-information, which is derived from the
> handshake and the parent-node's renegotiation-information. The primary
> use-case for this technique is  to update authentication-knowledge of the
> Server (i.e. does it know who the Client is?).  The creation of such a child
> node means the parent node can no longer be used.
>
> iii) A node can create a child node by performing renegotiation followed by
> an abbreviated handshake. Such a abbrv-renego-child inherits the session-id,
> shared-master-secret and authentication-information of its parent. There is
> a new client-random and server-random, and as in a full-renego-child, the
> renegotiation-information is derived from the handshake and the the
> renegotiation-information of its parent.  I do not know why this use-case
> exists; the encryption/hashing keys change but it is questionable if that
> adds any protection. The creation of such a child node means the parent node
> can no longer be used.
>
> Observe that each of the different child nodes can give birth to any of the
> other three types of children.
>


--------------------------------------------------------------------------------


> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>