draft-ietf-quic-tls-18.txt   draft-ietf-quic-tls-latest.txt 
QUIC Working Group M. Thomson, Ed. QUIC Working Group M. Thomson, Ed.
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track S. Turner, Ed. Intended status: Standards Track S. Turner, Ed.
Expires: July 27, 2019 sn3rd Expires: September 23, 2019 sn3rd
January 23, 2019 March 22, 2019
Using TLS to Secure QUIC Using TLS to Secure QUIC
draft-ietf-quic-tls-18 draft-ietf-quic-tls-latest
Abstract Abstract
This document describes how Transport Layer Security (TLS) is used to This document describes how Transport Layer Security (TLS) is used to
secure QUIC. secure QUIC.
Note to Readers Note to Readers
Discussion of this draft takes place on the QUIC working group Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org), which is archived at mailing list (quic@ietf.org), which is archived at
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 July 27, 2019. This Internet-Draft will expire on September 23, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 3, line 6 skipping to change at page 3, line 6
5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 24 5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 24
5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 25 5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 25
6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 25 6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 25
7. Security of Initial Messages . . . . . . . . . . . . . . . . 27 7. Security of Initial Messages . . . . . . . . . . . . . . . . 27
8. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 28 8. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 28
8.1. Protocol and Version Negotiation . . . . . . . . . . . . 28 8.1. Protocol and Version Negotiation . . . . . . . . . . . . 28
8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 28 8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 28
8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 29 8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
9.1. Packet Reflection Attack Mitigation . . . . . . . . . . . 29 9.1. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 30
9.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 30 9.2. Packet Reflection Attack Mitigation . . . . . . . . . . . 31
9.3. Header Protection Analysis . . . . . . . . . . . . . . . 30 9.3. Peer Denial of Service . . . . . . . . . . . . . . . . . 31
9.4. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 31 9.4. Header Protection Analysis . . . . . . . . . . . . . . . 31
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 9.5. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
11.1. Normative References . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.2. Informative References . . . . . . . . . . . . . . . . . 33 11.1. Normative References . . . . . . . . . . . . . . . . . . 33
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34 11.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Sample Initial Packet Protection . . . . . . . . . . 34 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Appendix A. Sample Initial Packet Protection . . . . . . . . . . 35
A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 35 A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 37 A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 36
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 38 A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 38
B.1. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 38 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 39
B.2. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 38 B.1. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 39
B.3. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 39 B.2. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 39
B.4. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 39 B.3. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 39
B.5. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 39 B.4. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 40
B.6. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 39 B.5. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 40
B.7. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 39 B.6. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 40
B.8. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 40 B.7. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 40
B.9. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 40 B.8. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 41
B.10. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 40 B.9. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 41
B.11. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 40 B.10. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 41
B.12. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 40 B.11. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 41
B.13. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 40 B.12. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 41
B.14. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 40 B.13. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 41
B.15. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 41 B.14. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 41
B.16. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 41 B.15. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 41
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41 B.16. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 42
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 41 B.17. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 42
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
This document describes how QUIC [QUIC-TRANSPORT] is secured using This document describes how QUIC [QUIC-TRANSPORT] is secured using
TLS [TLS13]. TLS [TLS13].
TLS 1.3 provides critical latency improvements for connection TLS 1.3 provides critical latency improvements for connection
establishment over previous versions. Absent packet loss, most new establishment over previous versions. Absent packet loss, most new
connections can be established and secured within a single round connections can be established and secured within a single round
trip; on subsequent connections between the same client and server, trip; on subsequent connections between the same client and server,
skipping to change at page 6, line 5 skipping to change at page 6, line 7
() Indicates messages protected by early data (0-RTT) keys () Indicates messages protected by early data (0-RTT) keys
{} Indicates messages protected using handshake keys {} Indicates messages protected using handshake keys
[] Indicates messages protected using application data [] Indicates messages protected using application data
(1-RTT) keys (1-RTT) keys
Figure 1: TLS Handshake with 0-RTT Figure 1: TLS Handshake with 0-RTT
Data is protected using a number of encryption levels: Data is protected using a number of encryption levels:
o Plaintext o Initial Keys
o Early Data (0-RTT) Keys o Early Data (0-RTT) Keys
o Handshake Keys o Handshake Keys
o Application Data (1-RTT) Keys o Application Data (1-RTT) Keys
Application data may appear only in the early data and application Application data may appear only in the early data and application
data levels. Handshake and Alert messages may appear in any level. data levels. Handshake and Alert messages may appear in any level.
skipping to change at page 6, line 33 skipping to change at page 6, line 35
QUIC [QUIC-TRANSPORT] assumes responsibility for the confidentiality QUIC [QUIC-TRANSPORT] assumes responsibility for the confidentiality
and integrity protection of packets. For this it uses keys derived and integrity protection of packets. For this it uses keys derived
from a TLS handshake [TLS13], but instead of carrying TLS records from a TLS handshake [TLS13], but instead of carrying TLS records
over QUIC (as with TCP), TLS Handshake and Alert messages are carried over QUIC (as with TCP), TLS Handshake and Alert messages are carried
directly over the QUIC transport, which takes over the directly over the QUIC transport, which takes over the
responsibilities of the TLS record layer, as shown below. responsibilities of the TLS record layer, as shown below.
+--------------+--------------+ +-------------+ +--------------+--------------+ +-------------+
| TLS | TLS | | QUIC | | TLS | TLS | | QUIC |
| Handshake | Alerts | | Applications| | Handshake | Alerts | | Applications|
| | | | (h2q, etc.) | | | | | (h3, etc.) |
+--------------+--------------+-+-------------+ +--------------+--------------+-+-------------+
| | | |
| QUIC Transport | | QUIC Transport |
| (streams, reliability, congestion, etc.) | | (streams, reliability, congestion, etc.) |
| | | |
+---------------------------------------------+ +---------------------------------------------+
| | | |
| QUIC Packet Protection | | QUIC Packet Protection |
| | | |
+---------------------------------------------+ +---------------------------------------------+
skipping to change at page 8, line 11 skipping to change at page 8, line 11
produced by TLS is associated with the set of keys that TLS is produced by TLS is associated with the set of keys that TLS is
currently using. If QUIC needs to retransmit that data, it MUST use currently using. If QUIC needs to retransmit that data, it MUST use
the same keys even if TLS has already updated to newer keys. the same keys even if TLS has already updated to newer keys.
One important difference between TLS records (used with TCP) and QUIC One important difference between TLS records (used with TCP) and QUIC
CRYPTO frames is that in QUIC multiple frames may appear in the same CRYPTO frames is that in QUIC multiple frames may appear in the same
QUIC packet as long as they are associated with the same encryption QUIC packet as long as they are associated with the same encryption
level. For instance, an implementation might bundle a Handshake level. For instance, an implementation might bundle a Handshake
message and an ACK for some Handshake data into the same packet. message and an ACK for some Handshake data into the same packet.
Each encryption level has a specific list of frames which may appear Some frames are prohibited in different encryption levels, others
in it. The rules here generalize those of TLS, in that frames cannot be sent. The rules here generalize those of TLS, in that
associated with establishing the connection can usually appear at any frames associated with establishing the connection can usually appear
encryption level, whereas those associated with transferring data can at any encryption level, whereas those associated with transferring
only appear in the 0-RTT and 1-RTT encryption levels: data can only appear in the 0-RTT and 1-RTT encryption levels:
o CRYPTO frames MAY appear in packets of any encryption level except
0-RTT.
o CONNECTION_CLOSE MAY appear in packets of any encryption level
other than 0-RTT.
o PADDING frames MAY appear in packets of any encryption level. o PADDING frames MAY appear in packets of any encryption level.
o CRYPTO and CONNECTION_CLOSE frames MAY appear in packets of any
encryption level except 0-RTT.
o ACK frames MAY appear in packets of any encryption level other o ACK frames MAY appear in packets of any encryption level other
than 0-RTT, but can only acknowledge packets which appeared in than 0-RTT, but can only acknowledge packets which appeared in
that packet number space. that packet number space.
o STREAM frames MUST ONLY appear in the 0-RTT and 1-RTT levels. o All other frame types MUST only be sent in the 0-RTT and 1-RTT
levels.
o All other frame types MUST only appear at the 1-RTT levels. Note that it is not possible to send the following frames in 0-RTT
for various reasons: ACK, CRYPTO, NEW_TOKEN, PATH_RESPONSE, and
RETIRE_CONNECTION_ID.
Because packets could be reordered on the wire, QUIC uses the packet Because packets could be reordered on the wire, QUIC uses the packet
type to indicate which level a given packet was encrypted under, as type to indicate which level a given packet was encrypted under, as
shown in Table 1. When multiple packets of different encryption shown in Table 1. When multiple packets of different encryption
levels need to be sent, endpoints SHOULD use coalesced packets to levels need to be sent, endpoints SHOULD use coalesced packets to
send them in the same UDP datagram. send them in the same UDP datagram.
+-----------------+------------------+-----------+ +---------------------+------------------+-----------+
| Packet Type | Encryption Level | PN Space | | Packet Type | Encryption Level | PN Space |
+-----------------+------------------+-----------+ +---------------------+------------------+-----------+
| Initial | Initial secrets | Initial | | Initial | Initial secrets | Initial |
| | | | | | | |
| 0-RTT Protected | 0-RTT | 0/1-RTT | | 0-RTT Protected | 0-RTT | 0/1-RTT |
| | | | | | | |
| Handshake | Handshake | Handshake | | Handshake | Handshake | Handshake |
| | | | | | | |
| Retry | N/A | N/A | | Retry | N/A | N/A |
| | | | | | | |
| Short Header | 1-RTT | 0/1-RTT | | Version Negotiation | N/A | N/A |
+-----------------+------------------+-----------+ | | | |
| Short Header | 1-RTT | 0/1-RTT |
+---------------------+------------------+-----------+
Table 1: Encryption Levels by Packet Type Table 1: Encryption Levels by Packet Type
Section 17 of [QUIC-TRANSPORT] shows how packets at the various Section 17 of [QUIC-TRANSPORT] shows how packets at the various
encryption levels fit into the handshake process. encryption levels fit into the handshake process.
4.1. Interface to TLS 4.1. Interface to TLS
As shown in Figure 2, the interface from QUIC to TLS consists of As shown in Figure 2, the interface from QUIC to TLS consists of
three primary functions: three primary functions:
skipping to change at page 13, line 9 skipping to change at page 13, line 9
4.1.3. TLS Interface Summary 4.1.3. TLS Interface Summary
Figure 3 summarizes the exchange between QUIC and TLS for both client Figure 3 summarizes the exchange between QUIC and TLS for both client
and server. Each arrow is tagged with the encryption level used for and server. Each arrow is tagged with the encryption level used for
that transmission. that transmission.
Client Server Client Server
Get Handshake Get Handshake
Initial -------------> Initial ------------->
Rekey tx to 0-RTT Keys Install tx 0-RTT Keys
0-RTT ---------------> 0-RTT --------------->
Handshake Received Handshake Received
Get Handshake Get Handshake
<------------- Initial <------------- Initial
Rekey rx to 0-RTT keys Install rx 0-RTT keys
Handshake Received Install Handshake keys
Rekey rx to Handshake keys
Get Handshake Get Handshake
<----------- Handshake <----------- Handshake
Rekey tx to 1-RTT keys Install tx 1-RTT keys
<--------------- 1-RTT <--------------- 1-RTT
Handshake Received Handshake Received
Rekey rx to Handshake keys Install tx Handshake keys
Handshake Received Handshake Received
Get Handshake Get Handshake
Handshake Complete Handshake Complete
Handshake -----------> Handshake ----------->
Rekey tx to 1-RTT keys Install 1-RTT keys
1-RTT ---------------> 1-RTT --------------->
Handshake Received Handshake Received
Rekey rx to 1-RTT keys Install rx 1-RTT keys
Get Handshake
Handshake Complete Handshake Complete
Get Handshake
<--------------- 1-RTT <--------------- 1-RTT
Handshake Received Handshake Received
Figure 3: Interaction Summary between QUIC and TLS Figure 3: Interaction Summary between QUIC and TLS
4.2. TLS Version 4.2. TLS Version
This document describes how TLS 1.3 [TLS13] is used with QUIC. This document describes how TLS 1.3 [TLS13] is used with QUIC.
In practice, the TLS handshake will negotiate a version of TLS to In practice, the TLS handshake will negotiate a version of TLS to
skipping to change at page 18, line 24 skipping to change at page 18, line 24
Each encryption level has separate secret values for protection of Each encryption level has separate secret values for protection of
packets sent in each direction. These traffic secrets are derived by packets sent in each direction. These traffic secrets are derived by
TLS (see Section 7.1 of [TLS13]) and are used by QUIC for all TLS (see Section 7.1 of [TLS13]) and are used by QUIC for all
encryption levels except the Initial encryption level. The secrets encryption levels except the Initial encryption level. The secrets
for the Initial encryption level are computed based on the client's for the Initial encryption level are computed based on the client's
initial Destination Connection ID, as described in Section 5.2. initial Destination Connection ID, as described in Section 5.2.
The keys used for packet protection are computed from the TLS secrets The keys used for packet protection are computed from the TLS secrets
using the KDF provided by TLS. In TLS 1.3, the HKDF-Expand-Label using the KDF provided by TLS. In TLS 1.3, the HKDF-Expand-Label
function described in Section 7.1 of [TLS13]) is used, using the hash function described in Section 7.1 of [TLS13] is used, using the hash
function from the negotiated cipher suite. Other versions of TLS function from the negotiated cipher suite. Other versions of TLS
MUST provide a similar function in order to be used QUIC. MUST provide a similar function in order to be used with QUIC.
The current encryption level secret and the label "quic key" are The current encryption level secret and the label "quic key" are
input to the KDF to produce the AEAD key; the label "quic iv" is used input to the KDF to produce the AEAD key; the label "quic iv" is used
to derive the IV, see Section 5.3. The header protection key uses to derive the IV, see Section 5.3. The header protection key uses
the "quic hp" label, see Section 5.4). Using these labels provides the "quic hp" label, see Section 5.4. Using these labels provides
key separation between QUIC and TLS, see Section 9.4. key separation between QUIC and TLS, see Section 9.5.
The KDF used for initial secrets is always the HKDF-Expand-Label The KDF used for initial secrets is always the HKDF-Expand-Label
function from TLS 1.3 (see Section 5.2). function from TLS 1.3 (see Section 5.2).
5.2. Initial Secrets 5.2. Initial Secrets
Initial packets are protected with a secret derived from the Initial packets are protected with a secret derived from the
Destination Connection ID field from the client's first Initial Destination Connection ID field from the client's first Initial
packet of the connection. Specifically: packet of the connection. Specifically:
skipping to change at page 19, line 18 skipping to change at page 19, line 18
The connection ID used with HKDF-Expand-Label is the Destination The connection ID used with HKDF-Expand-Label is the Destination
Connection ID in the Initial packet sent by the client. This will be Connection ID in the Initial packet sent by the client. This will be
a randomly-selected value unless the client creates the Initial a randomly-selected value unless the client creates the Initial
packet after receiving a Retry packet, where the Destination packet after receiving a Retry packet, where the Destination
Connection ID is selected by the server. Connection ID is selected by the server.
The value of initial_salt is a 20 byte sequence shown in the figure The value of initial_salt is a 20 byte sequence shown in the figure
in hexadecimal notation. Future versions of QUIC SHOULD generate a in hexadecimal notation. Future versions of QUIC SHOULD generate a
new salt value, thus ensuring that the keys are different for each new salt value, thus ensuring that the keys are different for each
version of QUIC. This prevents a middlebox that only recognizes one version of QUIC. This prevents a middlebox that only recognizes one
version of QUIC from seeing or modifying the contents of handshake version of QUIC from seeing or modifying the contents of packets from
packets from future versions. future versions.
The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for
Initial packets even where the TLS versions offered do not include Initial packets even where the TLS versions offered do not include
TLS 1.3. TLS 1.3.
Appendix A contains test vectors for the initial packet encryption. Appendix A contains test vectors for the initial packet encryption.
Note: The Destination Connection ID is of arbitrary length, and it Note: The Destination Connection ID is of arbitrary length, and it
could be zero length if the server sends a Retry packet with a could be zero length if the server sends a Retry packet with a
zero-length Source Connection ID field. In this case, the Initial zero-length Source Connection ID field. In this case, the Initial
skipping to change at page 19, line 50 skipping to change at page 19, line 50
used. used.
Packets are protected prior to applying header protection Packets are protected prior to applying header protection
(Section 5.4). The unprotected packet header is part of the (Section 5.4). The unprotected packet header is part of the
associated data (A). When removing packet protection, an endpoint associated data (A). When removing packet protection, an endpoint
first removes the header protection. first removes the header protection.
All QUIC packets other than Version Negotiation and Retry packets are All QUIC packets other than Version Negotiation and Retry packets are
protected with an AEAD algorithm [AEAD]. Prior to establishing a protected with an AEAD algorithm [AEAD]. Prior to establishing a
shared secret, packets are protected with AEAD_AES_128_GCM and a key shared secret, packets are protected with AEAD_AES_128_GCM and a key
derived from the destination connection ID in the client's first derived from the Destination Connection ID in the client's first
Initial packet (see Section 5.2). This provides protection against Initial packet (see Section 5.2). This provides protection against
off-path attackers and robustness against QUIC version unaware off-path attackers and robustness against QUIC version unaware
middleboxes, but not against on-path attackers. middleboxes, but not against on-path attackers.
QUIC can use any of the ciphersuites defined in [TLS13] with the QUIC can use any of the ciphersuites defined in [TLS13] with the
exception of TLS_AES_128_CCM_8_SHA256. The AEAD for that exception of TLS_AES_128_CCM_8_SHA256. The AEAD for that
ciphersuite, AEAD_AES_128_CCM_8 [CCM], does not produce a large ciphersuite, AEAD_AES_128_CCM_8 [CCM], does not produce a large
enough authentication tag for use with the header protection designs enough authentication tag for use with the header protection designs
provided (see Section 5.4). All other ciphersuites defined in provided (see Section 5.4). All other ciphersuites defined in
[TLS13] have a 16-byte authentication tag and produce an output 16 [TLS13] have a 16-byte authentication tag and produce an output 16
skipping to change at page 28, line 31 skipping to change at page 28, line 31
version information is copied into the TLS handshake, which provides version information is copied into the TLS handshake, which provides
integrity protection for the QUIC negotiation. This does not prevent integrity protection for the QUIC negotiation. This does not prevent
version downgrade prior to the completion of the handshake, though it version downgrade prior to the completion of the handshake, though it
means that a downgrade causes a handshake failure. means that a downgrade causes a handshake failure.
QUIC requires that the cryptographic handshake provide authenticated QUIC requires that the cryptographic handshake provide authenticated
protocol negotiation. TLS uses Application Layer Protocol protocol negotiation. TLS uses Application Layer Protocol
Negotiation (ALPN) [RFC7301] to select an application protocol. Negotiation (ALPN) [RFC7301] to select an application protocol.
Unless another mechanism is used for agreeing on an application Unless another mechanism is used for agreeing on an application
protocol, endpoints MUST use ALPN for this purpose. When using ALPN, protocol, endpoints MUST use ALPN for this purpose. When using ALPN,
endpoints MUST abort a connection if an application protocol is not endpoints MUST immediately close a connection (see Section 10.3 in
negotiated. [QUIC-TRANSPORT]) if an application protocol is not negotiated with a
no_application_protocol TLS alert (QUIC error code 0x178, see
Section 4.8). While [RFC7301] only specifies that servers use this
alert, QUIC clients MUST also use it to terminate a connection when
ALPN negotiation fails.
An application-layer protocol MAY restrict the QUIC versions that it An application-layer protocol MAY restrict the QUIC versions that it
can operate over. Servers MUST select an application protocol can operate over. Servers MUST select an application protocol
compatible with the QUIC version that the client has selected. If compatible with the QUIC version that the client has selected. If
the server cannot select a compatible combination of application the server cannot select a compatible combination of application
protocol and QUIC version, it MUST abort the connection. A client protocol and QUIC version, it MUST abort the connection. A client
MUST abort a connection if the server picks an incompatible MUST abort a connection if the server picks an incompatible
combination of QUIC version and ALPN identifier. combination of QUIC version and ALPN identifier.
8.2. QUIC Transport Parameters Extension 8.2. QUIC Transport Parameters Extension
skipping to change at page 29, line 8 skipping to change at page 29, line 12
Including transport parameters in the TLS handshake provides Including transport parameters in the TLS handshake provides
integrity protection for these values. integrity protection for these values.
enum { enum {
quic_transport_parameters(0xffa5), (65535) quic_transport_parameters(0xffa5), (65535)
} ExtensionType; } ExtensionType;
The "extension_data" field of the quic_transport_parameters extension The "extension_data" field of the quic_transport_parameters extension
contains a value that is defined by the version of QUIC that is in contains a value that is defined by the version of QUIC that is in
use. The quic_transport_parameters extension carries a use. The quic_transport_parameters extension carries a
TransportParameters when the version of QUIC defined in TransportParameters struct when the version of QUIC defined in
[QUIC-TRANSPORT] is used. [QUIC-TRANSPORT] is used.
The quic_transport_parameters extension is carried in the ClientHello The quic_transport_parameters extension is carried in the ClientHello
and the EncryptedExtensions messages during the handshake. and the EncryptedExtensions messages during the handshake.
While the transport parameters are technically available prior to the While the transport parameters are technically available prior to the
completion of the handshake, they cannot be fully trusted until the completion of the handshake, they cannot be fully trusted until the
handshake completes, and reliance on them should be minimized. handshake completes, and reliance on them should be minimized.
However, any tampering with the parameters will cause the handshake However, any tampering with the parameters will cause the handshake
to fail. to fail.
skipping to change at page 29, line 47 skipping to change at page 30, line 5
9. Security Considerations 9. Security Considerations
There are likely to be some real clangers here eventually, but the There are likely to be some real clangers here eventually, but the
current set of issues is well captured in the relevant sections of current set of issues is well captured in the relevant sections of
the main text. the main text.
Never assume that because it isn't in the security considerations Never assume that because it isn't in the security considerations
section it doesn't affect security. Most of this document does. section it doesn't affect security. Most of this document does.
9.1. Packet Reflection Attack Mitigation 9.1. Replay Attacks with 0-RTT
As described in Section 8 of [TLS13], use of TLS early data comes
with an exposure to replay attack. The use of 0-RTT in QUIC is
similarly vulnerable to replay attack.
Endpoints MUST implement and use the replay protections described in
[TLS13], however it is recognized that these protections are
imperfect. Therefore, additional consideration of the risk of replay
is needed.
QUIC is not vulnerable to replay attack, except via the application
protocol information it might carry. The management of QUIC protocol
state based on the frame types defined in [QUIC-TRANSPORT] is not
vulnerable to replay. Processing of QUIC frames is idempotent and
cannot result in invalid connection states if frames are replayed,
reordered or lost. QUIC connections do not produce effects that last
beyond the lifetime of the connection, except for those produced by
the application protocol that QUIC serves.
Note: TLS session tickets and address validation tokens are used to
carry QUIC configuration information between connections. These
MUST NOT be used to carry application semantics. The potential
for reuse of these tokens means that they require stronger
protections against replay.
A server that accepts 0-RTT on a connection incurs a higher cost than
accepting a connection without 0-RTT. This includes higher
processing and computation costs. Servers need to consider the
probability of replay and all associated costs when accepting 0-RTT.
Ultimately, the responsibility for managing the risks of replay
attacks with 0-RTT lies with an application protocol. An application
protocol that uses QUIC MUST describe how the protocol uses 0-RTT and
the measures that are employed to protect against replay attack. An
analysis of replay risk needs to consider all QUIC protocol features
that carry application semantics.
Disabling 0-RTT entirely is the most effective defense against replay
attack.
QUIC extensions MUST describe how replay attacks affects their
operation, or prohibit their use in 0-RTT. Application protocols
MUST either prohibit the use of extensions that carry application
semantics in 0-RTT or provide replay mitigation strategies.
9.2. Packet Reflection Attack Mitigation
A small ClientHello that results in a large block of handshake A small ClientHello that results in a large block of handshake
messages from a server can be used in packet reflection attacks to messages from a server can be used in packet reflection attacks to
amplify the traffic generated by an attacker. amplify the traffic generated by an attacker.
QUIC includes three defenses against this attack. First, the packet QUIC includes three defenses against this attack. First, the packet
containing a ClientHello MUST be padded to a minimum size. Second, containing a ClientHello MUST be padded to a minimum size. Second,
if responding to an unverified source address, the server is if responding to an unverified source address, the server is
forbidden to send more than three UDP datagrams in its first flight forbidden to send more than three UDP datagrams in its first flight
(see Section 8.1 of [QUIC-TRANSPORT]). Finally, because (see Section 8.1 of [QUIC-TRANSPORT]). Finally, because
acknowledgements of Handshake packets are authenticated, a blind acknowledgements of Handshake packets are authenticated, a blind
attacker cannot forge them. Put together, these defenses limit the attacker cannot forge them. Put together, these defenses limit the
level of amplification. level of amplification.
9.2. Peer Denial of Service 9.3. Peer Denial of Service
QUIC, TLS, and HTTP/2 all contain messages that have legitimate uses QUIC, TLS, and HTTP/2 all contain messages that have legitimate uses
in some contexts, but that can be abused to cause a peer to expend in some contexts, but that can be abused to cause a peer to expend
processing resources without having any observable impact on the processing resources without having any observable impact on the
state of the connection. If processing is disproportionately large state of the connection. If processing is disproportionately large
in comparison to the observable effects on bandwidth or state, then in comparison to the observable effects on bandwidth or state, then
this could allow a malicious peer to exhaust processing capacity this could allow a malicious peer to exhaust processing capacity
without consequence. without consequence.
QUIC prohibits the sending of empty "STREAM" frames unless they are QUIC prohibits the sending of empty "STREAM" frames unless they are
marked with the FIN bit. This prevents "STREAM" frames from being marked with the FIN bit. This prevents "STREAM" frames from being
sent that only waste effort. sent that only waste effort.
While there are legitimate uses for some redundant packets, While there are legitimate uses for some redundant packets,
implementations SHOULD track redundant packets and treat excessive implementations SHOULD track redundant packets and treat excessive
volumes of any non-productive packets as indicative of an attack. volumes of any non-productive packets as indicative of an attack.
9.3. Header Protection Analysis 9.4. Header Protection Analysis
Header protection relies on the packet protection AEAD being a Header protection relies on the packet protection AEAD being a
pseudorandom function (PRF), which is not a property that AEAD pseudorandom function (PRF), which is not a property that AEAD
algorithms guarantee. Therefore, no strong assurances about the algorithms guarantee. Therefore, no strong assurances about the
general security of this mechanism can be shown in the general case. general security of this mechanism can be shown in the general case.
The AEAD algorithms described in this document are assumed to be The AEAD algorithms described in this document are assumed to be
PRFs. PRFs.
The header protection algorithms defined in this document take the The header protection algorithms defined in this document take the
form: form:
skipping to change at page 31, line 32 skipping to change at page 32, line 39
reveal through timing side-channels that the packet number matches a reveal through timing side-channels that the packet number matches a
received packet. For authentication to be free from side-channels, received packet. For authentication to be free from side-channels,
the entire process of header protection removal, packet number the entire process of header protection removal, packet number
recovery, and packet protection removal MUST be applied together recovery, and packet protection removal MUST be applied together
without timing and other side-channels. without timing and other side-channels.
For the sending of packets, construction and protection of packet For the sending of packets, construction and protection of packet
payloads and packet numbers MUST be free from side-channels that payloads and packet numbers MUST be free from side-channels that
would reveal the packet number or its encoded size. would reveal the packet number or its encoded size.
9.4. Key Diversity 9.5. Key Diversity
In using TLS, the central key schedule of TLS is used. As a result In using TLS, the central key schedule of TLS is used. As a result
of the TLS handshake messages being integrated into the calculation of the TLS handshake messages being integrated into the calculation
of secrets, the inclusion of the QUIC transport parameters extension of secrets, the inclusion of the QUIC transport parameters extension
ensures that handshake and 1-RTT keys are not the same as those that ensures that handshake and 1-RTT keys are not the same as those that
might be produced by a server running TLS over TCP. However, 0-RTT might be produced by a server running TLS over TCP. To avoid the
keys only include the ClientHello message and might therefore use the possibility of cross-protocol key synchronization, additional
same secrets. To avoid the possibility of cross-protocol key measures are provided to improve key separation.
synchronization, additional measures are provided to improve key
separation.
The QUIC packet protection keys and IVs are derived using a different The QUIC packet protection keys and IVs are derived using a different
label than the equivalent keys in TLS. label than the equivalent keys in TLS.
To preserve this separation, a new version of QUIC SHOULD define new To preserve this separation, a new version of QUIC SHOULD define new
labels for key derivation for packet protection key and IV, plus the labels for key derivation for packet protection key and IV, plus the
header protection keys. header protection keys. This version of QUIC uses the string "quic".
Other versions can use a version-specific label in place of that
string.
The initial secrets also use a key that is specific to the negotiated The initial secrets use a key that is specific to the negotiated QUIC
QUIC version. New QUIC versions SHOULD define a new salt value used version. New QUIC versions SHOULD define a new salt value used in
in calculating initial secrets. calculating initial secrets.
10. IANA Considerations 10. IANA Considerations
This document does not create any new IANA registries, but it This document does not create any new IANA registries, but it
registers the values in the following registries: registers the values in the following registries:
o TLS ExtensionsType Registry [TLS-REGISTRIES] - IANA is to register o TLS ExtensionsType Registry [TLS-REGISTRIES] - IANA is to register
the quic_transport_parameters extension found in Section 8.2. The the quic_transport_parameters extension found in Section 8.2. The
Recommended column is to be marked Yes. The TLS 1.3 Column is to Recommended column is to be marked Yes. The TLS 1.3 Column is to
include CH and EE. include CH and EE.
skipping to change at page 32, line 37 skipping to change at page 33, line 43
[AES] "Advanced encryption standard (AES)", National Institute [AES] "Advanced encryption standard (AES)", National Institute
of Standards and Technology report, of Standards and Technology report,
DOI 10.6028/nist.fips.197, November 2001. DOI 10.6028/nist.fips.197, November 2001.
[CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF [CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>. <https://www.rfc-editor.org/info/rfc8439>.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", draft-ietf-quic-recovery-18 (work and Congestion Control", draft-ietf-quic-recovery-latest
in progress). (work in progress).
[QUIC-TRANSPORT] [QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", draft-ietf-quic- Multiplexed and Secure Transport", draft-ietf-quic-
transport-18 (work in progress). transport-latest (work in progress).
[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>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] 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>.
skipping to change at page 33, line 45 skipping to change at page 34, line 50
Transport Layer Security (TLS)", RFC 6655, Transport Layer Security (TLS)", RFC 6655,
DOI 10.17487/RFC6655, July 2012, DOI 10.17487/RFC6655, July 2012,
<https://www.rfc-editor.org/info/rfc6655>. <https://www.rfc-editor.org/info/rfc6655>.
[IMC] Katz, J. and Y. Lindell, "Introduction to Modern [IMC] Katz, J. and Y. Lindell, "Introduction to Modern
Cryptography, Second Edition", ISBN 978-1466570269, Cryptography, Second Edition", ISBN 978-1466570269,
November 2014. November 2014.
[QUIC-HTTP] [QUIC-HTTP]
Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over
QUIC", draft-ietf-quic-http-18 (work in progress). QUIC", draft-ietf-quic-http-latest (work in progress).
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
skipping to change at page 38, line 31 skipping to change at page 39, line 31
15599ef5014ea38c44bdfd387c03b527 5c35e009b6238f831420047c7271281c 15599ef5014ea38c44bdfd387c03b527 5c35e009b6238f831420047c7271281c
cb54df7884 cb54df7884
Appendix B. Change Log Appendix B. Change Log
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
Issue and pull request numbers are listed with a leading octothorp. Issue and pull request numbers are listed with a leading octothorp.
B.1. Since draft-ietf-quic-tls-17 B.1. Since draft-ietf-quic-tls-18
o Increased the set of permissible frames in 0-RTT (#2344, #2355)
B.2. Since draft-ietf-quic-tls-17
o Endpoints discard initial keys as soon as handshake keys are o Endpoints discard initial keys as soon as handshake keys are
available (#1951, #2045) available (#1951, #2045)
o Use of ALPN or equivalent is mandatory (#2263, #2284) o Use of ALPN or equivalent is mandatory (#2263, #2284)
B.2. Since draft-ietf-quic-tls-14 B.3. Since draft-ietf-quic-tls-14
o Update the salt used for Initial secrets (#1970) o Update the salt used for Initial secrets (#1970)
o Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019) o Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019)
o Change header protection o Change header protection
* Sample from a fixed offset (#1575, #2030) * Sample from a fixed offset (#1575, #2030)
* Cover part of the first byte, including the key phase (#1322, * Cover part of the first byte, including the key phase (#1322,
#2006) #2006)
o TLS provides an AEAD and KDF function (#2046) o TLS provides an AEAD and KDF function (#2046)
* Clarify that the TLS KDF is used with TLS (#1997) * Clarify that the TLS KDF is used with TLS (#1997)
* Change the labels for calculation of QUIC keys (#1845, #1971, * Change the labels for calculation of QUIC keys (#1845, #1971,
#1991) #1991)
o Initial keys are discarded once Handshake are avaialble (#1951, o Initial keys are discarded once Handshake are avaialble (#1951,
#2045) #2045)
B.3. Since draft-ietf-quic-tls-13 B.4. Since draft-ietf-quic-tls-13
o Updated to TLS 1.3 final (#1660) o Updated to TLS 1.3 final (#1660)
B.4. Since draft-ietf-quic-tls-12 B.5. Since draft-ietf-quic-tls-12
o Changes to integration of the TLS handshake (#829, #1018, #1094, o Changes to integration of the TLS handshake (#829, #1018, #1094,
#1165, #1190, #1233, #1242, #1252, #1450) #1165, #1190, #1233, #1242, #1252, #1450)
* The cryptographic handshake uses CRYPTO frames, not stream 0 * The cryptographic handshake uses CRYPTO frames, not stream 0
* QUIC packet protection is used in place of TLS record * QUIC packet protection is used in place of TLS record
protection protection
* Separate QUIC packet number spaces are used for the handshake * Separate QUIC packet number spaces are used for the handshake
* Changed Retry to be independent of the cryptographic handshake * Changed Retry to be independent of the cryptographic handshake
* Limit the use of HelloRetryRequest to address TLS needs (like * Limit the use of HelloRetryRequest to address TLS needs (like
key shares) key shares)
o Changed codepoint of TLS extension (#1395, #1402) o Changed codepoint of TLS extension (#1395, #1402)
B.5. Since draft-ietf-quic-tls-11 B.6. Since draft-ietf-quic-tls-11
o Encrypted packet numbers. o Encrypted packet numbers.
B.6. Since draft-ietf-quic-tls-10 B.7. Since draft-ietf-quic-tls-10
o No significant changes. o No significant changes.
B.7. Since draft-ietf-quic-tls-09 B.8. Since draft-ietf-quic-tls-09
o Cleaned up key schedule and updated the salt used for handshake o Cleaned up key schedule and updated the salt used for handshake
packet protection (#1077) packet protection (#1077)
B.8. Since draft-ietf-quic-tls-08 B.9. Since draft-ietf-quic-tls-08
o Specify value for max_early_data_size to enable 0-RTT (#942) o Specify value for max_early_data_size to enable 0-RTT (#942)
o Update key derivation function (#1003, #1004) o Update key derivation function (#1003, #1004)
B.9. Since draft-ietf-quic-tls-07 B.10. Since draft-ietf-quic-tls-07
o Handshake errors can be reported with CONNECTION_CLOSE (#608, o Handshake errors can be reported with CONNECTION_CLOSE (#608,
#891) #891)
B.10. Since draft-ietf-quic-tls-05 B.11. Since draft-ietf-quic-tls-05
No significant changes. No significant changes.
B.11. Since draft-ietf-quic-tls-04 B.12. Since draft-ietf-quic-tls-04
o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
B.12. Since draft-ietf-quic-tls-03 B.13. Since draft-ietf-quic-tls-03
No significant changes. No significant changes.
B.13. Since draft-ietf-quic-tls-02 B.14. Since draft-ietf-quic-tls-02
o Updates to match changes in transport draft o Updates to match changes in transport draft
B.14. Since draft-ietf-quic-tls-01 B.15. Since draft-ietf-quic-tls-01
o Use TLS alerts to signal TLS errors (#272, #374) o Use TLS alerts to signal TLS errors (#272, #374)
o Require ClientHello to fit in a single packet (#338) o Require ClientHello to fit in a single packet (#338)
o The second client handshake flight is now sent in the clear (#262, o The second client handshake flight is now sent in the clear (#262,
#337) #337)
o The QUIC header is included as AEAD Associated Data (#226, #243, o The QUIC header is included as AEAD Associated Data (#226, #243,
#302) #302)
skipping to change at page 40, line 47 skipping to change at page 42, line 4
o The second client handshake flight is now sent in the clear (#262, o The second client handshake flight is now sent in the clear (#262,
#337) #337)
o The QUIC header is included as AEAD Associated Data (#226, #243, o The QUIC header is included as AEAD Associated Data (#226, #243,
#302) #302)
o Add interface necessary for client address validation (#275) o Add interface necessary for client address validation (#275)
o Define peer authentication (#140) o Define peer authentication (#140)
o Require at least TLS 1.3 (#138) o Require at least TLS 1.3 (#138)
o Define transport parameters as a TLS extension (#122) o Define transport parameters as a TLS extension (#122)
o Define handling for protected packets before the handshake o Define handling for protected packets before the handshake
completes (#39) completes (#39)
o Decouple QUIC version and ALPN (#12) o Decouple QUIC version and ALPN (#12)
B.15. Since draft-ietf-quic-tls-00 B.16. Since draft-ietf-quic-tls-00
o Changed bit used to signal key phase o Changed bit used to signal key phase
o Updated key phase markings during the handshake o Updated key phase markings during the handshake
o Added TLS interface requirements section o Added TLS interface requirements section
o Moved to use of TLS exporters for key derivation o Moved to use of TLS exporters for key derivation
o Moved TLS error code definitions into this document o Moved TLS error code definitions into this document
B.16. Since draft-thomson-quic-tls-01 B.17. Since draft-thomson-quic-tls-01
o Adopted as base for draft-ietf-quic-tls o Adopted as base for draft-ietf-quic-tls
o Updated authors/editors list o Updated authors/editors list
o Added status note o Added status note
Acknowledgments Acknowledgments
This document has benefited from input from Dragana Damjanovic, This document has benefited from input from Dragana Damjanovic,
 End of changes. 55 change blocks. 
119 lines changed or deleted 176 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/