On 03/25/2016 02:41 PM, Colm MacCárthaigh wrote: > On Fri, Mar 25, 2016 at 12:02 PM, Karthik Bhargavan > <karthikeyan.bharga...@inria.fr > <mailto:karthikeyan.bharga...@inria.fr>> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
