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

> 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?


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