Re: New Version Notification for draft-thomson-http-replay-00.txt

Hi Martin,

On Thu, Jul 27, 2017 at 05:15:20PM +1000, Martin Thomson wrote:
> Hi Willy,
> 
> On 27 July 2017 at 17:08, Willy Tarreau <w@1wt.eu> wrote:
> > On Wed, Jul 26, 2017 at 02:19:29PM +1000, Martin Thomson wrote:
> >> If Early-Data was omitted by the client, that would make it easier in
> >> a sense.  Then an intermediary could tell if it was the first.
> >
> > If you remember that's exactly the conclusion that draw us to get rid
> > of this header on the client during our first meeting. We noticed that
> > it was wrong to have the client provide it because it would confuse
> > chained intermediaries and in the end the only thing that matters is
> > not how the request was *sent* but how it was *received*.
> 
> Yes, this was a good reason until Subodh convinced me that the race
> was serious and that how the packet is received can be controlled by
> an attacker to the extent necessary to confuse a server.

I continue to disagree on this specific case because it's exactly the
same as what can be done without 0-RTT, and 0-RTT doesn't make it any
weaker.

We're "just" talking about a generic way to abuse a supposed ability
for a client to retry upon network timeouts. This exists in clear, in
TLS with and without 0-RTT. The attacker can even just block the
response from being delivered to the client, to ensure it's really
handled. All that's done here is to provoke a timeout and watch what
happens.

The draft never suggests at all that a client should retry on timeouts
met with 0-RTT, it suggests the client has to retry when getting the
4NN response, promising the request was not processed.

> It's true that receipt is what matters ultimately.
> 
> I've updated the PR
> (https://github.com/martinthomson/http-replay/pull/25) to capture this
> nuance.  Hopefully it isn't awful.

I really disagree with one this because it removes the ability to wait
for the ClientFinished signal for all communications, even with client
talking directly to the server. It significantly affects the usage scope
of 0-RTT in my opinion, to try to cover for a case that is already not
covered using 1-RTT.

I'd rather remind of the risks of retrying a failed request upon timeout
instead of waiting for the proof of non-execution that 4NN consists in, but
that covers a broader scope, more in line with Mark's initial enumeration
of all retry cases.

Best regards,
Willy

Received on Thursday, 27 July 2017 08:32:09 UTC