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

["tom.petch" <[e-mail]>]

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

Tom Petch

----- Original Message -----
From: "tom.petch" <[e-mail]>
To: "Ravi Ganesan" <[e-mail]>
Cc: <[e-mail]>
Sent: Saturday, January 02, 2010 4:26 PM
Subject: Re: [TLS] renego, patricide, putting out to stud, etc.

> ----- Original Message -----
> From: "Ravi Ganesan" <[e-mail]>
> 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 <[e-mail]>
> > > Subject: Re: [TLS] sessions, contexts, etc.
> > > To: [e-mail]
> > > Message-ID:
> > >        <[e-mail]>
> > > 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.
> > >
> > >