Re: Review of draft-thomson-http-replay-latest

On Fri, Aug 04, 2017 at 03:07:42PM +0900, Kazuho Oku wrote:
> 2017-08-04 14:53 GMT+09:00 Victor Vasiliev <vasilvv@google.com>:
> > On Thu, Aug 3, 2017 at 8:50 PM, Martin Thomson <martin.thomson@gmail.com>
> >>
> >> As I noted in #28 above, even if the handshake
> >> completes, it doesn't mean that the once-early data is entirely safe.
> >
> > I am not sure I can read that from #28, I seem to read it as the opposite?
> > I might be confused here.
> >
> > I am not sure I understand in which sense it's not safe.
> 
> (Stated below is my understanding and it could be wrong, but)
> 
> Consider the case a server uses strike register to protect against
> 0-RTT replay attacks. If a server misidentifies a request sent using
> 0-RTT data to be confirmed by ClientFinished, there is a chance that
> such protection would fail.

That depends on what happens on if 0-RTT strike register check fails:

- Rejecting the entiere connection is safe (allowed if strike register
  is not probablistic).
- Rejecting 0-RTT is safe.
- Rejecting the request is unsafe.
- Auto-retrying the request is unsafe.

The above impiles that there should not be HTTP-level strike registers
for 0-RTT. Thus, each 0-RTT request, including replayed ones, should be
processed independently, with one of three different dispositions:

- Handle immediately
- Wait for ClientFinished
- Reject immediately

And first and last two interpretations must not be mixed for the same
request.

However, that there should not be 0-RTT strike registers at HTTP level
does not imply that there should not be HTTP-level request strike
registers, but those strike registers need to span both 0-RTT and 1-RTT
in order to combat retries, not just replays.


The usefulness of TLS-level strike register is being a fast first
pass, filtering down the potential torrent of events into a manageable
stream. Handling such torrent directly is very difficult, and easily
exposes the application for timing or denial-of-service attacks.




-Ilari

Received on Friday, 4 August 2017 07:44:03 UTC