Re: [TLS] sessions, contexts, etc.

[Ravi Ganesan <[e-mail]>]

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.