On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh wrote: > > Some protection is necessary; but it isn't too hard - a single-use session > cache, or a strike register, do protect against the side-channel and DOS > problems. Combined with a "fail closed" strategy and tickets that are > scoped to clusters or servers, these techniques do hard-stop the literal > 0-RTT replays, and they are practical. Many of us run systems like that > already.
As requirements: - Clients SHOULD NOT use the same ticket multiple times. - Clients MUST NOT use the same ticket multiple times for 0-RTT. - Servers MAY accept the same ticket multiple times. - 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). The "with the same binder" requirement is to deal with the following: 1) Bad client sends 0-RTT with ticket X and in-window age age1. 2) Some days pass... 3) Bad client sends 0-RTT with ticket X and in-window age age2. Without the "with the same binder", that would mean the server MUST reject the 0-RTT for 3), which would mean keeping state for days, which leads to excessive resource usage. With the "with same binder", the server can time out the state for 1) as soon as the age1 is out-of-window. And then it MAY accept 0-RTT for 3). This will not lead into mass replay possibility for either 1) nor 3). The part of assuming binders different if any part covered is different comes from strong hash requirement TLS 1.3 has. ? _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
