Subject: [tcpinc] draft-bittau-tcpinc-tcpcrypt-04 session cache behavior

From: Kyle Rose <[email-masked]>
Date: Sun, 1 Nov 2015 22:52:07 -0500

If a client opens two connections to a previously-known server in a short
period of time, what is the intended behavior of implementations?

If one session resumption attempt uses SID[i] and another SID[i+1], then if
they arrive out of order, should the server ignore (or simply not
recognize) SID[i+1] and initiate a new key agreement, but then accept
SID[i] when it eventually arrives?

What, then, should happen on the client? Should the client use SID[i+2] for
the next connection to this server, or will it use a different SID based on
the new key agreement?

Or, alternatively, should one connection use SID[i], and the next not send
a TCPCRYPT_RESUME because the previous handshake has not yet been completed?

I know this isn't specified in the draft because it's out-of-scope for the
protocol spec, but I think it's worth puzzling out how clients would
actually do this in the wild because this is likely to be a common case.

One way to resolve this is for clients only to ever have one SID[I] for a
given ss[] chain in-flight in a handshake, and request a new key agreement
otherwise; but to keep multiple chains for a given server cached so the
number of key agreements required over the session cache lifetime is
bounded by the maximum number of simultaneous handshake attempts rather
than by the total number of handshakes minus epsilon as it could otherwise
be in the pessimal case.

I will note that I'm not sure how this would work in the case of server
farms all responding for the same IP. Without state sharing, it seems like
session resumption wouldn't work at all without client stickiness, which is
one advantage of TLS's session ticket mechanism; but then with session
tickets and similar constructs you run into replay issues for early data on
0RT connections.

Kyle

---

From: David Mazieres <[email-masked]>
Date: Mon, 02 Nov 2015 14:16:31 -0800

> period of time, what is the intended behavior of implementations?

The keys are derived in such a way that you can precompute serveral
session IDs and associated keys without harming privacy.  So you can
easily tolerate a little bit of reordering.  Even if one of the SIDs
ends up not being used and you cache it for a long period of time, later
connections will still enjoy forward secrecy.

> tickets and similar constructs you run into replay issues for early data on

You are correct that this would require client stickiness.  Session
tickets are unlikely to meet the TCPINC charter's requirements for
forward secrecy.

David

---

From: Kyle Rose <[email-masked]>
Date: Tue, 3 Nov 2015 07:30:25 +0900

On Tue, Nov 3, 2015 at 7:16 AM, David Mazieres <
[email-masked]> wrote:

> session IDs and associated keys without harming privacy.

Sure; it's just not clear from the document that it's okay for a server to
accept SID[i+1] when it was expecting SID[i]:

"The active opener MUST use the lowest value of "i" that has not already
appeared in a resumption suboption exchanged with the same host and for the
same pre-session seed."

The MUST here seems to be implying that the only way to get the server to
recognize an SID is to choose the one it's expecting. Since SYN packets may
be reordered, this is best-effort.

> tickets are unlikely to meet the TCPINC charter's requirements for

I wasn't suggesting implementing session tickets; I'm just trying to
explore the consequences of this approach. It seems that without
complicating matters greatly (e.g., offering multiple SIDs, one for every
session the client has negotiated recently), the onus is on the server to
make session caching useful through client stickiness or state sharing.
Which is perfectly fine.

Kyle

---

From: Kyle Rose <[email-masked]>
Date: Tue, 3 Nov 2015 08:35:24 +0900

> Perhaps an extra sentence saying the passive opener MAY tolerate some
> reordering would clarify things?

That's probably fine. This feels like one of those cases where we want to
encourage implementations to be liberal in what they accept, as the
realities of network conditions guarantee that even following the spec to
the letter will not always result in clockwork operation.

Should the MUST be a SHOULD instead? The protocol still works even if the
active opener skips every other SID... They may simply not benefit from the
cached session, depending on how liberal the passive opener is.

Kyle