- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 27 Jul 2017 20:34:37 +0200
- To: Benjamin Kaduk <bkaduk@akamai.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, Kazuho Oku <kazuhooku@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Jul 27, 2017 at 01:18:50PM -0500, Benjamin Kaduk wrote: > On 07/25/2017 10:44 PM, Willy Tarreau wrote: > > So while we designed the 4NN principle as an end-to-end invitation to > > retry, offering the guarantee that the request was not processed and > > that it will not be replayed, this same signaling is perfectly usable > > between components. The fact that the client isn't notified of the > > intermediary retrying it is not a problem because if the client has > > sent its request in 0-RTT and has sent its ClientFinished, it's because > > it expected it to be completed. By the way that was the recommended way > > to implement 0-RTT before we discussed this at the workshop ;-) > > I just want to point out that 4NN was not a *guarantee* that the request > will not be replayed Yes it is. The only way to get this 4NN is for the connection to have been maintained between the client and the server for the whole duration. An attacker duplicating the traffic cannot use it against a new connection because the ClientFinished depends on the handshake. That's why I'm insisting that the 4NN *is* a guarantee, that the timeout isn't. Subodh's attack relies on letting the client connection time out before receiving anything in hope that the client would retry it, leaving a working connection to the attacker. Willy
Received on Thursday, 27 July 2017 18:35:07 UTC