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

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.

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.

> 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.

Hoping this helps,
Willy

Received on Thursday, 27 July 2017 19:50:44 UTC