Re: [TLS] sessions, contexts, etc.

[David-Sarah Hopwood <[e-mail]>]

Ravi Ganesan wrote:
> 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.

That (the last sentence) is not the case, as far as I'm aware. Renegotiating
on some connection currently associated with a session does not mean that
that session can no longer be resumed.

> 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.

Ditto.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com