On Sun, May 21, 2017 at 3:47 PM, Eric Rescorla <e...@rtfm.com> wrote: > > - Clients MUST NOT use the same ticket multiple times for 0-RTT. >> > > I don't understand the purpose of this requirement. As you note below, > servers are ultimately responsible for enforcing it, and it's not clear to > me why clients obeying it makes life easier for the server. >
I think clients should duplicate them sometimes, just to keep servers on their toes ;-) this is what we talked about maybe being a grease thing .. if at all. - Servers MUST NOT accept the same ticket with the same binder multiple >> times for 0-RTT (if any part of ClientHello covered by binder is >> different, one can assume binders are different). This holds even >> across servers (i.e., if server1 accepts 0-RTT with ticket X and >> binder Y, then server2 can not accept 0-RTT with ticket X and binder >> Y). >> > > I assume that what you have in mind here is that the server would know > which tickets it was authoritative for anti-replay and would simply reject > 0-RTT if it wasn't authoritative? This seems like it would significantly > cut > down on mass replays, though it would of course still make > application-level > replay a problem. > > I'm happy to write this up as part of the first two techniques. I'd be > interested in hearing from others in the WG what they think about: > > 1. Requiring it. > 2. Whether they still want to retain the stateless technique. > I'm for requiring it, and for removing the stateless technique ... because it prevents the side-channel and DOS attacks and those seem like the most serious ones (and also, the new ones). So far each case where we've thought "Actually stateless might be ok in this case" ... like the example of DNS ... turns out not to be safe when examined more closely (in DNSes case it would compromise privacy because caches could be probed). -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
