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

Thank you for the explanation.

2017-07-19 16:49 GMT+02:00 Subodh Iyengar <subodh@fb.com>:
>> While I understand that such an issue exists, I am not sure if it is a
> replay attack.
>
>
> A better way to think about it might be that mItm could always hold back the
> request even now, but he can't confuse the origin that the request came from
> 0-rtt or not 0-rtt because no such promise exists right now, however with
> this mechanism he can confuse the backend with a retry. So I think such an
> issue should be in scope for this discussion.

I do not think that the application will be confused.

For a backend, sending 4XX is a stateless thing. So it's just an issue
in which order the server sees the two requests confirmed with
ClientFinished (one that was sent by the client as a retry and the
other that was held back by an attacker). Since the two requests are
both ClientFinished-confirmed, to me it seems like that it is
identical to what could happen on TLS 1.2.

For example, to me it seems almost identical to an attack on TLS 1.2
that withholds the last packet that contains the HTTP request to
enforce the client to resend the request. The only difference would be
what timeout might kick in; in the TLS 1.2-case, a request timeout
would kick in if the attacker holds the last packet too long, whereas
in the 0-RTT case, it would be a TLS handshake timeout.

So while I think that it is an interesting attack (and that it is
worth mentioning in the document), I do not think that we need to move
the endpoint that sets the header to the client. The reason why I am
against such a move is that, moving it would make the worst case
performance of transactions using 0-RTT worse than when 1-RTT is used,
since the 4xx would cause a rentransmit in the entire chain.

> I don't think this mechanism is meant to stop replays, it's just meant to
> give the app the right information for it to make a decision of whether or
> not the client followed it's policy of sending data in 0-rtt. Replays are
> protected more by the transport rather than the application. For example if
> I had a transport without replay protection, this mechanism would not
> protect me from the classic replay safety attack of an attacker sending
> "safe" requests again and again and getting information from the length of
> the repsonse, if I was okay with the request being sent over 0-rtt.
>
> Subodh
>
> ________________________________
> From: Kazuho Oku <kazuhooku@gmail.com>
> Sent: Wednesday, July 19, 2017 7:32:25 AM
> To: Subodh Iyengar
> Cc: Mike Bishop; Martin Thomson; HTTP Working Group
>
> Subject: Re: New Version Notification for draft-thomson-http-replay-00.txt
>
> 2017-07-19 16:20 GMT+02:00 Subodh Iyengar <subodh@fb.com>:
>> 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.
>
> While I understand that such an issue exists, I am not sure if it is a
> replay attack.
>
> To me it seems like a retry attack.
>
> It seems to me that the impact of the attack is equal to when a MITM
> holds back the packet holding an HTTP response to cause the client
> retry the request.
>
> Or am I missing something?
>
>> 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.
>
>
>
> --
> Kazuho Oku



-- 
Kazuho Oku

Received on Friday, 21 July 2017 16:24:16 UTC