- From: Ilari Liusvaara <ilariliusvaara@welho.com>
- Date: Fri, 21 Jul 2017 19:26:20 +0300
- To: Subodh Iyengar <subodh@fb.com>
- Cc: Kazuho Oku <kazuhooku@gmail.com>, Mike Bishop <Michael.Bishop@microsoft.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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
Received on Friday, 21 July 2017 16:26:50 UTC