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

On 07/27/2017 01:34 PM, Willy Tarreau wrote:
> On Thu, Jul 27, 2017 at 01:18:50PM -0500, Benjamin Kaduk wrote:
>> On 07/25/2017 10:44 PM, Willy Tarreau wrote:
>>> So while we designed the 4NN principle as an end-to-end invitation to
>>> retry, offering the guarantee that the request was not processed and
>>> that it will not be replayed, this same signaling is perfectly usable
>>> between components. The fact that the client isn't notified of the
>>> intermediary retrying it is not a problem because if the client has
>>> sent its request in 0-RTT and has sent its ClientFinished, it's because
>>> it expected it to be completed. By the way that was the recommended way
>>> to implement 0-RTT before we discussed this at the workshop ;-)
>> I just want to point out that 4NN was not a *guarantee* that the request
>> will not be replayed
> Yes it is. The only way to get this 4NN is for the connection to have
> been maintained between the client and the server for the whole duration.
> An attacker duplicating the traffic cannot use it against a new connection
> because the ClientFinished depends on the handshake.

I think we may be using different vocabulary/definitions.

Alice makes a TCP connection to Bob, starts up a TLS 1.3 handshake and
sends some early data with it containing an HTTP request.  Eve has a tap
in the network and records the bits going Alice-->Bob.  Bob sends a TLS
1.3 ServerHello/EncryptedExtensions/Finished and a 4NN in its 0.5-RTT
data.  Nothing stops Eve from taking a copy of those recorded bits and
sending them towards Bob's clone Robert that shares a cert+key.  Are
there requirements on Robert's behavior when receiving those bits?  I
claim that with the -00, Robert is permitted to give 200 and an actual
response, but with pull/25, Robert is obliged to also return a 4NN.

Again, by "replay" I mean literally replaying the bits on the wire, not
a retry where the client generates a new request.

> That's why I'm insisting that the 4NN *is* a guarantee, that the timeout
> isn't. Subodh's attack relies on letting the client connection time out
> before receiving anything in hope that the client would retry it, leaving
> a working connection to the attacker.
>


A guarantee of what, exactly?  (I assume only upon receipt, since the
attacker can withhold the response from the client and force timeout
behavior.)

-Ben