- From: Benjamin Kaduk <bkaduk@akamai.com>
- Date: Wed, 19 Jul 2017 11:05:43 -0500
- To: Subodh Iyengar <subodh@fb.com>, Mike Bishop <Michael.Bishop@microsoft.com>, Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <49353fe5-1e3b-d508-ea1e-14795573ab83@akamai.com>
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.
Received on Wednesday, 19 July 2017 16:06:13 UTC