On 05/21/2017 05:47 PM, Eric Rescorla wrote: > > > On Sat, May 20, 2017 at 6:16 AM, Ilari Liusvaara > <ilariliusva...@welho.com <mailto:ilariliusva...@welho.com>> wrote: > > On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh 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 it's just an attempt to make clear what the client behavior should be. It's like when we say that implementations MUST NOT put more than one extension of the same type in a given extension block. The peer has to validate received messages, but the local implementation has to know to not generate them, either. > > > - Servers MAY accept the same ticket multiple times. > > > This seems implicit. > It seems implicit to me, as well, though I'm not sure that there's harm in saying it explicitly, particularly when reusing a ticket is a MUST NOT in certain specific cases (0-RTT). > > > - 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. > Right, this would bring replays down from the millions hypothesized for the weak time-based thing to more like tens, which is kind of in the regime that we are currently in with (at least some) application behavior. > 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: > I think it's worth writing up the most-secure scheme(s) we know of, to give us some concrete text to digest and decide if we can live with. > 1. Requiring it. > 2. Whether they still want to retain the stateless technique. > If we think we can require it and have it actually stick, that seems like the safest plan. The results of this discussion leave me uneasy with a scheme that permits millions of replays, even if there is not something concrete that I definitely object to. As DKG (almost) said, "we're designing a security protocol, not an easy-to-implement protocol". I'm still concerned that if we put MUST it will be more RFC 6919 than 2119, though, even if clients and/or ssllabs try to grease it. So, if we require it, then the stateless technique is not needed per se (but we still want the time limit so as to bound the size of a strike register). If we don't/can't require it, then I would say keep the stateless technique but try to crank down the time window and suggest that implementations rate-limit 0-RTT acceptance per domain to try to get away from the billions of replay regime. Another crazy idea would be to just say that servers MUST limit the use of a single binder to at most 100 times, with the usual case being just once, to allow for alternative designs that have weaker distributed consensus requirements (but still describe these current two methods as examples of ways to do so). -Ben
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
