On Wed, May 24, 2017 at 7:30 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > > > 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. > > Actually, even tens of replays at TLS level is quite dangerous, > especially if to different servers (bad information leaks via cache > attacks). >
It hard stops replays, but does nothing about retries, and I think that's ok. The client is in much more control of retries, and it's similar (if not identical) to what can happen today with an interrupted TCP or TLS connection. If a client permits hundreds, or millions of forced retries, I think that's more appropriately handled at the client/application level, but keep in mind there are typically seconds between the retries and the rate of attack is slow. Replays are when an attacker can send the same data at-will and it's completely unknown to the client, it can happen out of band over different network connectivity, in a very short and sharp interval of time, possibly even to different server endpoints, and can be used by attackers to gather information. These I think need to be mitigated at the TLS level; and should be hard-stopped. > 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). > > You actually need strong distributed consensus about all accepted > 0-RTT here. > This pattern doesn't need strong consensus. If you have 10 servers, you could give each 10 goes at the ticket, and let each exhaust its 10 attempts without any coordination or consensus. You likely won't get to "exactly 100", but you will get to "at most 100 times". But the inner critical section would be inherently more complicated. For the at most once case we need to a critical section that performs an exclusive-read-and-delete atomically. It's a mutex lock or a clever construction of atomic instructions. For "at most N" we now need to perform a decrement and write in the critical section, and it becomes more like a semaphore. It's probably not a pattern that's worth the trade-offs. -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
