draft-ietf-httpbis-replay-01.txt   draft-ietf-httpbis-replay-02.txt 
httpbis Working Group M. Thomson httpbis Working Group M. Thomson
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track M. Nottingham Intended status: Standards Track M. Nottingham
Expires: April 23, 2018 Fastly Expires: May 28, 2018 Fastly
W. Tarreau W. Tarreau
HAProxy Technologies HAProxy Technologies
October 20, 2017 November 24, 2017
Using Early Data in HTTP Using Early Data in HTTP
draft-ietf-httpbis-replay-01 draft-ietf-httpbis-replay-02
Abstract Abstract
This document explains the risks of using early data for HTTP and This document explains the risks of using early data for HTTP and
describes techniques for reducing them. In particular, it defines a describes techniques for reducing them. In particular, it defines a
mechanism that enables clients to communicate with servers about mechanism that enables clients to communicate with servers about
early data, to assure correct operation. early data, to assure correct operation.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2018. This Internet-Draft will expire on May 28, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
5.2. The 425 (Too Early) Status Code . . . . . . . . . . . . . 7 5.2. The 425 (Too Early) Status Code . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Gateways and Early Data . . . . . . . . . . . . . . . . . 8 6.1. Gateways and Early Data . . . . . . . . . . . . . . . . . 8
6.2. Consistent Handling of Early Data . . . . . . . . . . . . 8 6.2. Consistent Handling of Early Data . . . . . . . . . . . . 8
6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 8 6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 8
6.4. Out of Order Delivery . . . . . . . . . . . . . . . . . . 9 6.4. Out of Order Delivery . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
TLS 1.3 [TLS13] introduces the concept of early data (also known as TLS 1.3 [TLS13] introduces the concept of early data (also known as
zero round trip data or 0-RTT data). Early data allows a client to zero round trip data or 0-RTT data). Early data allows a client to
send data to a server in the first round trip of a connection, send data to a server in the first round trip of a connection,
without waiting for the TLS handshake to complete if the client has without waiting for the TLS handshake to complete if the client has
spoken to the same server recently. spoken to the same server recently.
When used with HTTP [HTTP], early data allows clients to send When used with HTTP [HTTP], early data allows clients to send
skipping to change at page 3, line 14 skipping to change at page 3, line 14
To help mitigate the risk of replays in HTTP, this document gives an To help mitigate the risk of replays in HTTP, this document gives an
overview of techniques for controlling these risks in servers, and overview of techniques for controlling these risks in servers, and
defines requirements for clients when sending requests in early data. defines requirements for clients when sending requests in early data.
The advice in this document also applies to use of 0-RTT in HTTP over The advice in this document also applies to use of 0-RTT in HTTP over
QUIC [HQ]. QUIC [HQ].
1.1. Conventions and Definitions 1.1. Conventions and Definitions
The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
document. It's not shouting; when they are capitalized, they have "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
the special meaning defined in [RFC2119]. "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.
2. Early Data in HTTP 2. Early Data in HTTP
Conceptually, early data is concatenated with other application to Conceptually, early data is concatenated with other application to
form a single stream. This can mean that requests are entirely form a single stream. This can mean that requests are entirely
contained within early data, or only part of a request is early. In contained within early data, or only part of a request is early. In
a multiplexed protocol, like HTTP/2 [RFC7540] or HTTP/QUIC [HQ], a multiplexed protocol, like HTTP/2 [RFC7540] or HTTP/QUIC [HQ],
multiple requests might be partially delivered in early data. multiple requests might be partially delivered in early data.
The model that this document assumes is that once the TLS handshake The model that this document assumes is that once the TLS handshake
skipping to change at page 4, line 34 skipping to change at page 4, line 34
It is RECOMMENDED that origin servers allow resources to explicitly It is RECOMMENDED that origin servers allow resources to explicitly
configure whether early data is appropriate in requests. Absent such configure whether early data is appropriate in requests. Absent such
explicit information, they SHOULD mitigate against early data in explicit information, they SHOULD mitigate against early data in
requests that have unsafe methods, using the techniques outlined requests that have unsafe methods, using the techniques outlined
above. above.
A request might be sent partially in early data with the remainder of A request might be sent partially in early data with the remainder of
the request being sent after the handshake completes. This does not the request being sent after the handshake completes. This does not
necessarily affect handling of that request; what matters is when the necessarily affect handling of that request; what matters is when the
server starts acting upon the contents of a request. Any time a server starts acting upon the contents of a request. Any time any
server might initiate processing prior to completion of the handshake server instance might initiate processing prior to completion of the
it needs to consider how a possible replay of early data could affect handshake, all server instances need to consider how a possible
that processing (see also Section 6.2). replay of early data could affect that processing (see also
Section 6.2).
A server can partially process requests that are incomplete. Parsing A server can partially process requests that are incomplete. Parsing
header fields - without acting on the values - and determining header fields - without acting on the values - and determining
request routing is likely to be safe from side-effects, but other request routing is likely to be safe from side-effects, but other
actions might not be. actions might not be.
Intermediary servers do not have sufficient information to make this Intermediary servers do not have sufficient information to make this
determination, so Section 5.2 describes a way for the origin to determination, so Section 5.2 describes a way for the origin to
signal to them that a particular request isn't appropriate for early signal to them that a particular request isn't appropriate for early
data. Intermediaries that accept early data MUST implement that data. Intermediaries that accept early data MUST implement that
skipping to change at page 5, line 27 skipping to change at page 5, line 28
requests immediately after sending the TLS ClientHello. requests immediately after sending the TLS ClientHello.
By their nature, clients have control over whether a given request is By their nature, clients have control over whether a given request is
sent in early data - thereby giving the client control over risk of sent in early data - thereby giving the client control over risk of
replay. Absent other information, clients MAY send requests with replay. Absent other information, clients MAY send requests with
safe HTTP methods (see [RFC7231], Section 4.2.1) in early data when safe HTTP methods (see [RFC7231], Section 4.2.1) in early data when
it is available, and SHOULD NOT send unsafe methods (or methods whose it is available, and SHOULD NOT send unsafe methods (or methods whose
safety is not known) in early data. safety is not known) in early data.
If the server rejects early data at the TLS layer, a client MUST 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, start sending again as though the connection was new. This could
this means re-sending the connection preface. Any requests sent in entail using a different negotiated protocol [ALPN] than the one
early data MUST be sent again, unless the client decides to abandon optimistically used for the early data. If HTTP/2 is selected after
those requests. 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 This automatic retry exposes the request to a potential replay
attack. An attacker sends early data to one server instance that attack. An attacker sends early data to one server instance that
accepts and processes the early data, but allows that connection to accepts and processes the early data, but allows that connection to
proceed no further. The attacker then forwards the same messages proceed no further. The attacker then forwards the same messages
from the client to another server instance that will reject early from the client to another server instance that will reject early
data. The client then retries the request, resulting in the request data. The client then retries the request, resulting in the request
being processed twice. Replays are also possible if there are being processed twice. Replays are also possible if there are
multiple server instances that will accept early data, or if the same multiple server instances that will accept early data, or if the same
server accepts early data multiple times (though this would be in server accepts early data multiple times (though this would be in
violation of requirements in TLS). violation of requirements in Section 8 of [TLS13]).
Clients that use early data MUST retry requests upon receipt of a 425 Clients that use early data MUST retry requests upon receipt of a 425
(Too Early) status code; see Section 5.2. (Too Early) status code; see Section 5.2.
An intermediary MUST NOT use early data when forwarding a request An intermediary MUST NOT use early data when forwarding a request
unless early data was used on a previous hop, or it knows that the unless early data was used on a previous hop, or it knows that the
request can be retried safely without consequences (typically, using request can be retried safely without consequences (typically, using
out-of-band configuration). Absent better information, that means out-of-band configuration). Absent better information, that means
that an intermediary can only use early data if the request either that an intermediary can only use early data if the request either
arrived in early data or arrived with the "Early-Data" header field arrived in early data or arrived with the "Early-Data" header field
skipping to change at page 6, line 18 skipping to change at page 6, line 20
Because HTTP requests can span multiple "hops", it is necessary to Because HTTP requests can span multiple "hops", it is necessary to
explicitly communicate whether a request has been sent in early data explicitly communicate whether a request has been sent in early data
on a previous connection. Likewise, some means of explicitly on a previous connection. Likewise, some means of explicitly
triggering a retry when early data is not desirable is necessary. triggering a retry when early data is not desirable is necessary.
Finally, it is necessary to know whether the client will actually Finally, it is necessary to know whether the client will actually
perform such a retry. perform such a retry.
To meet these needs, two signalling mechanisms are defined: To meet these needs, two signalling mechanisms are defined:
o The "Early-Data" header field is included in requests that are o The "Early-Data" header field is included in requests that might
received in early data. have been forwarded by an intermediary prior to the TLS handshake
completing.
o The 425 (Too Early) status code is defined for a server to o The 425 (Too Early) status code is defined for a server to
indicate that a request could not be processed due to the indicate that a request could not be processed due to the
consequences of a possible replay attack. consequences of a possible replay attack.
They are designed to enable better coordination of the use of early They are designed to enable better coordination of the use of early
data between the user agent and origin server, and also when a data between the user agent and origin server, and also when a
gateway (also "reverse proxy", "Content Delivery Network", or gateway (also "reverse proxy", "Content Delivery Network", or
"surrogate") is present. "surrogate") is present.
skipping to change at page 7, line 38 skipping to change at page 7, line 38
A request that is marked with Early-Data was sent in early data on a A request that is marked with Early-Data was sent in early data on a
previous hop. Requests that contain the Early-Data field and cannot previous hop. Requests that contain the Early-Data field and cannot
be safely processed MUST be rejected using the 425 (Too Early) status be safely processed MUST be rejected using the 425 (Too Early) status
code. code.
5.2. The 425 (Too Early) Status Code 5.2. The 425 (Too Early) Status Code
A 425 (Too Early) status code indicates that the server is unwilling A 425 (Too Early) status code indicates that the server is unwilling
to risk processing a request that might be replayed. to risk processing a request that might be replayed.
Clients (user-agents and intermediaries) that sent the request in User agents that send a request in early data MUST automatically
early data MUST automatically retry the request when receiving a 425 retry the request when receiving a 425 (Too Early) response status
(Too Early) response status code. Such retries MUST NOT be sent in code. Such retries MUST NOT be sent in early data.
early data.
Intermediaries that receive a 425 (Too Early) status code MAY In all cases, an intermediary can forward a 425 (Too Early) status
automatically retry requests after allowing the handshake to complete code. Intermediaries MUST forward a 425 (Too Early) status code if
unless the original request contained the "Early-Data" header field the request that it received and forwarded contained an "Early-Data"
when it was received. Otherwise, an intermediary MUST forward the header field. Otherwise, an intermediary that receives a request in
425 (Too Early) status code. 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 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" unless the request is received in early data or the "Early-Data"
header field is set to "1". A server SHOULD NOT emit the 425 status header field is set to "1". A server SHOULD NOT emit the 425 status
code unless one of these conditions is met. code unless one of these conditions is met.
The 425 (Too Early) status code is not cacheable by default. Its The 425 (Too Early) status code is not cacheable by default. Its
payload is not the representation of any identified resource. payload is not the representation of any identified resource.
6. Security Considerations 6. Security Considerations
skipping to change at page 10, line 25 skipping to change at page 10, line 25
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-21 (work in progress), Version 1.3", draft-ietf-tls-tls13-21 (work in progress),
July 2017. July 2017.
8.2. Informative References 8.2. Informative References
[ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[HQ] Bishop, M., "Hypertext Transfer Protocol (HTTP) over [HQ] Bishop, M., "Hypertext Transfer Protocol (HTTP) over
QUIC", draft-ietf-quic-http-07 (work in progress), October QUIC", draft-ietf-quic-http-07 (work in progress), October
2017. 2017.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
Acknowledgments Acknowledgments
This document was not easy to produce. The following people made This document was not easy to produce. The following people made
substantial contributions to the quality and completeness of the substantial contributions to the quality and completeness of the
document: Subodh Iyengar, Benjamin Kaduk, Ilari Liusavaara, Kazuho document: Subodh Iyengar, Benjamin Kaduk, Ilari Liusavaara, Kazuho
Oku, Kyle Rose, and Victor Vasiliev. Oku, Eric Rescorla, Kyle Rose, and Victor Vasiliev.
Authors' Addresses Authors' Addresses
Martin Thomson Martin Thomson
Mozilla Mozilla
Email: martin.thomson@gmail.com Email: martin.thomson@gmail.com
Mark Nottingham Mark Nottingham
Fastly Fastly
Email: mnot@mnot.net Email: mnot@mnot.net
Willy Tarreau Willy Tarreau
HAProxy Technologies HAProxy Technologies
Email: willy@haproxy.org Email: willy@haproxy.org
 End of changes. 16 change blocks. 
30 lines changed or deleted 47 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/