From 18ab184cb57c0ef358b33d95fa0b614f5a426ae4 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 21 Nov 2017 16:23:26 +1100 Subject: [PATCH 1/9] RFC 8174 --- draft-ietf-httpbis-replay.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/draft-ietf-httpbis-replay.md b/draft-ietf-httpbis-replay.md index 107957e9b..8692e6e77 100644 --- a/draft-ietf-httpbis-replay.md +++ b/draft-ietf-httpbis-replay.md @@ -73,9 +73,10 @@ The advice in this document also applies to use of 0-RTT in HTTP over QUIC ## Conventions and Definitions -The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this document. -It's not shouting; when they are capitalized, they have the special meaning -defined in {{!RFC2119}}. +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", +"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this +document are to be interpreted as described in BCP 14 {{!RFC2119}} {{!RFC8174}} +when, and only when, they appear in all capitals, as shown here. # Early Data in HTTP From dcabd90e65cb8d0c7cd4598902463320fadba0e9 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 21 Nov 2017 16:25:04 +1100 Subject: [PATCH 2/9] Sharpen text about partially-received request processing --- draft-ietf-httpbis-replay.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/draft-ietf-httpbis-replay.md b/draft-ietf-httpbis-replay.md index 8692e6e77..eedad8963 100644 --- a/draft-ietf-httpbis-replay.md +++ b/draft-ietf-httpbis-replay.md @@ -138,9 +138,10 @@ unsafe methods, using the techniques outlined above. A request might be sent partially in early data with the remainder of the request being sent after the handshake completes. This does not necessarily affect handling of that request; what matters is when the server starts acting -upon the contents of a request. Any time a server might initiate processing -prior to completion of the handshake it needs to consider how a possible replay of -early data could affect that processing (see also {{be-consistent}}). +upon the contents of a request. Any time any server instance might initiate +processing prior to completion of the handshake, all server instances need to +consider how a possible replay of early data could affect that processing (see +also {{be-consistent}}). A server can partially process requests that are incomplete. Parsing header fields - without acting on the values - and determining request routing is From 0011caac64978bc40020a35d8b1eb21e58b1db75 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 21 Nov 2017 16:25:49 +1100 Subject: [PATCH 3/9] Acknowledge ekr --- draft-ietf-httpbis-replay.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-replay.md b/draft-ietf-httpbis-replay.md index eedad8963..f16667dc3 100644 --- a/draft-ietf-httpbis-replay.md +++ b/draft-ietf-httpbis-replay.md @@ -396,4 +396,5 @@ Reference: {: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, Kyle Rose, and Victor Vasiliev. +Benjamin Kaduk, Ilari Liusavaara, Kazuho Oku, Eric Rescorla, Kyle Rose, and +Victor Vasiliev. From e8b65a9d54dad92e24b1aef2ad69062d7c6058aa Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 21 Nov 2017 16:27:02 +1100 Subject: [PATCH 4/9] Mention that ALPN can change --- draft-ietf-httpbis-replay.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-replay.md b/draft-ietf-httpbis-replay.md index f16667dc3..89988b9d4 100644 --- a/draft-ietf-httpbis-replay.md +++ b/draft-ietf-httpbis-replay.md @@ -177,7 +177,8 @@ other information, clients MAY send requests with safe HTTP methods (see 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. For HTTP/2, this means re-sending the +again as though the connection was new. This could include a change to the +negotiated protocol {{?ALPN=RFC7301}}. For HTTP/2, this means re-sending the connection preface. Any requests sent in early data MUST be sent again, unless the client decides to abandon those requests. From d141223ee006ae01ccfb69578b30398a0d268219 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 21 Nov 2017 16:27:31 +1100 Subject: [PATCH 5/9] Cite anti-replay section of TLS 1.3 --- draft-ietf-httpbis-replay.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-replay.md b/draft-ietf-httpbis-replay.md index 89988b9d4..a36b10a00 100644 --- a/draft-ietf-httpbis-replay.md +++ b/draft-ietf-httpbis-replay.md @@ -190,7 +190,7 @@ reject early data. The client then retries the request, resulting in the request being processed twice. Replays are also possible if there are multiple server instances that will accept early data, or if the same server accepts early data multiple times (though this would be in violation of requirements in -TLS). +Section 8 of {{!TLS13}}). Clients that use early data MUST retry requests upon receipt of a 425 (Too Early) status code; see {{status}}. From 126d29adecde7e399668a61f87d60fc3e4761e33 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 21 Nov 2017 16:28:33 +1100 Subject: [PATCH 6/9] Refine the short definition of the header field --- draft-ietf-httpbis-replay.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-httpbis-replay.md b/draft-ietf-httpbis-replay.md index a36b10a00..22d203f31 100644 --- a/draft-ietf-httpbis-replay.md +++ b/draft-ietf-httpbis-replay.md @@ -213,8 +213,8 @@ client will actually perform such a retry. To meet these needs, two signalling mechanisms are defined: -* The `Early-Data` header field is included in requests that are received in - early data. +* The `Early-Data` header field is included in requests that might have been + forwarded by an intermediary prior to the TLS handshake completing. * The 425 (Too Early) status code is defined for a server to indicate that a request could not be processed due to the consequences of a possible replay From 19508264b8b45d650739892b74dd1e363eebd75c Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 21 Nov 2017 16:29:20 +1100 Subject: [PATCH 7/9] Rework 425 handling rules for clarity --- draft-ietf-httpbis-replay.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/draft-ietf-httpbis-replay.md b/draft-ietf-httpbis-replay.md index 22d203f31..a9088ef12 100644 --- a/draft-ietf-httpbis-replay.md +++ b/draft-ietf-httpbis-replay.md @@ -279,14 +279,16 @@ using the 425 (Too Early) status code. A 425 (Too Early) status code indicates that the server is unwilling to risk processing a request that might be replayed. -Clients (user-agents and intermediaries) that sent the request in early data -MUST automatically retry the request when receiving a 425 (Too Early) -response status code. Such retries MUST NOT be sent in early data. - -Intermediaries that receive a 425 (Too Early) status code MAY automatically -retry requests after allowing the handshake to complete unless the original -request contained the `Early-Data` header field when it was received. -Otherwise, an intermediary MUST forward the 425 (Too Early) status code. +User agents that send a request in early data MUST automatically retry the +request when receiving a 425 (Too Early) response status code. Such retries MUST +NOT be sent in early data. + +In all cases, an intermediary can forward a 425 (Too Early) status code. +Intermediaries MUST forward a 425 (Too Early) status code if the request that it +received and forwarded contained an `Early-Data` header field. An intermediary +that receives a request in early data MAY automatically retry that request in +response to a 425 (Too Early) status code, but it MUST wait for the TLS +handshake to complete on the connection where it received the request. The server cannot assume that a client is able to retry a request unless the request is received in early data or the `Early-Data` header field is set to From 4a950531ae36b1bff0acf2690f7e928d5f058c64 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 22 Nov 2017 10:19:34 +1100 Subject: [PATCH 8/9] Otherwise... --- draft-ietf-httpbis-replay.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-httpbis-replay.md b/draft-ietf-httpbis-replay.md index a9088ef12..b51259bab 100644 --- a/draft-ietf-httpbis-replay.md +++ b/draft-ietf-httpbis-replay.md @@ -285,10 +285,10 @@ NOT be sent in early data. In all cases, an intermediary can forward a 425 (Too Early) status code. Intermediaries MUST forward a 425 (Too Early) status code if the request that it -received and forwarded contained an `Early-Data` header field. An intermediary -that receives a request in early data MAY automatically retry that request in -response to a 425 (Too Early) status code, but it MUST wait for the TLS -handshake to complete on the connection where it received the request. +received and forwarded contained an `Early-Data` header field. Otherwise, an +intermediary that receives a request in early data MAY automatically retry that +request in response to a 425 (Too Early) status code, but it MUST wait for the +TLS handshake to complete on the connection where it received the request. The server cannot assume that a client is able to retry a request unless the request is received in early data or the `Early-Data` header field is set to From 362d93d1b516d1e230e33d7e0b49167c5364d580 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 22 Nov 2017 10:21:11 +1100 Subject: [PATCH 9/9] Reword based on @kaduk's suggestions --- draft-ietf-httpbis-replay.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/draft-ietf-httpbis-replay.md b/draft-ietf-httpbis-replay.md index b51259bab..9672cb537 100644 --- a/draft-ietf-httpbis-replay.md +++ b/draft-ietf-httpbis-replay.md @@ -177,10 +177,11 @@ other information, clients MAY send requests with safe HTTP methods (see 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 include a change to the -negotiated protocol {{?ALPN=RFC7301}}. For HTTP/2, this means re-sending the -connection preface. Any requests sent in early data MUST be sent again, unless -the client decides to abandon those requests. +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. 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