From fb06f6f8e07a05b963a9f94ed7374bf2e45288ed Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 29 Nov 2017 20:04:03 +1100 Subject: [PATCH 1/4] Remove buffering text for 1.1 --- draft-ietf-httpbis-replay.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/draft-ietf-httpbis-replay.md b/draft-ietf-httpbis-replay.md index 9672cb537..2146943c9 100644 --- a/draft-ietf-httpbis-replay.md +++ b/draft-ietf-httpbis-replay.md @@ -113,8 +113,7 @@ to mitigate the risks of replay: replayed. 3. If the server receives multiple requests in early data, it can determine - whether to defer HTTP processing on a per-request basis. This may require - buffering the responses to preserve ordering in HTTP/1.1. + whether to defer HTTP processing on a per-request basis. 4. The server can cause a client to retry a request and not use early data by responding with the 425 (Too Early) status code ({{status}}), in cases where From ad92e98dfc6abb968aa036840acd8ae4b499e9d2 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 29 Nov 2017 20:05:40 +1100 Subject: [PATCH 2/4] Don't make a special point about h2 preface --- draft-ietf-httpbis-replay.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/draft-ietf-httpbis-replay.md b/draft-ietf-httpbis-replay.md index 2146943c9..b3b598a55 100644 --- a/draft-ietf-httpbis-replay.md +++ b/draft-ietf-httpbis-replay.md @@ -178,9 +178,8 @@ send unsafe methods (or methods whose safety is not known) in early data. If the server rejects early data at the TLS layer, a client MUST start sending again as though the connection was new. This could entail using a different negotiated protocol {{?ALPN=RFC7301}} than the one optimistically used for the -early data. If HTTP/2 is selected after early data is rejected, a client sends -another connection preface. Any requests sent in early data MUST be sent again, -unless the client decides to abandon those requests. +early data. Any requests sent in early data MUST be sent again, unless the +client decides to abandon those requests. This automatic retry exposes the request to a potential replay attack. An attacker sends early data to one server instance that accepts and processes the From 9a37c88017da4bbef3c510a1a708097895355b1b Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 29 Nov 2017 20:10:15 +1100 Subject: [PATCH 3/4] Reword to make distinction between mitigate and disable clear --- draft-ietf-httpbis-replay.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-httpbis-replay.md b/draft-ietf-httpbis-replay.md index b3b598a55..b13516fb7 100644 --- a/draft-ietf-httpbis-replay.md +++ b/draft-ietf-httpbis-replay.md @@ -311,11 +311,11 @@ target. A gateway that forwards requests that were received in early data MUST only do so if it knows that the origin server that receives those requests understands the `Early-Data` header field and will correctly generate a 425 (Too Early) -status code. A gateway that isn't certain about origin server support SHOULD -either delay forwarding the request until the TLS handshake with its client -completes, or send a 425 (Too Early) status code in response. A gateway that is -uncertain about whether an origin server supports the `Early-Data` header field -SHOULD disable early data. +status code. A gateway that is uncertain about origin server support for a +given request SHOULD either delay forwarding the request until the TLS handshake +with its client completes, or send a 425 (Too Early) status code in response. A +gateway SHOULD disable early data entirely unless at least one potential origin +server supports `Early-Data` header field. ## Consistent Handling of Early Data {#be-consistent} From dd735e747e85142df49d623c3736f00d8522f001 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 29 Nov 2017 20:16:20 +1100 Subject: [PATCH 4/4] Disabling early data is wise Gateways gain very little from enabling early data, but expend quite a bit of effort. That might not be worthwhile. --- draft-ietf-httpbis-replay.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/draft-ietf-httpbis-replay.md b/draft-ietf-httpbis-replay.md index b13516fb7..e9caca1ce 100644 --- a/draft-ietf-httpbis-replay.md +++ b/draft-ietf-httpbis-replay.md @@ -313,9 +313,12 @@ so if it knows that the origin server that receives those requests understands the `Early-Data` header field and will correctly generate a 425 (Too Early) status code. A gateway that is uncertain about origin server support for a given request SHOULD either delay forwarding the request until the TLS handshake -with its client completes, or send a 425 (Too Early) status code in response. A -gateway SHOULD disable early data entirely unless at least one potential origin -server supports `Early-Data` header field. +with its client completes, or send a 425 (Too Early) status code in response. + +A gateway without at least one potential origin server that supports +`Early-Data` header field expends significant effort for what can at best be a +modest performance benefit from enabling early data. If no origin server +supports early data, disabling early data entirely is more efficient. ## Consistent Handling of Early Data {#be-consistent}