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

On 07/27/2017 02:50 PM, Willy Tarreau wrote:
> On Thu, Jul 27, 2017 at 01:45:34PM -0500, Benjamin Kaduk wrote:
>>>> 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.
> I don't see how this would make any difference. In before pull/25, both
> Alice and Eve send the request as early data without ClientFinished. This
> *without ClientFinished* is the signal that the request is at risk. After
> pull/25, both Alice and Eve send the request as early data without
> ClientFinished and both with the EarlyData header field. This one becomes
> the signal. In both cases, it requires both Bob and Robert to have the
> same configuration, so nothing was saved by adding EarlyData.

My claim is with regarding Bob/Robert's decision about whether a given
(early) request can safely be processed as early data (vs. needing to be
verified by waiting for ClientFinished or sending 4NN for 1-RTT retry)
-- that is, whether they must necessarily make the same decision for a
given request.  You mention that they must have the same configuration,
but but what if the current system load also is used in making the
decision?  My reading of pull/24 is that "MUST consistently use the same
approach" also implies must make the same decision.  If you think that
the -00 draft as-is implies that Robert and Bob must make the same
decision, I'd be happy to have that be the case.


> The point that Subodh made was that Bob would hijack Alice->Bob's connection
> and would delay the ClientFinished message so that the finalized request
> doesn't reach Bob. Alice, being fed up with waiting would *spontaneously*
> try again and succeed. Then Eve would unblock the packet and have Bob play
> the initial request again. The fault here is not a lack of identification
> that the first request was transported over early data, it's a fault from
> Alice who retried without being invited to do so nor knowing the consequences
> of doing so. And if this attack would work for a selection of Alices, then it
> would also work over TLS 1.2 as well because no transport information was used
> at all.

My understanding was that Subodh's point involve delaying not just the
ClientFinished but also the early data preceding it, so that Bob did not
even know there was a request at all, let alone one that is not
finalized.  When the early data + ClientFinished were allowed through
together, Bob would see the request, check that the handshake is
finished, and assume it was a 1-RTT request, even though Alice had
already timed out and retried.

I do not dispute that Alice could prevent the behavior by waiting to
receive a 4NN before retrying, though I also do not expect (e.g.)
browsers to universally adopt such behavior.

>> Again, by "replay" I mean literally replaying the bits on the wire, not
>> a retry where the client generates a new request.
> We do uses the same terminology, but you and Subodh are talking about
> different cases.
>
>>> 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.)
> A guarantee that the request that led to this response was not processed.
> The timeout behaviour is made up and not part of the draft at all, and is
> irrelevant to 0-RTT.
>

I agree that a client receiving 4NN has a guarantee that its request was
not processed on this connection.  Does it also have a guarantee that
(replays of) its request were not processed on any other connection
[even though those other connections would subsequently have the TLS
handshake fail]?

-Ben