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

[Ilari Liusvaara <[e-mail]>]

On Wed, May 31, 2017 at 03:49:03PM -0400, Victor Vasiliev wrote:
> On Tue, May 30, 2017 at 9:56 PM, Colm MacCárthaigh <[e-mail]>
>  wrote:
> 
> > Here you argue, essentially, that it is too inconvenient to mitigate those
> > attacks for users. I don't think we can seriously take that approach.
> >
> > If the methods are too inconvenient, the secure alternative is to not use
> > 0-RTT at all.
> >
> > [snip]
> >
> 
> I think I am not getting my key point across here clearly.  I am not arguing
> that they are inconvenient, I am arguing that the guarantee you are trying
> to provide is impossible.

TLS level "sent data is delivered at most once" is very much possible.
But it requires synchronous state.

And it seems like where "few replays @TLS" would be easier than "no
replays @TLS", is where the replays would be to different servers, with
each server only accepting once. But "few replays" distributed among
different servers is much more dangerous than "few replays" to one
server.

Yes, residual replays will still come through even when TLS guarantees
"at most once" behavior. But turns out one already has to handle that
form of replay, due to wonders of web browser behavior (and reordering
attacks abusing timeouts). It is TLS not guaranteeing "at most once"
behavior (especially across servers) that enables new attacks.

This is fundamentially about what is REQUIRED to do 0-RTT without
nasty security holes. If you think this is too difficult, just don't
do 0-RTT. One extra RTT is a lot better than nasty attacks, with
potential consequences much worse than just some site getting DoSed
or some card chargebacks.



-Ilari