draft-ietf-httpbis-replay-02.txt   draft-ietf-httpbis-replay-latest.txt 
httpbis Working Group M. Thomson HTTP Working Group M. Thomson
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track M. Nottingham Intended status: Standards Track M. Nottingham
Expires: May 28, 2018 Fastly Expires: August 6, 2018 Fastly
W. Tarreau W. Tarreau
HAProxy Technologies HAProxy Technologies
November 24, 2017 February 02, 2018
Using Early Data in HTTP Using Early Data in HTTP
draft-ietf-httpbis-replay-02 draft-ietf-httpbis-replay-latest
Abstract Abstract
This document explains the risks of using early data for HTTP and Using TLS early data creates an exposure to the possibility of a
describes techniques for reducing them. In particular, it defines a replay attack. This document defines mechanisms that allow clients
mechanism that enables clients to communicate with servers about to communicate with servers about HTTP requests that are sent in
early data, to assure correct operation. early data. Techniques are described that use these mechanisms to
mitigate the risk of replay.
Note to Readers
Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at
https://lists.w3.org/Archives/Public/ietf-http-wg/ [1].
Working Group information can be found at http://httpwg.github.io/
[2]; source code and issues list for this draft can be found at
https://github.com/httpwg/http-extensions/labels/replay [3].
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 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 May 28, 2018. This Internet-Draft will expire on August 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
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 . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . 9
6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 8 6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 11
8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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.
skipping to change at page 3, line 22 skipping to change at page 3, line 35
1.1. Conventions and Definitions 1.1. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. 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 data
form a single stream. This can mean that requests are entirely to 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
completes, the early data received on that TLS connection is known to completes, the early data received on that TLS connection is known to
not be a replayed copy of that data. However, it is important to not be a replayed copy of that data. However, it is important to
note that this does not mean that early data will not be or has not note that this does not mean that early data will not be or has not
been replayed on another connection. been replayed on another connection.
skipping to change at page 4, line 7 skipping to change at page 4, line 22
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. This provides the server with some the request(s) therein. This provides the server with some
assurance that the early data was not replayed. 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.
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 425 (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
determine this. However, some resources do elect to associate side determine this. However, some resources do elect to associate side
effects with safe methods, so this cannot be universally relied upon. effects with safe methods, so this cannot be universally relied upon.
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, origin servers MUST either reject early data or
requests that have unsafe methods, using the techniques outlined implement the techniques described in this document for ensuring that
above. requests are not processed prior to TLS handshake completion.
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 any server starts acting upon the contents of a request. Any time any
server instance might initiate processing prior to completion of the server instance might initiate processing prior to completion of the
handshake, all server instances need to consider how a possible handshake, all server instances need to consider how a possible
replay of early data could affect that processing (see also replay of early data could affect that processing (see also
Section 6.2). Section 6.2).
skipping to change at page 5, line 30 skipping to change at page 5, line 44
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. This could start sending again as though the connection was new. This could
entail using a different negotiated protocol [ALPN] than the one entail using a different negotiated protocol [ALPN] than the one
optimistically used for the early data. If HTTP/2 is selected after optimistically used for the early data. Any requests sent in early
early data is rejected, a client sends another connection preface. data MUST be sent again, unless the client decides to abandon those
Any requests sent in early data MUST be sent again, unless the client requests.
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
skipping to change at page 6, line 22 skipping to change at page 6, line 34
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 might o The "Early-Data" header field is included in requests that might
have been forwarded by an intermediary prior to the TLS handshake have been forwarded by an intermediary prior to the TLS handshake
completing. with its client 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 10 skipping to change at page 7, line 23
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 prior to the completion of An intermediary that forwards a request prior to the completion of
the TLS handshake MUST send it with the "Early-Data" header field set the TLS handshake with its client MUST send it with the "Early-Data"
to "1" (i.e., it adds it if not present in the request). An header field set to "1" (i.e., it adds it if not present in the
intermediary MUST use the "Early-Data" header field if it might have request). An intermediary MUST use the "Early-Data" header field if
forwarded the request prior to handshake completion (see Section 6.2 it might have forwarded the request prior to handshake completion
for details). (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 425 (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.
skipping to change at page 8, line 23 skipping to change at page 8, line 38
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 origin server that receives MUST only do so if it knows that the origin server that receives
those requests understands the "Early-Data" header field and will those requests understands the "Early-Data" header field and will
correctly generate a 425 (Too Early) status code. A gateway that correctly generate a 425 (Too Early) status code. A gateway that is
isn't certain about origin server support SHOULD either delay uncertain about origin server support for a given request SHOULD
forwarding the request until the TLS handshake with its client either delay forwarding the request until the TLS handshake with its
completes, or send a 425 (Too Early) status code in response. A client completes, or send a 425 (Too Early) status code in response.
gateway that is uncertain about whether an origin server supports the
"Early-Data" header field SHOULD disable early data. 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.
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 (including TLS handshake completes, then all instances of the server (including
gateways) need to agree and either reject the request or delay gateways) need to agree and either reject the request or delay
processing. 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 A server MUST NOT act on early data before the handshake completes if
it and any other server instance could make a different decision it and any other server instance could make a different decision
about how to handle the same data. 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 425 (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 6.4. Out of Order Delivery
In protocols that deliver data out of order (such as QUIC [HQ]) early In protocols that deliver data out of order (such as QUIC [HQ]) early
data can arrive after the handshake completes. This leads to data can arrive after the handshake completes. A server MAY process
potential ambiguity about the status of requests and could lead to requests received in early data after handshake completion if it can
inconsistent treatment (see Section 6.2). Implementations MUST rely on other instances correctly handling replays of the same
either ensure that any early data that is delivered late is either requests.
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
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 425 (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
skipping to change at page 10, line 30 skipping to change at page 11, line 10
[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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/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-23 (work in progress),
July 2017. January 2018.
8.2. Informative References 8.2. Informative References
[ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/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-09 (work in progress), January
2017. 2018.
[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>.
8.3. URIs
[1] https://lists.w3.org/Archives/Public/ietf-http-wg/
[2] http://httpwg.github.io/
[3] https://github.com/httpwg/http-extensions/labels/replay
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: David Benjamin, Subodh Iyengar, Benjamin Kaduk, Ilari
Oku, Eric Rescorla, Kyle Rose, and Victor Vasiliev. Liusavaara, Kazuho 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. 25 change blocks. 
52 lines changed or deleted 81 lines changed or added

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