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

From: Ravi Ganesan <[email-masked]>
Date: Wed, 30 Dec 2009 22:20:15 -0800

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

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

What I meant by 'that node can no longer be used', is that since the
effective encryption/hashing keys have been rolled over,
trying to send data using the values in that node to the side should
not work. In that sense either of the renego child nodes renders its
parent inactive.
It did occur to me that the node while it cannot be 'used' (per my
def) might still be able to have progeny (put out to stud if you
will!).
I just figured that one could get an identical result by using the
parameters in the child to do the "resume", and that would be
preferable.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 31 Dec 2009 20:03:20 +0000

> not work. In that sense either of the renego child nodes renders its

OK, but that's a fairly complicated way of describing the semantics. Also
you used the term "session" to describe the nodes:

# Treating each session as a node in a graph we can get a tree rooted at
# the ROOT.

which is not consistent with "that node can no longer be used", since the
*session* can be reused.

Per connection, the progression of connection states is linear, not a tree,
and that's the simplest way of describing it.

--

---

From: Ravi Ganesan <[email-masked]>
Date: Thu, 31 Dec 2009 15:42:50 -0800

>> 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, 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-masked]>
> Subject: Re: [TLS] sessions, contexts, etc.
> To: [email-masked]
> Message-ID:
>        <[email-masked]>
> 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.
>
> 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.
>
>

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 31 Dec 2009 17:19:09 -0800

It's not really parent-child, it is actually more like cloning and
metamorphosis.

Mike

Ravi Ganesan wrote:
> unintended baggage, 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).
> useful even for regular TLS. Especially since we are keeping chained 
> hashes around.
> 
> 
>     Message: 1
>     From: Ravi Ganesan <[email-masked] <mailto:[email-masked]>>
>     To: [email-masked] <mailto:[email-masked]>
>     Message-ID:
>            <[email-masked]
>     <mailto:[email-masked]>>
>     (vi) renegotiation-information /*The newly introduced RI field at
>     the end of
>     the handshake. */
> 
> 
>     the Client will typically initiate a completely fresh session using
>     the FULL
>     who have completed a ROOT session can engage in further handshakes
>     to create
>     usually used for efficiency considerations (abbrv. handshake
>     requires no PKI
>     adds any protection. The creation of such a child node means the
>     parent node
>     can no longer be used.
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Marsh Ray <[email-masked]>
Date: Thu, 31 Dec 2009 19:42:18 -0600

Ravi Ganesan wrote:
> [...]
> TLS to "sockets" or "connections", needlessly.

The TLS spec doesn't use the term "socket" anywhere.

> For instance  what does
> a connection mean if the binding is not TCP?

A TLS connection is pretty fundamental.

>From the application layer's perspective, the connection is a conduit
through which it may send and receive application data with the benefit
of the security guarantees of TLS.

At the TLS record layer, a connection is a sequence of TLS records with
consistent framing, record sequence numbers, MAC and crypto params.

TLS needs to ride on some reliable and ordered transport, but it doesn't
 have to be TCP. A few places in the TLS spec say certain errors must
"terminate the connection", but it can't really mandate the behavior of
lower levels. (E.g., an application using starttls could drop back to
the unencrypted protocol rather than actually closing the TCP connection).

- Marsh