Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

[Benjamin Kaduk <[e-mail]>]

On 03/25/2016 02:41 PM, Colm MacCárthaigh wrote:
> On Fri, Mar 25, 2016 at 12:02 PM, Karthik Bhargavan
> <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     > +1 but I think we can go further here and specify 0RTT in such a way that it only works when the server
>     maintains state, and so that any given 0RTT ticket may only be
>     used once (to preserve forward secrecy as much as possible within
>     the constrains of 0RTT).
>
>     Do you envision clients only having one resumption handshake at a
>     time? I was under the impression that TLS 1.2 clients typically
>     open multiple
>     resumption handshakes in parallel, and that TLS 1.3 clients would
>     want to do the same.
>
>
> It is common for existing clients to re-use the same ticket for many
> connections. This is at-odds with forward secrecy though :/ Clients
> could have many resumption tokens at a time though; e.g. they could
> ask for 10 and use each one once. It's just that each token is used
> once. So parallel resumptions could be supported.
>

I understand there are good reasons to want to make the default behavior
of a single-physical-server TLS server as secure as possible, but I
think it's also well-understood that the more "exciting" portions of
0-RTT happen in a distributed setup, where there are different physical
(well, maybe virtual) machines sharing a session ticket key, potentially
in different data centers.  I don't think we've seen a real description
of how this proposal for "single-use" session tickets would behave in
the distributed setup yet.  Are you proposing to require a distributed
replay cache shared by all machines sharing the session-ticket key?  I
expect a lot of pushback from operators in that case, since distributed
replay caches are really annoying to get right, let alone performant. 
So then the "single-use" property would come with a caveat, that it's
only "single use" per replay cache instance, and some limited number of
replays become possible.

Can you say more about how you envision your proposal working for these
distributed environments?


In a more general sense, it's starting to seem like we should consider
the spectrum from "actually no replays possible" to "some small number
of replays possible [on the order of the number of machines sharing the
session ticket key]" and ending at "nearly unlimited (millions+) of
replays possible".  I think avoiding the last case is a reasonable goal,
but I'm as-yet unconvinced that the first case is achievable. Perhaps
the middle ground is good enough...

-Ben