[TLS] Fw: renego, patricide, putting out to stud, etc.
"tom.petch" <firstname.lastname@example.org> Wed, 06 January 2010 10:07 UTC
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0CA3A6835 for <email@example.com>; Wed, 6 Jan 2010 02:07:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([18.104.22.168]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rIHDi5-W-tq for <firstname.lastname@example.org>; 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 [22.214.171.124]) by core3.amsl.com (Postfix) with ESMTP id A7DE23A681D for <email@example.com>; Wed, 6 Jan 2010 02:07:35 -0800 (PST)
X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106
X-IronPort-AV: E=Sophos;i="4.49,228,1262563200"; d="scan'208";a="170971001"
Received: from 1cust33.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([126.96.36.199]) by smtp.pipex.tiscali.co.uk with SMTP; 06 Jan 2010 10:07:31 +0000
From: "tom.petch" <firstname.lastname@example.org>
To: "tls" <email@example.com>
Date: Wed, 6 Jan 2010 09:29:43 +0100
Content-Type: text/plain; charset="UTF-8"
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.
Reply-To: "tom.petch" <firstname.lastname@example.org>
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:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:firstname.lastname@example.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" <email@example.com> To: "Ravi Ganesan" <firstname.lastname@example.org> Cc: <email@example.com> Sent: Saturday, January 02, 2010 4:26 PM Subject: Re: [TLS] renego, patricide, putting out to stud, etc. > ----- Original Message ----- > From: "Ravi Ganesan" <firstname.lastname@example.org> > 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 <email@example.com> > > > Subject: Re: [TLS] sessions, contexts, etc. > > > To: firstname.lastname@example.org > > > Message-ID: > > > <email@example.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. > > > > > >
- [TLS] renego, patricide, putting out to stud, etc. Ravi Ganesan
- Re: [TLS] renego, patricide, putting out to stud,… David-Sarah Hopwood
- Re: [TLS] renego, patricide, putting out to stud,… Ravi Ganesan
- Re: [TLS] renego, patricide, putting out to stud,… Michael D'Errico
- Re: [TLS] renego, patricide, putting out to stud,… Marsh Ray
- [TLS] Fw: renego, patricide, putting out to stud,… tom.petch