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 <c...@allcosts.net> > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
