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

On Thu, Jul 27, 2017 at 03:16:28PM -0500, Benjamin Kaduk wrote:
> 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?

It doesn't change the fact that the additional presence of the EarlyData
header field added by the client makes no distinction here, it's just
redundant with the connection using 0-RTT.

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

Having both of them rely on EarlyData demands that same for of consistency
unfortunately so it doesn't add anything against this.

I mean, don't get me wrong, I'm not saying at all that there are not corner
cases that we have to try to improve, what I'm saying is that the proposal
to have the client add Early-Data was proposed solely for the timeout case
and provides zero benefit for the case where the early data are replayed
without ClientFinished (thus without the client being aware), and that's
precisely the limit of using 0-RTT, so if the whether *one* of the servers
considers the request safe or not (configuration issue or anything) is out
of our control. The principle is to let the server decide what action to
take with requests received as Early Data.

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

Not exactly since the Early Data has to be sent before the ClientFinished,
the point was to be able to present Bob with a request carrying a validated
ClientFinished (ie: Bob was supposed to trust it).

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

But the point of the draft precisely is to explain how to safely map
HTTP on top of early data and to explain the risks :-) If we start to
say "let's not do it safely because some will surely bypass the rule
anyway", it becomes a bit difficult to provide something really useful :-)

That's why I'm really all for documenting the corner cases so that
implementers know what *not* to do (ie: even if a browser retries on
timeout, it must absolutely not do it with early data). And anyway as
Subodh showed, a browser retrying on timeout would be at risk whatever
the transport level in use.

> 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]?

Absolutely not, but it does have a guarantee that this request was not
presented with a ClientFinished. So by virtue of the server having the
final choice whether a request is safe to process as early data or not,
the second will fail. The remaining cases where such a request is
nevertheless processed are caused by different configurations, but adding
headers on the client will not address misconfigured servers anyway (and
would in fact make things worse by increasing the complexity, resulting
in additional wrong combinations statically speaking).


Received on Thursday, 27 July 2017 21:01:49 UTC