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

[Benjamin Kaduk <[e-mail]>]

On 05/24/2017 10:32 AM, Colm MacCárthaigh wrote:
>
>     > 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". 
>

Or (up to) 100 servers and give each server just one crack at the
ticket, which is perhaps more plausible to implement sanely.

> 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. 
>

That particular decrement-based design is not worth the trade-off,
definitely, but I doubt it's the only scheme that could meet the stated
requirement.  Something that attempts to access a global single-use data
structure but has some failure tolerance for that operation, and some
plausible story for bounding how often that can happen, say (like
stopping accepting 0-RTT at all on that server for 10 seconds once a
threshold level of errors occurs).

But, as indicated by the "crazy idea" prefix, I am not actually pushing
for this scheme.

-Ben