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

Kyle Rose <krose@krose.org> Mon, 02 November 2015 03:52 UTC

MIME-Version: 1.0
In-Reply-To: <CAJU8_nVeTB=+t+OZJzj7da9mmn0J1afjP-HGXw63TkykVMLM9w@mail.gmail.com>
References: <CAJU8_nVeTB=+t+OZJzj7da9mmn0J1afjP-HGXw63TkykVMLM9w@mail.gmail.com>
Date: Sun, 01 Nov 2015 22:52:07 -0500
Message-ID: <CAJU8_nWH4G-GZSTQt+1sr8cOVXGVq5TJSQEn0Hxu2oK1zv2FHQ@mail.gmail.com>
From: Kyle Rose <krose@krose.org>
To: tcpinc <tcpinc@ietf.org>
Content-Type: multipart/alternative; boundary="001a1140ed047b7901052386b368"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpinc/z2I_xK0-RCGMR0kyA_ge4yJgqWQ>
Subject: [tcpinc] draft-bittau-tcpinc-tcpcrypt-04 session cache behavior
Precedence: list

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

[tcpinc] draft-bittau-tcpinc-tcpcrypt-04 session … Kyle Rose
Re: [tcpinc] draft-bittau-tcpinc-tcpcrypt-04 sess… David Mazieres
Re: [tcpinc] draft-bittau-tcpinc-tcpcrypt-04 sess… Kyle Rose
Re: [tcpinc] draft-bittau-tcpinc-tcpcrypt-04 sess… Kyle Rose