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

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.

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