Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

[Ryan Hamilton <[e-mail]>]

On Mon, Mar 14, 2016 at 1:17 PM, Geoffrey Keating <[e-mail]> wrote:

> Ryan Hamilton <[e-mail]> writes:
>
> > On Mon, Mar 14, 2016 at 12:12 PM, Geoffrey Keating <[e-mail]>
> > wrote:
> >
> > > So, I don't think HTTP is generally safe against attacker-forced
> > > replay, and would suggest great caution in allowing it.
> > >
> >
> > It's worth keeping in mind this recent paper about Replay attacks against
> > HTTPS <http://blog.valverde.me/2015/12/07/bad-life-advice/#.VucOsJMrIxN
> >.
> > TL;DR: Attackers can already force a browser to replay requests basically
> > at will. ​As a result, it's not clear that 0-RTT replay makes this
> > situation worse.
>
> The blog indicates that it's possible to cause a browser to repeat a
> request exactly once, within a short timeframe (probably 60 seconds or
> so) before the browser times out; and the browser must not see the
> first request succeed.  That's quite different from being able to let
> a client make and complete a request, and then being to repeat that
> request thousands of times over a period of hours or longer; even if
> the client is a browser, it might be hard to convince it to do that.
>

​Right. I'm not trying to argue that these two things are the same. I am
trying to point out that HTTPS replay attacks are *already* possible. So
from an HTTP developer perspective, developers already need to deal with
this issue. There are surely things we can do constrain the replay-ability
of 0-RTT​ data and I'm happy to see that happen. However, I don't want to
throw out 0-RTT completely for fear that it will expose HTTP to a new class
of attacks, since HTTP is already exposed to those attacks.

Cheers,

Ryan