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

I agree with your analysis and that the proposed mitigation should have
the desired effect.
It's probably worth calling out that the scenario assumes the client
sends non-idempotent stuff over 0-RTT, which the client is not supposed
to do. And, as you note, a server with a separate API/stream for early
data would know that the request in question came over early data.
-Ben
On 07/19/2017 09:20 AM, Subodh Iyengar wrote:
> 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: 
> o 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
> o 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:
>
> * Aclient 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.