From 27e3c6c728135c2d284295ba765a359ae2a6ebf2 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 8 Dec 2017 11:52:00 +1100 Subject: [PATCH 1/3] As it so happens, late arrival isn't a problem --- draft-ietf-httpbis-replay.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/draft-ietf-httpbis-replay.md b/draft-ietf-httpbis-replay.md index 478215266..a64854670 100644 --- a/draft-ietf-httpbis-replay.md +++ b/draft-ietf-httpbis-replay.md @@ -345,11 +345,10 @@ requests, which could result in increased load. ## Out of Order Delivery -In protocols that deliver data out of order (such as QUIC {{HQ}}) early data -can arrive after the handshake completes. This leads to potential ambiguity -about the status of requests and could lead to inconsistent treatment (see -{{be-consistent}}). Implementations MUST either ensure that any early data that -is delivered late is either discarded or consistently identified and processed. +In protocols that deliver data out of order (such as QUIC {{HQ}}) early data can +arrive after the handshake completes. A server MAY process requests received in +early data after handshake completion if it can rely on other instances +correctly handling replays of the same requests. # IANA Considerations From 821e3a452d99175795273add0c31a8d9046b9850 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 8 Dec 2017 11:52:26 +1100 Subject: [PATCH 2/3] Consistency on mitigation technique isn't necessary All of the following are good: * rejecting 0-RTT * holding a request * sending 425 Thanks to @davidben for walking through this one. --- draft-ietf-httpbis-replay.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/draft-ietf-httpbis-replay.md b/draft-ietf-httpbis-replay.md index a64854670..344fddaca 100644 --- a/draft-ietf-httpbis-replay.md +++ b/draft-ietf-httpbis-replay.md @@ -330,6 +330,14 @@ request is not safe to process before the TLS handshake completes, then all instances of the server (including gateways) need to agree and either reject the request or delay processing. +Disabling early data, delaying requests, or rejecting requests with the 425 (Too +Early) status code are all equally good measures for mitigating replay attacks +on requests that might be vulnerable to replay. Server instances can implement +any of these measures and be considered to be consistent, even if different +instances use different methods. Critically, this means that it is possible to +employ different mitigations in reaction to other conditions, such as server +load. + A server MUST NOT act on early data before the handshake completes if it and any other server instance could make a different decision about how to handle the same data. From 05ad6d10d8ee1016441118c69c0522bb45187c16 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 8 Dec 2017 11:54:13 +1100 Subject: [PATCH 3/3] Ack for davidben --- draft-ietf-httpbis-replay.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-httpbis-replay.md b/draft-ietf-httpbis-replay.md index 344fddaca..297f27441 100644 --- a/draft-ietf-httpbis-replay.md +++ b/draft-ietf-httpbis-replay.md @@ -409,6 +409,6 @@ Reference: # Acknowledgments {:numbered="false"} This document was not easy to produce. The following people made substantial -contributions to the quality and completeness of the document: Subodh Iyengar, -Benjamin Kaduk, Ilari Liusavaara, Kazuho Oku, Eric Rescorla, Kyle Rose, and -Victor Vasiliev. +contributions to the quality and completeness of the document: David Benjamin, +Subodh Iyengar, Benjamin Kaduk, Ilari Liusavaara, Kazuho Oku, Eric Rescorla, +Kyle Rose, and Victor Vasiliev.