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

2017-07-21 20:02 GMT+02:00 Kazuho Oku <kazuhooku@gmail.com>:

>
>
> 2017-07-21 19:16 GMT+02:00 Subodh Iyengar <subodh@fb.com>:
>
>> > The attack you gave is not specific to 0-RTT or even to TLS 1.3.
>> To stop that sort of (retry) attack, the application must make POSTs
>> idempotent, even if HTTP says that POSTs are not idempotent. This
>> is even if 0-RTT is not implemented at all anywhere.
>>
>> I agree, a generic retry attack is not specific to 0-RTT or even TLS 1.3.
>> However this draft adds a new header which has certain semantics.
>> The attack is just an example of how to use a retry to circumvent those
>> semantics
>>
>> and confuse the app server.
>>
>>
>> If the application does not use the header to decide anything and all
>> it's
>>
>> requests are idempotent, then does it really need the header at all? It
>> could just accept
>>
>> all requests. So clearly this header exists to make decisions based on
>> it, could even be a
>>
>> GET request it does not wish to serve over 0-RTT, or whatever.
>>
>>
>> > 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.
>>
>> Ya its very similar, it's not even novel, I referred to it as a variant
>> of dkg attack 😊.
>> The header adds new bit of information that the origin server is making
>> a decision on. The thing that
>>
>> this attack shows though is that that information can be faked in certain
>> practical circumstances, which
>>
>> makes it unsafe to rely on that information.
>>
>>
>>
>> > 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.
>>
>>
>> Could you clarify this point Kazhuho?
>>
>
> Sure.
>
> Http-replay is a specification that is required only when we have an
> intermediary that terminates an HTTPS connection (a server application that
> directly terminates TLS does not need a header, since it can look at the
> state of the TLS stack).
>
> So let's consider the case in which we are running an application server
> behind a reverse proxy. The worst case would be when the two RTTs (one
> between the client and reverse proxy and the other between the reverse
> proxy and the server) are identical (the RTT is hereafter referred to as
> RTTh; h standing for hop-by-hop).
>
> If it was the case that the node that sets the early-data (which also is
> the node that resends the request after 1-RTT confirmation when it sees a
> 4xx response) was the reverse proxy, then the use of 0-RTT and 4xx will not
> increase any latency compared to the 1-RTT case. This is because the
> reverse proxy will see 4xx at the same moment it sees ClientFinished. In
> other words, the client will receive the response in 6 RTTh since it
> started sending the TLS handshake.
>
> OTOH, if we move the responsibility of setting the `early-data` header to
> the client (and therefore require the client to do the resend), the 4xx
> will need to go to the client, and then the request will travel though the
> entire chain. This means that the client will need to wait for 8 RTTh since
> it started sending the TLS handshake.
>
> To summarize, by moving the responsibility of setting `early-data` header
> to the client, we would see  33% additional latency (at worst) for using
> 0-RTT,  compared none in case of the original approach. And in addition to
> that, we would see additional bandwidth consumed between the client and the
> reverse proxy due to the retransmit of the request.
>
>
Correction: the numbers for the original case is 3 RTTh, and the case for
the client setting the early-data header is 4 RTTh.

Sorry for the mistake.

> Thanks,
>>
>> Subodh
>>
>>
>> ------------------------------
>> *From:* ilariliusvaara@welho.com <ilariliusvaara@welho.com> on behalf of
>> Ilari Liusvaara <ilariliusvaara@welho.com>
>> *Sent:* Friday, July 21, 2017 9:26:20 AM
>> *To:* Subodh Iyengar
>> *Cc:* Kazuho Oku; Mike Bishop; Martin Thomson; HTTP Working Group
>> *Subject:* Re: New Version Notification for
>> draft-thomson-http-replay-00.txt
>>
>> On Wed, Jul 19, 2017 at 02:49:32PM +0000, Subodh Iyengar wrote:
>> > > 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.
>>
>> The attack you gave is not specific to 0-RTT or even to TLS 1.3.
>>
>> To stop that sort of (retry) attack, the application must make POSTs
>> idempotent, even if HTTP says that POSTs are not idempotent. This
>> is even if 0-RTT is not implemented at all anywhere.
>>
>> The 0-RTT data header, even in racy form that may misdetect 0-RTT
>> request as 1-RTT does stop actual replay attacks if server knows what
>> resources are sensitive. And thanks to difficulty of ideal anti-replay
>> at scale, the TLS 1.3 specification does admit replays.
>>
>>
>>
>> -Ilari
>>
>
>
>
> --
> Kazuho Oku
>



-- 
Kazuho Oku