draft-ietf-httpbis-replay-00.txt   draft-ietf-httpbis-replay-01.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: March 10, 2018 true Expires: April 23, 2018 Fastly
W. Tarreau W. Tarreau
HAProxy Technologies HAProxy Technologies
September 06, 2017 October 20, 2017
Using Early Data in HTTP Using Early Data in HTTP
draft-ietf-httpbis-replay-00 draft-ietf-httpbis-replay-01
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
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 March 10, 2018. This Internet-Draft will expire on April 23, 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
(http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3
2. Early Data in HTTP . . . . . . . . . . . . . . . . . . . . . 3 2. Early Data in HTTP . . . . . . . . . . . . . . . . . . . . . 3
3. Supporting Early Data in HTTP Servers . . . . . . . . . . . . 3 3. Supporting Early Data in HTTP Servers . . . . . . . . . . . . 3
4. Using Early Data in HTTP Clients . . . . . . . . . . . . . . 5 4. Using Early Data in HTTP Clients . . . . . . . . . . . . . . 5
5. Extensions for Early Data in HTTP . . . . . . . . . . . . . . 6 5. Extensions for Early Data in HTTP . . . . . . . . . . . . . . 6
5.1. The Early-Data Header Field . . . . . . . . . . . . . . . 6 5.1. The Early-Data Header Field . . . . . . . . . . . . . . . 6
5.2. The 4NN (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
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6.4. Out of Order Delivery . . . . . . . . . . . . . . . . . . 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
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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.
skipping to change at page 3, line 49 skipping to change at page 3, line 49
1. TLS [TLS13] mandates the use of replay detection strategies that 1. TLS [TLS13] mandates the use of replay detection strategies that
reduce the ability of an attacker to successfully replay early reduce the ability of an attacker to successfully replay early
data. These anti-replay techniques reduce but don't completely data. These anti-replay techniques reduce but don't completely
eliminate the chance of data being replayed and ensure a fixed eliminate the chance of data being replayed and ensure a fixed
upper limit to the number of replays. upper limit to the number of replays.
2. The server can choose whether it will process early data before 2. The server can choose whether it will process early data before
the TLS handshake completes. By deferring processing, it can the TLS handshake completes. By deferring processing, it can
ensure that only a successfully completed connection is used for ensure that only a successfully completed connection is used for
the request(s) therein. Assuming that a replayed ClientHello the request(s) therein. This provides the server with some
will not result in additional connections being made by the assurance that the early data was not replayed.
client, this provides the server with some assurance that the
early data was not replayed.
3. If the server receives multiple requests in early data, it can 3. If the server receives multiple requests in early data, it can
determine whether to defer HTTP processing on a per-request determine whether to defer HTTP processing on a per-request
basis. This may require buffering the responses to preserve basis. This may require buffering the responses to preserve
ordering in HTTP/1.1. ordering in HTTP/1.1.
4. The server can cause a client to retry a request and not use 4. The server can cause a client to retry a request and not use
early data by responding with the 4NN (Too Early) status code early data by responding with the 425 (Too Early) status code
(Section 5.2), in cases where the risk of replay is judged too (Section 5.2), in cases where the risk of replay is judged too
great. great.
For a given request, the level of tolerance to replay risk is For a given request, the level of tolerance to replay risk is
specific to the resource it operates upon (and therefore only known specific to the resource it operates upon (and therefore only known
to the origin server). In general, if processing a request does not to the origin server). In general, if processing a request does not
have state-changing side effects, the consequences of replay are not have state-changing side effects, the consequences of replay are not
significant. significant.
The request method's safety ([RFC7231], Section 4.2.1) is one way to The request method's safety ([RFC7231], Section 4.2.1) is one way to
skipping to change at page 5, line 5 skipping to change at page 5, line 5
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
mechanism. mechanism.
Note that a server cannot choose to selectively reject early data at Note that a server cannot choose to selectively reject early data at
the TLS layer. TLS only permits a server to accept all early data, the TLS layer. TLS only permits a server to accept all early data,
or none of it. Once a server has decided to accept early data, it or none of it. Once a server has decided to accept early data, it
MUST process all requests in early data, even if the server rejects MUST process all requests in early data, even if the server rejects
the request by sending a 4NN (Too Early) response. the request by sending a 425 (Too Early) response.
A server can limit the amount of early data with the A server can limit the amount of early data with the
"max_early_data_size" field of the "early_data" TLS extension. This "max_early_data_size" field of the "early_data" TLS extension. This
can be used to avoid committing an arbitrary amount of memory for can be used to avoid committing an arbitrary amount of memory for
deferred requests. A server SHOULD ensure that when it accepts early deferred requests. A server SHOULD ensure that when it accepts early
data, it can defer processing of requests until after the TLS data, it can defer processing of requests until after the TLS
handshake completes. handshake completes.
4. Using Early Data in HTTP Clients 4. Using Early Data in HTTP Clients
skipping to change at page 5, line 37 skipping to change at page 5, line 37
start sending again as though the connection was new. For HTTP/2, start sending again as though the connection was new. For HTTP/2,
this means re-sending the connection preface. Any requests sent in this means re-sending the connection preface. Any requests sent in
early data MUST be sent again, unless the client decides to abandon early data MUST be sent again, unless the client decides to abandon
those requests. 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 the 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 TLS).
Clients that use early data MUST retry requests upon receipt of a 4NN 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
set to "1". set to "1" (see Section 5.1).
5. Extensions for Early Data in HTTP 5. Extensions for Early Data in HTTP
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 are
received in early data. received in early data.
o The 4NN (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.
Gateways typically don't have specific information about whether a Gateways typically don't have specific information about whether a
given request can be processed safely when it is sent in early data. given request can be processed safely when it is sent in early data.
In many cases, only the origin server has the necessary information In many cases, only the origin server has the necessary information
to decide whether the risk of replay is acceptable. These extensions to decide whether the risk of replay is acceptable. These extensions
allow coordination between a gateway and its origin server. allow coordination between a gateway and its origin server.
5.1. The Early-Data Header Field 5.1. The Early-Data Header Field
The "Early-Data" request header field indicates that the request has The "Early-Data" request header field indicates that the request has
been conveyed in early data, and additionally indicates that a client been conveyed in early data, and additionally indicates that a client
understands the 4NN (Too Early) status code. understands the 425 (Too Early) status code.
It has just one valid value: "1". Its syntax is defined by the It has just one valid value: "1". Its syntax is defined by the
following ABNF [ABNF]: following ABNF [ABNF]:
Early-Data = "1" Early-Data = "1"
For example: For example:
GET /resource HTTP/1.0 GET /resource HTTP/1.0
Host: example.com Host: example.com
Early-Data: 1 Early-Data: 1
An intermediary that forwards a request received in TLS early data
MUST send it with the "Early-Data" header field set to "1" (i.e., it An intermediary that forwards a request prior to the completion of
adds it if not present in the request). the TLS handshake MUST send it with the "Early-Data" header field set
to "1" (i.e., it adds it if not present in the request). An
intermediary MUST use the "Early-Data" header field if it might have
forwarded the request prior to handshake completion (see Section 6.2
for details).
An intermediary MUST NOT remove this header field if it is present in An intermediary MUST NOT remove this header field if it is present in
a request. a request.
The "Early-Data" header field is not intended for use by user agents The "Early-Data" header field is not intended for use by user agents
(that is, the original initiator of a request). Sending a request in (that is, the original initiator of a request). Sending a request in
early data implies that the client understands this specification and early data implies that the client understands this specification and
is willing to retry a request in response to a 4NN (Too Early) status is willing to retry a request in response to a 425 (Too Early) status
code. A user agent that sends a request in early data does not need code. A user agent that sends a request in early data does not need
to include the "Early-Data" header field. to include the "Early-Data" header field.
A server cannot make a request that contains the Early-Data header A server cannot make a request that contains the Early-Data header
field safe for processing by waiting for the handshake to complete. field safe for processing by waiting for the handshake to complete.
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 4NN (Too Early) status be safely processed MUST be rejected using the 425 (Too Early) status
code. code.
5.2. The 4NN (Too Early) Status Code 5.2. The 425 (Too Early) Status Code
A 4NN (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 Clients (user-agents and intermediaries) that sent the request in
early data MUST automatically retry the request when receiving a 4NN early data MUST automatically retry the request when receiving a 425
(Too Early) response status code. Such retries MUST NOT be sent in (Too Early) response status code. Such retries MUST NOT be sent in
early data, and SHOULD NOT be sent if the TLS handshake on the early data.
original connection does not successfully complete.
Intermediaries that receive a 4NN (Too Early) status code MAY Intermediaries that receive a 425 (Too Early) status code MAY
automatically retry requests after allowing the handshake to complete automatically retry requests after allowing the handshake to complete
unless the original request contained the "Early-Data" header field unless the original request contained the "Early-Data" header field
when it was received. Otherwise, an intermediary MUST forward the when it was received. Otherwise, an intermediary MUST forward the
4NN (Too Early) status code. 425 (Too Early) status code.
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 4NN 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 4NN (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
Using early data exposes a client to the risk that their request is Using early data exposes a client to the risk that their request is
replayed. A retried or replayed request can produce different side replayed. A retried or replayed request can produce different side
effects on the server. In addition to those side effects, replays effects on the server. In addition to those side effects, replays
and retries might be used for traffic analysis to recover information and retries might be used for traffic analysis to recover information
about requests or the resources those requests target. about requests or the resources those requests target.
6.1. Gateways and Early Data 6.1. Gateways and Early Data
A gateway that forwards requests that were received in early data A gateway that forwards requests that were received in early data
MUST only do so if it knows that the server that receives those MUST only do so if it knows that the origin server that receives
requests understands the "Early-Data" header field and will correctly those requests understands the "Early-Data" header field and will
generate a 4NN (Too Early) status code. A gateway that isn't certain correctly generate a 425 (Too Early) status code. A gateway that
about server support SHOULD either delay forwarding the request until isn't certain about origin server support SHOULD either delay
the TLS handshake completes, or send a 4NN (Too Early) status code in forwarding the request until the TLS handshake with its client
response. A gateway that is uncertain about whether an origin server completes, or send a 425 (Too Early) status code in response. A
supports the "Early-Data" header field SHOULD disable early data. gateway that is uncertain about whether an origin server supports the
"Early-Data" header field SHOULD disable early data.
6.2. Consistent Handling of Early Data 6.2. Consistent Handling of Early Data
Consistent treatment of a request that arrives in - or partially in - Consistent treatment of a request that arrives in - or partially in -
early data is critical to avoiding inappropriate processing of early data is critical to avoiding inappropriate processing of
replayed requests. If a request is not safe to process before the replayed requests. If a request is not safe to process before the
TLS handshake completes, then all instances of the server need to TLS handshake completes, then all instances of the server (including
agree and either reject the request or delay processing. gateways) need to agree and either reject the request or delay
processing.
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.
6.3. Denial of Service 6.3. Denial of Service
Accepting early data exposes a server to potential denial of service Accepting early data exposes a server to potential denial of service
through the replay of requests that are expensive to handle. A through the replay of requests that are expensive to handle. A
server that is under load SHOULD prefer rejecting TLS early data as a server that is under load SHOULD prefer rejecting TLS early data as a
whole rather than accepting early data and selectively processing whole rather than accepting early data and selectively processing
requests. Generating a 503 (Service Unavailable) or 4NN (Too Early) requests. Generating a 503 (Service Unavailable) or 425 (Too Early)
status code often leads to clients retrying requests, which could status code often leads to clients retrying requests, which could
result in increased load. result in increased load.
6.4. 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 Section 6.2). Implementations MUST
either ensure that any early data that is delivered late is either
discarded or consistently identified and processed.
7. IANA Considerations 7. IANA Considerations
This document registers the "Early-Data" header field in the "Message This document registers the "Early-Data" header field in the "Message
Headers" registry [HEADERS]. Headers" registry [HEADERS].
Header field name: Early-Data Header field name: Early-Data
Applicable protocol: http Applicable protocol: http
Status: standard Status: standard
skipping to change at page 9, line 4 skipping to change at page 9, line 24
7. IANA Considerations 7. IANA Considerations
This document registers the "Early-Data" header field in the "Message This document registers the "Early-Data" header field in the "Message
Headers" registry [HEADERS]. Headers" registry [HEADERS].
Header field name: Early-Data Header field name: Early-Data
Applicable protocol: http Applicable protocol: http
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): This document Specification document(s): This document
Related information: (empty) Related information: (empty)
This document registers the 4NN (Too Early) status code in the This document registers the 425 (Too Early) status code in the
"Hypertext Transfer Protocol (HTTP) Status Code" registry established "Hypertext Transfer Protocol (HTTP) Status Code" registry established
in [RFC7231]. in [RFC7231].
Value: 4NN Value: 425
Description: Too Early Description: Too Early
Reference: This document Reference: This document
8. References 8. References
8.1. Normative References 8.1. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, <https://www.rfc- DOI 10.17487/RFC5234, January 2008,
editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[HEADERS] Klyne, G., Nottingham, M., and J. Mogul, "Registration [HEADERS] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, September 2004, <https://www.rfc- DOI 10.17487/RFC3864, September 2004,
editor.org/info/rfc3864>. <https://www.rfc-editor.org/info/rfc3864>.
[HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
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, <https://www.rfc- DOI 10.17487/RFC7231, June 2014,
editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[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
[HQ] Bishop, M., "Hypertext Transfer Protocol (HTTP) over [HQ] Bishop, M., "Hypertext Transfer Protocol (HTTP) over
QUIC", draft-ietf-quic-http-05 (work in progress), August 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, <https://www.rfc- DOI 10.17487/RFC7540, May 2015,
editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
Appendix A. 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, and Victor Vasiliev. Oku, 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
true 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. 45 change blocks. 
61 lines changed or deleted 78 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/