[TLS] Fw: renego, patricide, putting out to stud, etc.

"tom.petch" <cfinss@dial.pipex.com> Wed, 06 January 2010 10:07 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 7C0CA3A6835 for <tls@core3.amsl.com>; Wed, 6 Jan 2010 02:07:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 2rIHDi5-W-tq for <tls@core3.amsl.com>; Wed, 6 Jan 2010 02:07:36 -0800 (PST)
Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id A7DE23A681D for <tls@ietf.org>; Wed, 6 Jan 2010 02:07:35 -0800 (PST)
X-Trace: 170971001/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.33/None/cfinss@dial.pipex.com
X-SBRS: None
X-RemoteIP: 62.188.105.33
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: AqEFANDvQ0s+vGkh/2dsb2JhbACCUYEOhEuIWLUljG8KgSKCLlYE
X-IronPort-AV: E=Sophos;i="4.49,228,1262563200"; d="scan'208";a="170971001"
X-IP-Direction: IN
Received: from 1cust33.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.33]) by smtp.pipex.tiscali.co.uk with SMTP; 06 Jan 2010 10:07:31 +0000
Message-ID: <002001ca8eaf$b5d77de0$0601a8c0@allison>
From: "tom.petch" <cfinss@dial.pipex.com>
To: "tls" <tls@ietf.org>
Date: Wed, 6 Jan 2010 09:29:43 +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: [TLS] Fw: renego, patricide, putting out to stud, 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: Wed, 06 Jan 2010 10:07:37 -0000

Resending as it looks like this was a victim of the Y2.01K bug.

Tom Petch

----- Original Message -----
From: "tom.petch" <cfinss@dial.pipex.com>
To: "Ravi Ganesan" <ravi@findravi.com>
Cc: <tls@ietf.org>
Sent: Saturday, January 02, 2010 4:26 PM
Subject: Re: [TLS] renego, patricide, putting out to stud, etc.

> ----- Original Message -----
> From: "Ravi Ganesan" <ravi@findravi.com>
> Sent: Friday, January 01, 2010 12:42 AM
>
> > >> OK, but that's a fairly complicated way of describing the semantics. Also
> > >> you used the term "session" to describe the nodes:
> >
> > It is somewhat complicated, but I think it is the minimum needed. I just
> > feel getting into connections, sessions, channels, all words which carry
> > unintended baggage,

 Session is reasonably well-defined but I think that it is you that is
adding baggage to it which I find muddying the waters.

 Likewise renego(tiation) is not so well defined and IMO best
avoided.

 A session has a session identifier, supplied by the host.  Reuse
 that session identifier in a ClientHello and you are reusing
 that session; leave it blank and you have a new session
 (assuming that the host agrees and supplies a new session
 identifier).

 I agree absolutely that we need to explore the kind of
 scenarios that you describe below but
 I cannot make sense of your tree - and I think that Michael is
 right to call it cloning and metamorphosis - unless you tell me
 what you are doing with the session identifier and over which
 of many possible TCP connections you are doing it.

 Tom Petch

> >       does not seem to be working.  Just consider if I am the
> > Client and you are the Server, and we open a thingy (call it A) communicate
> > for a while. Use A to spawn two more thingys in parallel using abbreviated
> > handshakes (B and C). Then do a renego using full handshake on B (gives us
> > D). D then spawns two more thingys using abbreviated handshakes (E and F). F
> > happens to do a renego using a full handshakes to spawn G. In the meanwhile
> > we do a full handshake renego on A, and then.... you are asked to explain in
> > retrospect exactly what on earth happened. If you use my approach of tagging
> > each of the nodes A,B,C,D,E, F and G with the six variables (session-id,
> > master-secret, client-random, server-random, auth knowledge and RI), and
> > show which of them change from parent to child, you will end up with a
> > compact tree with the properties I mentioned.
> >
> > But of course I am biased, I feel it is limiting to use words that limit TLS
> > to "sockets" or "connections", needlessly.  For instance  what does a
> > connection mean if the binding is not TCP? e.g.  EKR's work on UDP, mine on
> > HTTP, Gajek et al on SOAP).
> > This bias aside, however, I think the tree with its state transitions is
> > useful even for regular TLS. Especially since we are keeping chained hashes
> > around.
> >
> >
> > Message: 1
> > > Date: Wed, 30 Dec 2009 16:46:49 -0800
> > > From: Ravi Ganesan <ravi@findravi.com>
> > > Subject: Re: [TLS] sessions, contexts, etc.
> > > To: tls@ietf.org
> > > Message-ID:
> > >        <3561bdcc0912301646p65923143t1b138fb17b75d9@mail.gmail.com>
> > > Content-Type: text/plain; charset="utf-8"
> > >
> > > 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.
> > >
> > > 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
> > > 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.
> > >
> > >