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

From: Willy Tarreau <[email-masked]>
Date: Tue, 1 Aug 2017 09:16:30 +0200

Hi Ben,

On Mon, Jul 31, 2017 at 10:36:02AM -0500, Benjamin Kaduk wrote:
> > In fact we're documenting how to use a risky but very appealing feature
> > safely with HTTP and posing some elements so that it doesn't represent a
> > risk anymore. When we write "the server must do this", if it's a server
> > farm and not a single node, they all have to act consistently. If there
> > is a risk of inconsistency past a certain point, it becomes the front
> > intermediary's role to either respond with 4NN or wait for ClientFinished
> > to ensure reliability before the uncertain path.
> 
> Just to double-check, we will still have text that says the server farm
> must act consistently (as opposed to just saying "the server must do
> this" and making it implicit that a server-cum-server-farm is bound to
> behave as if a single server)?

Yes I think it is important. I'd even be willing to go a bit further
regarding consistency requirements. Something along "The first intermediary
on the path which cannot guarantee that the next hops will act consistently
and that they will all properly handle the Early-Data header field MUST
either wait for ClientFinished if it's the first one to receive early data,
or respond with 4NN without forwarding the request".

> The server is supposed to send its
> ServerHello/EncryptedExtensions/Finished immediately after it sees the
> ClientHello, and the client can keep streaming early data while that's
> happening.  The client should send EndOfEarlyData/Finished once it
> receives the server's Finished, and move the data stream to 1-RTT data. 
> So I think that the attacker can let through the ClientHello but hold on
> to the application data until the server's first flight arrives, then
> let through the stored records along with the client's response, all in
> one go (possibly with additional delaying for the whole assembly).

Yes but then the EarlyData have already been sent to the server, and the
intercepted data are specific to this connection and nor reusable for
another one, that was my point.

Cheers,
Willy

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 2 Aug 2017 09:04:02 -0500

Hi Willy,

> another one, that was my point.

I think we may still be talking past each other, here, specifically
about the "no[t] reusable for another [connection]" point.  When we talk
about the specific bits of early data that go on the wire, wrapped in
one or more TLS records, those can only ever be used on one (successful)
TLS connection because the encryption key incorporates the
ClientHello.random and compliant clients will not reuse the random
value; the client only accepts one ServerHello and that commits the
connection to being between those two parties (or to failing).  At the
same time, anyone who records those TLS records on the wire can replay
them at the same or a different server, with the intention of inducing
the server to send an application-level response to the unauthenticated
(imposter) client, even before the ClientFinished is received (which
will never happen).  The server farm has some limited amount of control
over how often this will happen, but in general it cannot be completely
prevented, regardless of whether or not the ClientFinished is processed
on the "real" connection -- the replay avoidance strategies discussed in
the TLS 1.3 spec all come into play at the time of the decision of
whether or not to accept the early data TLS extension, which is well
before a ClientFinished is available.

So, I don't think I understand what you mean by "specific to this
connection and no[t] reusable for another one".  Am I missing something?

Thanks,

Ben