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

Martin, a few others and I discussed this draft offline just after the HTTP WG meeting and I believe there is an extension of the dkg style attack possible on the proposal currently.

I'm making the following assumptions:
     * There is no special API to handle 0-rtt data by the TLS terminator, i.e. it is treated as a part of the same 1-rtt stream of data

  *   A Terminating proxy uses one of 2 approaches to decide to set Early-Data upstream:
     *   The terminating proxy just checks for isHandshakeFinished() to determine whether or not the data was send on 0-rtt or not, and sets the Early-Data accordingly
     *   The server buffers the entire request till it gets the Finished message and then forwards the requests without early data header
  *   There are 2 timeouts on the client, a transport timeout which is larger and a request timeout which is smaller
  *   The client will potentially retry requests that timeout potentially on a new connection
  *   A client decides to send a non-idempotent request over 0-rtt and relies on the server to reject it

Let's say the following things happen:

  *   A client sends a request to the Terminating proxy over 0-rtt.
  *   A MITM forwards the client hello to the proxy, gets the server hello etc. and forwards it to the client and gets the earlydata and finished message.
  *   The MITM then holds back the request and the finished message.
  *   The request would time out on the client and the client retries on a new connection over 1-rtt to another server.
  *   The transport has not timed out yet.
  *   The MITM then releases the original data to the proxy
  *   Since the proxy received the data and finished together, it would consider it to not be early data and not forward the early data header to the upstream
  *   The upstream server now has received the same request twice without knowing that it was sent over 0-rtt so it would not reject them and if it didn't have another idempotency mechanism, would execute it twice.


Any strategy that does not provide a custom API for servers to tell the difference between 0-rtt and non 0-rtt data suffers from this problem. However custom APIs are painful to work with.

Fortunately I think there is a simple fix to this though which is setting the early data header from the client directly and then the proxy can just forward it through. I understand that this cannot be exactly determined by the client, but it could be conservative about it.

Subodh
________________________________
From: Mike Bishop <Michael.Bishop@microsoft.com>
Sent: Thursday, June 22, 2017 3:40:03 PM
To: Martin Thomson
Cc: HTTP Working Group
Subject: RE: New Version Notification for draft-thomson-http-replay-00.txt

Ah, just terminology, then.  I was reading "gateway" as "intermediary," not as "reverse proxy."  A reverse proxy is much more likely to have a close configuration relationship with its back-end server(s).

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com]
Sent: Thursday, June 22, 2017 3:24 PM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: New Version Notification for draft-thomson-http-replay-00.txt

On 23 June 2017 at 03:38, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> I like most of it, but the second paragraph in 5 seems a little hand-wavy.  The gateway is supposed to "know" the server supports this new standard, which it can only fully do if it has received a 4NN in the past, which would only happen if it knew in the past, which....  Chicken, meet egg.

I don't think that it is as hand-wavy as all that.  Keep in mind that as a gateway for HTTPS, the gateway has the keys for the origin server.  That means that there is a pretty strong relationship there.
The gateway can use that.  For instance, a CDN might delay requests unconditionally unless their customer has provided an override that enables immediate forwarding.

This is less of a chicken and egg issue even if the gateway is forced to hold requests.  As we well know, the number of requests that can fit into the first round trip is limited.  That's why header compression is so useful.  Early data gives the client a little more space for sending requests.  It's not much, but it's something.