Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh <[e-mail]>]

On Wed, May 24, 2017 at 7:30 AM, Ilari Liusvaara <[e-mail]>
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