draft-ietf-quic-tls-latest.txt   draft-ietf-quic-tls-auth48.txt 
skipping to change at page 2, line 7 skipping to change at line 46
(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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 2. Notational Conventions
2.1. TLS Overview . . . . . . . . . . . . . . . . . . . . . . 4 2.1. TLS Overview
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Overview
4. Carrying TLS Messages . . . . . . . . . . . . . . . . . . . . 8 4. Carrying TLS Messages
4.1. Interface to TLS . . . . . . . . . . . . . . . . . . . . 9 4.1. Interface to TLS
4.1.1. Handshake Complete . . . . . . . . . . . . . . . . . 9 4.1.1. Handshake Complete
4.1.2. Handshake Confirmed . . . . . . . . . . . . . . . . . 10 4.1.2. Handshake Confirmed
4.1.3. Sending and Receiving Handshake Messages . . . . . . 10 4.1.3. Sending and Receiving Handshake Messages
4.1.4. Encryption Level Changes . . . . . . . . . . . . . . 12 4.1.4. Encryption Level Changes
4.1.5. TLS Interface Summary . . . . . . . . . . . . . . . . 13 4.1.5. TLS Interface Summary
4.2. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. TLS Version
4.3. ClientHello Size . . . . . . . . . . . . . . . . . . . . 15 4.3. ClientHello Size
4.4. Peer Authentication . . . . . . . . . . . . . . . . . . . 16 4.4. Peer Authentication
4.5. Session Resumption . . . . . . . . . . . . . . . . . . . 17 4.5. Session Resumption
4.6. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.6. 0-RTT
4.6.1. Enabling 0-RTT . . . . . . . . . . . . . . . . . . . 18 4.6.1. Enabling 0-RTT
4.6.2. Accepting and Rejecting 0-RTT . . . . . . . . . . . . 18 4.6.2. Accepting and Rejecting 0-RTT
4.6.3. Validating 0-RTT Configuration . . . . . . . . . . . 19 4.6.3. Validating 0-RTT Configuration
4.7. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 19 4.7. HelloRetryRequest
4.8. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 19 4.8. TLS Errors
4.9. Discarding Unused Keys . . . . . . . . . . . . . . . . . 20 4.9. Discarding Unused Keys
4.9.1. Discarding Initial Keys . . . . . . . . . . . . . . . 21 4.9.1. Discarding Initial Keys
4.9.2. Discarding Handshake Keys . . . . . . . . . . . . . . 21 4.9.2. Discarding Handshake Keys
4.9.3. Discarding 0-RTT Keys . . . . . . . . . . . . . . . . 21 4.9.3. Discarding 0-RTT Keys
5. Packet Protection . . . . . . . . . . . . . . . . . . . . . . 22 5. Packet Protection
5.1. Packet Protection Keys . . . . . . . . . . . . . . . . . 22 5.1. Packet Protection Keys
5.2. Initial Secrets . . . . . . . . . . . . . . . . . . . . . 23 5.2. Initial Secrets
5.3. AEAD Usage . . . . . . . . . . . . . . . . . . . . . . . 24 5.3. AEAD Usage
5.4. Header Protection . . . . . . . . . . . . . . . . . . . . 25 5.4. Header Protection
5.4.1. Header Protection Application . . . . . . . . . . . . 26 5.4.1. Header Protection Application
5.4.2. Header Protection Sample . . . . . . . . . . . . . . 29 5.4.2. Header Protection Sample
5.4.3. AES-Based Header Protection . . . . . . . . . . . . . 30 5.4.3. AES-Based Header Protection
5.4.4. ChaCha20-Based Header Protection . . . . . . . . . . 30 5.4.4. ChaCha20-Based Header Protection
5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 31 5.5. Receiving Protected Packets
5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 31 5.6. Use of 0-RTT Keys
5.7. Receiving Out-of-Order Protected Packets . . . . . . . . 32 5.7. Receiving Out-of-Order Protected Packets
5.8. Retry Packet Integrity . . . . . . . . . . . . . . . . . 33 5.8. Retry Packet Integrity
6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 34 6. Key Update
6.1. Initiating a Key Update . . . . . . . . . . . . . . . . . 36 6.1. Initiating a Key Update
6.2. Responding to a Key Update . . . . . . . . . . . . . . . 37 6.2. Responding to a Key Update
6.3. Timing of Receive Key Generation . . . . . . . . . . . . 37 6.3. Timing of Receive Key Generation
6.4. Sending with Updated Keys . . . . . . . . . . . . . . . . 38 6.4. Sending with Updated Keys
6.5. Receiving with Different Keys . . . . . . . . . . . . . . 38 6.5. Receiving with Different Keys
6.6. Limits on AEAD Usage . . . . . . . . . . . . . . . . . . 39 6.6. Limits on AEAD Usage
6.7. Key Update Error Code . . . . . . . . . . . . . . . . . . 41 6.7. Key Update Error Code
7. Security of Initial Messages
7. Security of Initial Messages . . . . . . . . . . . . . . . . 41 8. QUIC-Specific Adjustments to the TLS Handshake
8. QUIC-Specific Adjustments to the TLS Handshake . . . . . . . 41 8.1. Protocol Negotiation
8.1. Protocol Negotiation . . . . . . . . . . . . . . . . . . 42 8.2. QUIC Transport Parameters Extension
8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 42 8.3. Removing the EndOfEarlyData Message
8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 43 8.4. Prohibit TLS Middlebox Compatibility Mode
8.4. Prohibit TLS Middlebox Compatibility Mode . . . . . . . . 43 9. Security Considerations
9. Security Considerations . . . . . . . . . . . . . . . . . . . 44 9.1. Session Linkability
9.1. Session Linkability . . . . . . . . . . . . . . . . . . . 44 9.2. Replay Attacks with 0-RTT
9.2. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 44 9.3. Packet Reflection Attack Mitigation
9.3. Packet Reflection Attack Mitigation . . . . . . . . . . . 45 9.4. Header Protection Analysis
9.4. Header Protection Analysis . . . . . . . . . . . . . . . 45 9.5. Header Protection Timing Side Channels
9.5. Header Protection Timing Side Channels . . . . . . . . . 46 9.6. Key Diversity
9.6. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 47 9.7. Randomness
9.7. Randomness . . . . . . . . . . . . . . . . . . . . . . . 47 10. IANA Considerations
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 11. References
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 11.1. Normative References
11.1. Normative References . . . . . . . . . . . . . . . . . . 48 11.2. Informative References
11.2. Informative References . . . . . . . . . . . . . . . . . 49 Appendix A. Sample Packet Protection
Appendix A. Sample Packet Protection . . . . . . . . . . . . . . 51 A.1. Keys
A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 51 A.2. Client Initial
A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 52 A.3. Server Initial
A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 54 A.4. Retry
A.4. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 55 A.5. ChaCha20-Poly1305 Short Header Packet
A.5. ChaCha20-Poly1305 Short Header Packet . . . . . . . . . . 55 Appendix B. AEAD Algorithm Analysis
Appendix B. AEAD Algorithm Analysis . . . . . . . . . . . . . . 57
B.1. Analysis of AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage B.1. Analysis of AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage
Limits . . . . . . . . . . . . . . . . . . . . . . . . . 58 Limits
B.1.1. Confidentiality Limit . . . . . . . . . . . . . . . . 58 B.1.1. Confidentiality Limit
B.1.2. Integrity Limit . . . . . . . . . . . . . . . . . . . 58 B.1.2. Integrity Limit
B.2. Analysis of AEAD_AES_128_CCM Usage Limits . . . . . . . . 59 B.2. Analysis of AEAD_AES_128_CCM Usage Limits
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 Authors' Addresses
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 4, line 38 skipping to change at line 172
+-------------+------------+--------------+---------+ +-------------+------------+--------------+---------+
Content | | | Application | | Content | | | Application | |
Layer | Handshake | Alerts | Data | ... | Layer | Handshake | Alerts | Data | ... |
| | | | | | | | | |
+-------------+------------+--------------+---------+ +-------------+------------+--------------+---------+
Record | | Record | |
Layer | Records | Layer | Records |
| | | |
+---------------------------------------------------+ +---------------------------------------------------+
Figure 1: TLS Layers Figure 1: TLS Layers
Each content-layer message (e.g., handshake, alerts, and application Each content-layer message (e.g., handshake, alerts, and application
data) is carried as a series of typed TLS records by the record data) is carried as a series of typed TLS records by the record
layer. Records are individually cryptographically protected and then layer. Records are individually cryptographically protected and then
transmitted over a reliable transport (typically TCP), which provides transmitted over a reliable transport (typically TCP), which provides
sequencing and guaranteed delivery. sequencing and guaranteed delivery.
The TLS authenticated key exchange occurs between two endpoints: The TLS authenticated key exchange occurs between two endpoints:
client and server. The client initiates the exchange and the server client and server. The client initiates the exchange and the server
responds. If the key exchange completes successfully, both client responds. If the key exchange completes successfully, both client
skipping to change at page 5, line 20 skipping to change at line 203
TLS supports X.509 [RFC5280] certificate-based authentication for TLS supports X.509 [RFC5280] certificate-based authentication for
both server and client. When PSK key exchange is used (as in both server and client. When PSK key exchange is used (as in
resumption), knowledge of the PSK serves to authenticate the peer. resumption), knowledge of the PSK serves to authenticate the peer.
The TLS key exchange is resistant to tampering by attackers, and it The TLS key exchange is resistant to tampering by attackers, and it
produces shared secrets that cannot be controlled by either produces shared secrets that cannot be controlled by either
participating peer. participating peer.
TLS provides two basic handshake modes of interest to QUIC: TLS provides two basic handshake modes of interest to QUIC:
o A full 1-RTT handshake, in which the client is able to send * A full 1-RTT handshake, in which the client is able to send
application data after one round trip and the server immediately application data after one round trip and the server immediately
responds after receiving the first handshake message from the responds after receiving the first handshake message from the
client. client.
o A 0-RTT handshake, in which the client uses information it has * A 0-RTT handshake, in which the client uses information it has
previously learned about the server to send application data previously learned about the server to send application data
immediately. This application data can be replayed by an immediately. This application data can be replayed by an
attacker, so 0-RTT is not suitable for carrying instructions that attacker, so 0-RTT is not suitable for carrying instructions that
might initiate any action that could cause unwanted effects if might initiate any action that could cause unwanted effects if
replayed. replayed.
A simplified TLS handshake with 0-RTT application data is shown in A simplified TLS handshake with 0-RTT application data is shown in
Figure 2. Figure 2.
Client Server Client Server
skipping to change at page 6, line 22 skipping to change at line 235
<-------- [Application Data] <-------- [Application Data]
{Finished} --------> {Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
() 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 2: TLS Handshake with 0-RTT Figure 2: TLS Handshake with 0-RTT
Figure 2 omits the EndOfEarlyData message, which is not used in QUIC; Figure 2 omits the EndOfEarlyData message, which is not used in QUIC;
see Section 8.3. Likewise, neither ChangeCipherSpec nor KeyUpdate see Section 8.3. Likewise, neither ChangeCipherSpec nor KeyUpdate
messages are used by QUIC. ChangeCipherSpec is redundant in TLS 1.3; messages are used by QUIC. ChangeCipherSpec is redundant in TLS 1.3;
see Section 8.4. QUIC has its own key update mechanism; see see Section 8.4. QUIC has its own key update mechanism; see
Section 6. Section 6.
Data is protected using a number of encryption levels: Data is protected using a number of encryption levels:
o Initial keys * Initial keys
o Early data (0-RTT) keys * Early data (0-RTT) keys
o Handshake keys * Handshake keys
o Application data (1-RTT) keys * Application data (1-RTT) keys
Application data can only appear in the early data and application Application data can only appear 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.
The 0-RTT handshake can be used if the client and server have The 0-RTT handshake can be used if the client and server have
previously communicated. In the 1-RTT handshake, the client is previously communicated. In the 1-RTT handshake, the client is
unable to send protected application data until it has received all unable to send protected application data until it has received all
of the handshake messages sent by the server. of the handshake messages sent by the server.
3. Protocol Overview 3. Protocol Overview
skipping to change at page 7, line 35 skipping to change at line 297
QUIC also relies on TLS for authentication and negotiation of QUIC also relies on TLS for authentication and negotiation of
parameters that are critical to security and performance. parameters that are critical to security and performance.
Rather than a strict layering, these two protocols cooperate: QUIC Rather than a strict layering, these two protocols cooperate: QUIC
uses the TLS handshake; TLS uses the reliability, ordered delivery, uses the TLS handshake; TLS uses the reliability, ordered delivery,
and record layer provided by QUIC. and record layer provided by QUIC.
At a high level, there are two main interactions between the TLS and At a high level, there are two main interactions between the TLS and
QUIC components: QUIC components:
o The TLS component sends and receives messages via the QUIC * The TLS component sends and receives messages via the QUIC
component, with QUIC providing a reliable stream abstraction to component, with QUIC providing a reliable stream abstraction to
TLS. TLS.
o The TLS component provides a series of updates to the QUIC * The TLS component provides a series of updates to the QUIC
component, including (a) new packet protection keys to install and component, including (a) new packet protection keys to install and
(b) state changes such as handshake completion, the server (b) state changes such as handshake completion, the server
certificate, etc. certificate, etc.
Figure 4 shows these interactions in more detail, with the QUIC Figure 4 shows these interactions in more detail, with the QUIC
packet protection being called out specially. packet protection being called out specially.
+------------+ +------------+ +------------+ +------------+
| |<---- Handshake Messages ----->| | | |<---- Handshake Messages ----->| |
| |<- Validate 0-RTT Parameters ->| | | |<- Validate 0-RTT Parameters ->| |
skipping to change at page 9, line 5 skipping to change at line 356
packet number space that is used determines the semantics of frames. packet number space that is used determines the semantics of frames.
Some frames are prohibited in different packet number spaces; see Some frames are prohibited in different packet number spaces; see
Section 12.5 of [QUIC-TRANSPORT]. Section 12.5 of [QUIC-TRANSPORT].
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 keys were used to protect a given packet, as type to indicate which keys were used to protect a given packet, as
shown in Table 1. When packets of different types need to be sent, shown in Table 1. When packets of different types need to be sent,
endpoints SHOULD use coalesced packets to send them in the same UDP endpoints SHOULD use coalesced packets to send them in the same UDP
datagram. datagram.
+---------------------+-----------------+------------------+ +=====================+=================+==================+
| Packet Type | Encryption Keys | PN Space | | Packet Type | Encryption Keys | PN Space |
+---------------------+-----------------+------------------+ +=====================+=================+==================+
| Initial | Initial secrets | Initial | | Initial | Initial secrets | Initial |
| | | | +=====================+-----------------+------------------+
| 0-RTT Protected | 0-RTT | Application data | | 0-RTT Protected | 0-RTT | Application data |
| | | | +=====================+-----------------+------------------+
| Handshake | Handshake | Handshake | | Handshake | Handshake | Handshake |
| | | | +=====================+-----------------+------------------+
| Retry | Retry | N/A | | Retry | Retry | N/A |
| | | | +=====================+-----------------+------------------+
| Version Negotiation | N/A | N/A | | Version Negotiation | N/A | N/A |
| | | | +=====================+-----------------+------------------+
| Short Header | 1-RTT | Application data | | Short Header | 1-RTT | Application data |
+---------------------+-----------------+------------------+ +=====================+-----------------+------------------+
Table 1: Encryption Keys by Packet Type Table 1: Encryption Keys 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 4, the interface from QUIC to TLS consists of four As shown in Figure 4, the interface from QUIC to TLS consists of four
primary functions: primary functions:
o Sending and receiving handshake messages * Sending and receiving handshake messages
o Processing stored transport and application state from a resumed * Processing stored transport and application state from a resumed
session and determining if it is valid to generate or accept early session and determining if it is valid to generate or accept 0-RTT
data data
o Rekeying (both transmit and receive) * Rekeying (both transmit and receive)
o Updating handshake state * Updating handshake state
Additional functions might be needed to configure TLS. In Additional functions might be needed to configure TLS. In
particular, QUIC and TLS need to agree on which is responsible for particular, QUIC and TLS need to agree on which is responsible for
validation of peer credentials, such as certificate validation validation of peer credentials, such as certificate validation
[RFC5280]. [RFC5280].
4.1.1. Handshake Complete 4.1.1. Handshake Complete
In this document, the TLS handshake is considered complete when the In this document, the TLS handshake is considered complete when the
TLS stack has reported that the handshake is complete. This happens TLS stack has reported that the handshake is complete. This happens
skipping to change at page 11, line 26 skipping to change at line 472
QUIC CRYPTO frames only carry TLS handshake messages. TLS alerts are QUIC CRYPTO frames only carry TLS handshake messages. TLS alerts are
turned into QUIC CONNECTION_CLOSE error codes; see Section 4.8. TLS turned into QUIC CONNECTION_CLOSE error codes; see Section 4.8. TLS
application data and other content types cannot be carried by QUIC at application data and other content types cannot be carried by QUIC at
any encryption level; it is an error if they are received from the any encryption level; it is an error if they are received from the
TLS stack. TLS stack.
When an endpoint receives a QUIC packet containing a CRYPTO frame When an endpoint receives a QUIC packet containing a CRYPTO frame
from the network, it proceeds as follows: from the network, it proceeds as follows:
o If the packet uses the current TLS receiving encryption level, * If the packet uses the current TLS receiving encryption level,
sequence the data into the input flow as usual. As with STREAM sequence the data into the input flow as usual. As with STREAM
frames, the offset is used to find the proper location in the data frames, the offset is used to find the proper location in the data
sequence. If the result of this process is that new data is sequence. If the result of this process is that new data is
available, then it is delivered to TLS in order. available, then it is delivered to TLS in order.
o If the packet is from a previously installed encryption level, it * If the packet is from a previously installed encryption level, it
MUST NOT contain data that extends past the end of previously MUST NOT contain data that extends past the end of previously
received data in that flow. Implementations MUST treat any received data in that flow. Implementations MUST treat any
violations of this requirement as a connection error of type violations of this requirement as a connection error of type
PROTOCOL_VIOLATION. PROTOCOL_VIOLATION.
o If the packet is from a new encryption level, it is saved for * If the packet is from a new encryption level, it is saved for
later processing by TLS. Once TLS moves to receiving from this later processing by TLS. Once TLS moves to receiving from this
encryption level, saved data can be provided to TLS. When TLS encryption level, saved data can be provided to TLS. When TLS
provides keys for a higher encryption level, if there is data from provides keys for a higher encryption level, if there is data from
a previous encryption level that TLS has not consumed, this MUST a previous encryption level that TLS has not consumed, this MUST
be treated as a connection error of type PROTOCOL_VIOLATION. be treated as a connection error of type PROTOCOL_VIOLATION.
Each time that TLS is provided with new data, new handshake bytes are Each time that TLS is provided with new data, new handshake bytes are
requested from TLS. TLS might not provide any bytes if the handshake requested from TLS. TLS might not provide any bytes if the handshake
messages it has received are incomplete or it has no data to send. messages it has received are incomplete or it has no data to send.
skipping to change at page 12, line 39 skipping to change at line 534
level are available. level are available.
The availability of new keys is always a result of providing inputs The availability of new keys is always a result of providing inputs
to TLS. TLS only provides new keys after being initialized (by a to TLS. TLS only provides new keys after being initialized (by a
client) or when provided with new handshake data. client) or when provided with new handshake data.
However, a TLS implementation could perform some of its processing However, a TLS implementation could perform some of its processing
asynchronously. In particular, the process of validating a asynchronously. In particular, the process of validating a
certificate can take some time. While waiting for TLS processing to certificate can take some time. While waiting for TLS processing to
complete, an endpoint SHOULD buffer received packets if they might be complete, an endpoint SHOULD buffer received packets if they might be
processed using keys that aren't yet available. These packets can be processed using keys that are not yet available. These packets can
processed once keys are provided by TLS. An endpoint SHOULD continue be processed once keys are provided by TLS. An endpoint SHOULD
to respond to packets that can be processed during this time. continue to respond to packets that can be processed during this
time.
After processing inputs, TLS might produce handshake bytes, keys for After processing inputs, TLS might produce handshake bytes, keys for
new encryption levels, or both. new encryption levels, or both.
TLS provides QUIC with three items as a new encryption level becomes TLS provides QUIC with three items as a new encryption level becomes
available: available:
o A secret * A secret
o An Authenticated Encryption with Associated Data (AEAD) function * An Authenticated Encryption with Associated Data (AEAD) function
o A Key Derivation Function (KDF)
* A Key Derivation Function (KDF)
These values are based on the values that TLS negotiates and are used These values are based on the values that TLS negotiates and are used
by QUIC to generate packet and header protection keys; see Section 5 by QUIC to generate packet and header protection keys; see Section 5
and Section 5.4. and Section 5.4.
If 0-RTT is possible, it is ready after the client sends a TLS If 0-RTT is possible, it is ready after the client sends a TLS
ClientHello message or the server receives that message. After ClientHello message or the server receives that message. After
providing a QUIC client with the first handshake bytes, the TLS stack providing a QUIC client with the first handshake bytes, the TLS stack
might signal the change to 0-RTT keys. On the server, after might signal the change to 0-RTT keys. On the server, after
receiving handshake bytes that contain a ClientHello message, a TLS receiving handshake bytes that contain a ClientHello message, a TLS
skipping to change at page 14, line 40 skipping to change at line 628
1-RTT - - - - - - - -> 1-RTT - - - - - - - ->
Handshake Received Handshake Received
Handshake Complete Handshake Complete
Handshake Confirmed Handshake Confirmed
Install rx 1-RTT keys Install rx 1-RTT keys
<--------------- 1-RTT <--------------- 1-RTT
(HANDSHAKE_DONE) (HANDSHAKE_DONE)
Handshake Confirmed Handshake Confirmed
Figure 5: Interaction Summary between QUIC and TLS Figure 5: Interaction Summary between QUIC and TLS
Figure 5 shows the multiple packets that form a single "flight" of Figure 5 shows the multiple packets that form a single "flight" of
messages being processed individually, to show what incoming messages messages being processed individually, to show what incoming messages
trigger different actions. This shows multiple "Get Handshake" trigger different actions. This shows multiple "Get Handshake"
invocations to retrieve handshake messages at different encryption invocations to retrieve handshake messages at different encryption
levels. New handshake messages are requested after incoming packets levels. New handshake messages are requested after incoming packets
have been processed. have been processed.
Figure 5 shows one possible structure for a simple handshake Figure 5 shows one possible structure for a simple handshake
exchange. The exact process varies based on the structure of exchange. The exact process varies based on the structure of
skipping to change at page 16, line 28 skipping to change at line 711
The requirements for authentication depend on the application The requirements for authentication depend on the application
protocol that is in use. TLS provides server authentication and protocol that is in use. TLS provides server authentication and
permits the server to request client authentication. permits the server to request client authentication.
A client MUST authenticate the identity of the server. This A client MUST authenticate the identity of the server. This
typically involves verification that the identity of the server is typically involves verification that the identity of the server is
included in a certificate and that the certificate is issued by a included in a certificate and that the certificate is issued by a
trusted entity (see for example [RFC2818]). trusted entity (see for example [RFC2818]).
Note: Where servers provide certificates for authentication, the | Note: Where servers provide certificates for authentication,
size of the certificate chain can consume a large number of bytes. | the size of the certificate chain can consume a large number of
Controlling the size of certificate chains is critical to | bytes. Controlling the size of certificate chains is critical
performance in QUIC as servers are limited to sending 3 bytes for | to performance in QUIC as servers are limited to sending 3
every byte received prior to validating the client address; see | bytes for every byte received prior to validating the client
Section 8.1 of [QUIC-TRANSPORT]. The size of a certificate chain | address; see Section 8.1 of [QUIC-TRANSPORT]. The size of a
can be managed by limiting the number of names or extensions; | certificate chain can be managed by limiting the number of
using keys with small public key representations, like ECDSA; or | names or extensions; using keys with small public key
by using certificate compression [COMPRESS]. | representations, like ECDSA; or by using certificate
| compression [COMPRESS].
A server MAY request that the client authenticate during the A server MAY request that the client authenticate during the
handshake. A server MAY refuse a connection if the client is unable handshake. A server MAY refuse a connection if the client is unable
to authenticate when requested. The requirements for client to authenticate when requested. The requirements for client
authentication vary based on application protocol and deployment. authentication vary based on application protocol and deployment.
A server MUST NOT use post-handshake client authentication (as A server MUST NOT use post-handshake client authentication (as
defined in Section 4.6.2 of [TLS13]) because the multiplexing offered defined in Section 4.6.2 of [TLS13]) because the multiplexing offered
by QUIC prevents clients from correlating the certificate request by QUIC prevents clients from correlating the certificate request
with the application-level event that triggered it (see with the application-level event that triggered it (see
skipping to change at page 18, line 15 skipping to change at line 793
[TLS13] sets a limit of seven days on the time between the original [TLS13] sets a limit of seven days on the time between the original
connection and any attempt to use 0-RTT. There are other constraints connection and any attempt to use 0-RTT. There are other constraints
on 0-RTT usage, notably those caused by the potential exposure to on 0-RTT usage, notably those caused by the potential exposure to
replay attack; see Section 9.2. replay attack; see Section 9.2.
4.6.1. Enabling 0-RTT 4.6.1. Enabling 0-RTT
The TLS early_data extension in the NewSessionTicket message is The TLS early_data extension in the NewSessionTicket message is
defined to convey (in the max_early_data_size parameter) the amount defined to convey (in the max_early_data_size parameter) the amount
of TLS 0-RTT data the server is willing to accept. QUIC does not use of TLS 0-RTT data the server is willing to accept. QUIC does not use
TLS 0-RTT data. QUIC uses 0-RTT packets to carry early data. TLS early data. QUIC uses 0-RTT packets to carry early data.
Accordingly, the max_early_data_size parameter is repurposed to hold Accordingly, the max_early_data_size parameter is repurposed to hold
a sentinel value 0xffffffff to indicate that the server is willing to a sentinel value 0xffffffff to indicate that the server is willing to
accept QUIC 0-RTT data. To indicate that the server does not accept accept QUIC 0-RTT data. To indicate that the server does not accept
0-RTT data, the early_data extension is omitted from the 0-RTT data, the early_data extension is omitted from the
NewSessionTicket. The amount of data that the client can send in NewSessionTicket. The amount of data that the client can send in
QUIC 0-RTT is controlled by the initial_max_data transport parameter QUIC 0-RTT is controlled by the initial_max_data transport parameter
supplied by the server. supplied by the server.
Servers MUST NOT send the early_data extension with a Servers MUST NOT send the early_data extension with a
max_early_data_size field set to any value other than 0xffffffff. A max_early_data_size field set to any value other than 0xffffffff. A
skipping to change at page 19, line 17 skipping to change at line 843
application protocol, transport parameters, and any application application protocol, transport parameters, and any application
configuration. The client therefore MUST reset the state of all configuration. The client therefore MUST reset the state of all
streams, including application state bound to those streams. streams, including application state bound to those streams.
A client MAY reattempt 0-RTT if it receives a Retry or Version A client MAY reattempt 0-RTT if it receives a Retry or Version
Negotiation packet. These packets do not signify rejection of 0-RTT. Negotiation packet. These packets do not signify rejection of 0-RTT.
4.6.3. Validating 0-RTT Configuration 4.6.3. Validating 0-RTT Configuration
When a server receives a ClientHello with the early_data extension, When a server receives a ClientHello with the early_data extension,
it has to decide whether to accept or reject early data from the it has to decide whether to accept or reject 0-RTT data from the
client. Some of this decision is made by the TLS stack (e.g., client. Some of this decision is made by the TLS stack (e.g.,
checking that the cipher suite being resumed was included in the checking that the cipher suite being resumed was included in the
ClientHello; see Section 4.2.10 of [TLS13]). Even when the TLS stack ClientHello; see Section 4.2.10 of [TLS13]). Even when the TLS stack
has no reason to reject early data, the QUIC stack or the application has no reason to reject 0-RTT data, the QUIC stack or the application
protocol using QUIC might reject early data because the configuration protocol using QUIC might reject 0-RTT data because the configuration
of the transport or application associated with the resumed session of the transport or application associated with the resumed session
is not compatible with the server's current configuration. is not compatible with the server's current configuration.
QUIC requires additional transport state to be associated with a QUIC requires additional transport state to be associated with a
0-RTT session ticket. One common way to implement this is using 0-RTT session ticket. One common way to implement this is using
stateless session tickets and storing this state in the session stateless session tickets and storing this state in the session
ticket. Application protocols that use QUIC might have similar ticket. Application protocols that use QUIC might have similar
requirements regarding associating or storing state. This associated requirements regarding associating or storing state. This associated
state is used for deciding whether early data must be rejected. For state is used for deciding whether 0-RTT data must be rejected. For
example, HTTP/3 settings [QUIC-HTTP] determine how early data from example, HTTP/3 settings [QUIC-HTTP] determine how 0-RTT data from
the client is interpreted. Other applications using QUIC could have the client is interpreted. Other applications using QUIC could have
different requirements for determining whether to accept or reject different requirements for determining whether to accept or reject
early data. 0-RTT data.
4.7. HelloRetryRequest 4.7. HelloRetryRequest
The HelloRetryRequest message (see Section 4.1.4 of [TLS13]) can be The HelloRetryRequest message (see Section 4.1.4 of [TLS13]) can be
used to request that a client provide new information, such as a key used to request that a client provide new information, such as a key
share, or to validate some characteristic of the client. From the share, or to validate some characteristic of the client. From the
perspective of QUIC, HelloRetryRequest is not differentiated from perspective of QUIC, HelloRetryRequest is not differentiated from
other cryptographic handshake messages that are carried in Initial other cryptographic handshake messages that are carried in Initial
packets. Although it is in principle possible to use this feature packets. Although it is in principle possible to use this feature
for address verification, QUIC implementations SHOULD instead use the for address verification, QUIC implementations SHOULD instead use the
skipping to change at page 22, line 12 skipping to change at line 979
determines that it has received all 0-RTT packets, which can be done determines that it has received all 0-RTT packets, which can be done
by keeping track of missing packet numbers. by keeping track of missing packet numbers.
5. Packet Protection 5. Packet Protection
As with TLS over TCP, QUIC protects packets with keys derived from As with TLS over TCP, QUIC protects packets with keys derived from
the TLS handshake, using the AEAD algorithm [AEAD] negotiated by TLS. the TLS handshake, using the AEAD algorithm [AEAD] negotiated by TLS.
QUIC packets have varying protections depending on their type: QUIC packets have varying protections depending on their type:
o Version Negotiation packets have no cryptographic protection. * Version Negotiation packets have no cryptographic protection.
o Retry packets use AEAD_AES_128_GCM to provide protection against * Retry packets use AEAD_AES_128_GCM to provide protection against
accidental modification and to limit the entities that can produce accidental modification and to limit the entities that can produce
a valid Retry; see Section 5.8. a valid Retry; see Section 5.8.
o Initial packets use AEAD_AES_128_GCM with keys derived from the * Initial packets use AEAD_AES_128_GCM with keys derived from the
Destination Connection ID field of the first Initial packet sent Destination Connection ID field of the first Initial packet sent
by the client; see Section 5.2. by the client; see Section 5.2.
o All other packets have strong cryptographic protections for * All other packets have strong cryptographic protections for
confidentiality and integrity, using keys and algorithms confidentiality and integrity, using keys and algorithms
negotiated by TLS. negotiated by TLS.
This section describes how packet protection is applied to Handshake This section describes how packet protection is applied to Handshake
packets, 0-RTT packets, and 1-RTT packets. The same packet packets, 0-RTT packets, and 1-RTT packets. The same packet
protection process is applied to Initial packets. However, as it is protection process is applied to Initial packets. However, as it is
trivial to determine the keys used for Initial packets, these packets trivial to determine the keys used for Initial packets, these packets
are not considered to have confidentiality or integrity protection. are not considered to have confidentiality or integrity protection.
Retry packets use a fixed key and so similarly lack confidentiality Retry packets use a fixed key and so similarly lack confidentiality
and integrity protection. and integrity protection.
skipping to change at page 22, line 48 skipping to change at line 1015
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 with the hash
function from the negotiated cipher suite. All uses of HKDF-Expand- function from the negotiated cipher suite. All uses of HKDF-Expand-
Label in QUIC use a zero-length Context. Label in QUIC use a zero-length Context.
Note that labels, which are described using strings, are encoded as Note that labels, which are described using strings, are encoded as
bytes using ASCII [ASCII] without quotes or any trailing NUL byte. bytes using ASCII [ASCII] without quotes or any trailing NUL byte.
Other versions of TLS MUST provide a similar function in order to be Other versions of TLS MUST provide a similar function in order to be
used with QUIC. 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
skipping to change at page 24, line 37 skipping to change at line 1094
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.
The secrets used for constructing subsequent Initial packets change The secrets used for constructing subsequent Initial packets change
when a server sends a Retry packet to use the connection ID value when a server sends a Retry packet to use the connection ID value
selected by the server. The secrets do not change when a client selected by the server. The secrets do not change when a client
changes the Destination Connection ID it uses in response to an changes the Destination Connection ID it uses in response to an
Initial packet from the server. Initial packet from the server.
Note: The Destination Connection ID field could be any length up | Note: The Destination Connection ID field could be any length
to 20 bytes, including zero length if the server sends a Retry | up to 20 bytes, including zero length if the server sends a
packet with a zero-length Source Connection ID field. After a | Retry packet with a zero-length Source Connection ID field.
Retry, the Initial keys provide the client no assurance that the | After a Retry, the Initial keys provide the client no assurance
server received its packet, so the client has to rely on the | that the server received its packet, so the client has to rely
exchange that included the Retry packet to validate the server | on the exchange that included the Retry packet to validate the
address; see Section 8.1 of [QUIC-TRANSPORT]. | server address; see Section 8.1 of [QUIC-TRANSPORT].
Appendix A contains sample Initial packets. Appendix A contains sample Initial packets.
5.3. AEAD Usage 5.3. AEAD Usage
The Authenticated Encryption with Associated Data (AEAD) function The Authenticated Encryption with Associated Data (AEAD) function
(see [AEAD]) used for QUIC packet protection is the AEAD that is (see [AEAD]) used for QUIC packet protection is the AEAD that is
negotiated for use with the TLS connection. For example, if TLS is negotiated for use with the TLS connection. For example, if TLS is
using the TLS_AES_128_GCM_SHA256 cipher suite, the AEAD_AES_128_GCM using the TLS_AES_128_GCM_SHA256 cipher suite, the AEAD_AES_128_GCM
function is used. function is used.
skipping to change at page 27, line 18 skipping to change at line 1209
if (packet[0] & 0x80) == 0x80: if (packet[0] & 0x80) == 0x80:
# Long header: 4 bits masked # Long header: 4 bits masked
packet[0] ^= mask[0] & 0x0f packet[0] ^= mask[0] & 0x0f
else: else:
# Short header: 5 bits masked # Short header: 5 bits masked
packet[0] ^= mask[0] & 0x1f packet[0] ^= mask[0] & 0x1f
# pn_offset is the start of the Packet Number field. # pn_offset is the start of the Packet Number field.
packet[pn_offset:pn_offset+pn_length] ^= mask[1:1+pn_length] packet[pn_offset:pn_offset+pn_length] ^= mask[1:1+pn_length]
Figure 6: Header Protection Pseudocode Figure 6: Header Protection Pseudocode
Specific header protection functions are defined based on the Specific header protection functions are defined based on the
selected cipher suite; see Section 5.4.3 and Section 5.4.4. selected cipher suite; see Section 5.4.3 and Section 5.4.4.
Figure 7 shows an example long header packet (Initial) and a short Figure 7 shows an example long header packet (Initial) and a short
header packet (1-RTT). Figure 7 shows the fields in each header that header packet (1-RTT). Figure 7 shows the fields in each header that
are covered by header protection and the portion of the protected are covered by header protection and the portion of the protected
packet payload that is sampled. packet payload that is sampled.
Initial Packet { Initial Packet {
skipping to change at page 32, line 22 skipping to change at line 1422
if it receives an indication that 0-RTT data has been rejected. if it receives an indication that 0-RTT data has been rejected.
A server MUST NOT use 0-RTT keys to protect packets; it uses 1-RTT A server MUST NOT use 0-RTT keys to protect packets; it uses 1-RTT
keys to protect acknowledgments of 0-RTT packets. A client MUST NOT keys to protect acknowledgments of 0-RTT packets. A client MUST NOT
attempt to decrypt 0-RTT packets it receives and instead MUST discard attempt to decrypt 0-RTT packets it receives and instead MUST discard
them. them.
Once a client has installed 1-RTT keys, it MUST NOT send any more Once a client has installed 1-RTT keys, it MUST NOT send any more
0-RTT packets. 0-RTT packets.
Note: 0-RTT data can be acknowledged by the server as it receives | Note: 0-RTT data can be acknowledged by the server as it
it, but any packets containing acknowledgments of 0-RTT data | receives it, but any packets containing acknowledgments of
cannot have packet protection removed by the client until the TLS | 0-RTT data cannot have packet protection removed by the client
handshake is complete. The 1-RTT keys necessary to remove packet | until the TLS handshake is complete. The 1-RTT keys necessary
protection cannot be derived until the client receives all server | to remove packet protection cannot be derived until the client
handshake messages. | receives all server handshake messages.
5.7. Receiving Out-of-Order Protected Packets 5.7. Receiving Out-of-Order Protected Packets
Due to reordering and loss, protected packets might be received by an Due to reordering and loss, protected packets might be received by an
endpoint before the final TLS handshake messages are received. A endpoint before the final TLS handshake messages are received. A
client will be unable to decrypt 1-RTT packets from the server, client will be unable to decrypt 1-RTT packets from the server,
whereas a server will be able to decrypt 1-RTT packets from the whereas a server will be able to decrypt 1-RTT packets from the
client. Endpoints in either role MUST NOT decrypt 1-RTT packets from client. Endpoints in either role MUST NOT decrypt 1-RTT packets from
their peer prior to completing the handshake. their peer prior to completing the handshake.
Even though 1-RTT keys are available to a server after receiving the Even though 1-RTT keys are available to a server after receiving the
first handshake messages from a client, it is missing assurances on first handshake messages from a client, it is missing assurances on
the client state: the client state:
o The client is not authenticated, unless the server has chosen to * The client is not authenticated, unless the server has chosen to
use a pre-shared key and validated the client's pre-shared key use a pre-shared key and validated the client's pre-shared key
binder; see Section 4.2.11 of [TLS13]. binder; see Section 4.2.11 of [TLS13].
o The client has not demonstrated liveness, unless the server has * The client has not demonstrated liveness, unless the server has
validated the client's address with a Retry packet or other means; validated the client's address with a Retry packet or other means;
see Section 8.1 of [QUIC-TRANSPORT]. see Section 8.1 of [QUIC-TRANSPORT].
o Any received 0-RTT data that the server responds to might be due * Any received 0-RTT data that the server responds to might be due
to a replay attack. to a replay attack.
Therefore, the server's use of 1-RTT keys before the handshake is Therefore, the server's use of 1-RTT keys before the handshake is
complete is limited to sending data. A server MUST NOT process complete is limited to sending data. A server MUST NOT process
incoming 1-RTT protected packets before the TLS handshake is incoming 1-RTT protected packets before the TLS handshake is
complete. Because sending acknowledgments indicates that all frames complete. Because sending acknowledgments indicates that all frames
in a packet have been processed, a server cannot send acknowledgments in a packet have been processed, a server cannot send acknowledgments
for 1-RTT packets until the TLS handshake is complete. Received for 1-RTT packets until the TLS handshake is complete. Received
packets protected with 1-RTT keys MAY be stored and later decrypted packets protected with 1-RTT keys MAY be stored and later decrypted
and used once the handshake is complete. and used once the handshake is complete.
Note: TLS implementations might provide all 1-RTT secrets prior to | Note: TLS implementations might provide all 1-RTT secrets prior
handshake completion. Even where QUIC implementations have 1-RTT | to handshake completion. Even where QUIC implementations have
read keys, those keys are not to be used prior to completing the | 1-RTT read keys, those keys are not to be used prior to
handshake. | completing the handshake.
The requirement for the server to wait for the client Finished The requirement for the server to wait for the client Finished
message creates a dependency on that message being delivered. A message creates a dependency on that message being delivered. A
client can avoid the potential for head-of-line blocking that this client can avoid the potential for head-of-line blocking that this
implies by sending its 1-RTT packets coalesced with a Handshake implies by sending its 1-RTT packets coalesced with a Handshake
packet containing a copy of the CRYPTO frame that carries the packet containing a copy of the CRYPTO frame that carries the
Finished message, until one of the Handshake packets is acknowledged. Finished message, until one of the Handshake packets is acknowledged.
This enables immediate server processing for those packets. This enables immediate server processing for those packets.
A server could receive packets protected with 0-RTT keys prior to A server could receive packets protected with 0-RTT keys prior to
skipping to change at page 33, line 47 skipping to change at line 1495
Retry packets (see Section 17.2.5 of [QUIC-TRANSPORT]) carry a Retry Retry packets (see Section 17.2.5 of [QUIC-TRANSPORT]) carry a Retry
Integrity Tag that provides two properties: it allows the discarding Integrity Tag that provides two properties: it allows the discarding
of packets that have accidentally been corrupted by the network, and of packets that have accidentally been corrupted by the network, and
only an entity that observes an Initial packet can send a valid Retry only an entity that observes an Initial packet can send a valid Retry
packet. packet.
The Retry Integrity Tag is a 128-bit field that is computed as the The Retry Integrity Tag is a 128-bit field that is computed as the
output of AEAD_AES_128_GCM [AEAD] used with the following inputs: output of AEAD_AES_128_GCM [AEAD] used with the following inputs:
o The secret key, K, is 128 bits equal to * The secret key, K, is 128 bits equal to
0xbe0c690b9f66575a1d766b54e368c84e. 0xbe0c690b9f66575a1d766b54e368c84e.
o The nonce, N, is 96 bits equal to 0x461599d35d632bf2239825bb. * The nonce, N, is 96 bits equal to 0x461599d35d632bf2239825bb.
o The plaintext, P, is empty. * The plaintext, P, is empty.
o The associated data, A, is the contents of the Retry Pseudo- * The associated data, A, is the contents of the Retry Pseudo-
Packet, as illustrated in Figure 8: Packet, as illustrated in Figure 8:
The secret key and the nonce are values derived by calling HKDF- The secret key and the nonce are values derived by calling HKDF-
Expand-Label using Expand-Label using
0xd9c9943e6101fd200021506bcc02814c73030f25c79d71ce876eca876e6fca8e as 0xd9c9943e6101fd200021506bcc02814c73030f25c79d71ce876eca876e6fca8e as
the secret, with labels being "quic key" and "quic iv" (Section 5.1). the secret, with labels being "quic key" and "quic iv" (Section 5.1).
Retry Pseudo-Packet { Retry Pseudo-Packet {
ODCID Length (8), ODCID Length (8),
Original Destination Connection ID (0..160), Original Destination Connection ID (0..160),
skipping to change at page 35, line 47 skipping to change at line 1592
QUIC Packets [1] @N QUIC Packets [1] @N
containing ACK containing ACK
<-------- <--------
... Key Update Permitted ... Key Update Permitted
@N [1] QUIC Packets @N [1] QUIC Packets
containing ACK for @N packets containing ACK for @N packets
--------> -------->
Key Update Permitted ... Key Update Permitted ...
Figure 9: Key Update Figure 9: Key Update
6.1. Initiating a Key Update 6.1. Initiating a Key Update
Endpoints maintain separate read and write secrets for packet Endpoints maintain separate read and write secrets for packet
protection. An endpoint initiates a key update by updating its protection. An endpoint initiates a key update by updating its
packet protection write secret and using that to protect new packets. packet protection write secret and using that to protect new packets.
The endpoint creates a new write secret from the existing write The endpoint creates a new write secret from the existing write
secret as performed in Section 7.2 of [TLS13]. This uses the KDF secret as performed in Section 7.2 of [TLS13]. This uses the KDF
function provided by TLS with a label of "quic ku". The function provided by TLS with a label of "quic ku". The
corresponding key and IV are created from that secret as defined in corresponding key and IV are created from that secret as defined in
skipping to change at page 36, line 36 skipping to change at line 1625
the handshake (Section 4.1.2). An endpoint MUST NOT initiate a the handshake (Section 4.1.2). An endpoint MUST NOT initiate a
subsequent key update unless it has received an acknowledgment for a subsequent key update unless it has received an acknowledgment for a
packet that was sent protected with keys from the current key phase. packet that was sent protected with keys from the current key phase.
This ensures that keys are available to both peers before another key This ensures that keys are available to both peers before another key
update can be initiated. This can be implemented by tracking the update can be initiated. This can be implemented by tracking the
lowest packet number sent with each key phase and the highest lowest packet number sent with each key phase and the highest
acknowledged packet number in the 1-RTT space: once the latter is acknowledged packet number in the 1-RTT space: once the latter is
higher than or equal to the former, another key update can be higher than or equal to the former, another key update can be
initiated. initiated.
Note: Keys of packets other than the 1-RTT packets are never | Note: Keys of packets other than the 1-RTT packets are never
updated; their keys are derived solely from the TLS handshake | updated; their keys are derived solely from the TLS handshake
state. | state.
The endpoint that initiates a key update also updates the keys that The endpoint that initiates a key update also updates the keys that
it uses for receiving packets. These keys will be needed to process it uses for receiving packets. These keys will be needed to process
packets the peer sends after updating. packets the peer sends after updating.
An endpoint MUST retain old keys until it has successfully An endpoint MUST retain old keys until it has successfully
unprotected a packet sent using the new keys. An endpoint SHOULD unprotected a packet sent using the new keys. An endpoint SHOULD
retain old keys for some time after unprotecting a packet sent using retain old keys for some time after unprotecting a packet sent using
the new keys. Discarding old keys too early can cause delayed the new keys. Discarding old keys too early can cause delayed
packets to be discarded. Discarding packets will be interpreted as packets to be discarded. Discarding packets will be interpreted as
skipping to change at page 46, line 4 skipping to change at line 2071
[NAN] analyzes authenticated encryption algorithms that provide nonce [NAN] analyzes authenticated encryption algorithms that provide nonce
privacy, referred to as "Hide Nonce" (HN) transforms. The general privacy, referred to as "Hide Nonce" (HN) transforms. The general
header protection construction in this document is one of those header protection construction in this document is one of those
algorithms (HN1). Header protection is applied after the packet algorithms (HN1). Header protection is applied after the packet
protection AEAD, sampling a set of bytes ("sample") from the AEAD protection AEAD, sampling a set of bytes ("sample") from the AEAD
output and encrypting the header field using a pseudorandom function output and encrypting the header field using a pseudorandom function
(PRF) as follows: (PRF) as follows:
protected_field = field XOR PRF(hp_key, sample) protected_field = field XOR PRF(hp_key, sample)
The header protection variants in this document use a pseudorandom The header protection variants in this document use a pseudorandom
permutation (PRP) in place of a generic PRF. However, since all PRPs permutation (PRP) in place of a generic PRF. However, since all PRPs
are also PRFs [IMC], these variants do not deviate from the HN1 are also PRFs [IMC], these variants do not deviate from the HN1
construction. construction.
As "hp_key" is distinct from the packet protection key, it follows As "hp_key" is distinct from the packet protection key, it follows
that header protection achieves AE2 security as defined in [NAN] and that header protection achieves AE2 security as defined in [NAN] and
therefore guarantees privacy of "field", the protected packet header. therefore guarantees privacy of "field", the protected packet header.
Future header protection variants based on this construction MUST use Future header protection variants based on this construction MUST use
a PRF to ensure equivalent security guarantees. a PRF to ensure equivalent security guarantees.
Use of the same key and ciphertext sample more than once risks Use of the same key and ciphertext sample more than once risks
compromising header protection. Protecting two different headers compromising header protection. Protecting two different headers
with the same key and ciphertext sample reveals the exclusive OR of with the same key and ciphertext sample reveals the exclusive OR of
the protected fields. Assuming that the AEAD acts as a PRF, if L the protected fields. Assuming that the AEAD acts as a PRF, if L
bits are sampled, the odds of two ciphertext samples being identical bits are sampled, the odds of two ciphertext samples being identical
approach 2^-L/2, that is, the birthday bound. For the algorithms approach 2^(-L/2), that is, the birthday bound. For the algorithms
described in this document, that probability is one in 2^64. described in this document, that probability is one in 2^64.
To prevent an attacker from modifying packet headers, the header is To prevent an attacker from modifying packet headers, the header is
transitively authenticated using packet protection; the entire packet transitively authenticated using packet protection; the entire packet
header is part of the authenticated additional data. Protected header is part of the authenticated additional data. Protected
fields that are falsified or modified can only be detected once the fields that are falsified or modified can only be detected once the
packet protection is removed. packet protection is removed.
9.5. Header Protection Timing Side Channels 9.5. Header Protection Timing Side Channels
skipping to change at page 48, line 8 skipping to change at line 2171
10. IANA Considerations 10. IANA Considerations
IANA has registered a codepoint of 57 (or 0x39) for the IANA has registered a codepoint of 57 (or 0x39) for the
quic_transport_parameters extension (defined in Section 8.2) in the quic_transport_parameters extension (defined in Section 8.2) in the
"TLS ExtensionType Values" registry [TLS-REGISTRIES]. "TLS ExtensionType Values" registry [TLS-REGISTRIES].
The Recommended column for this extension is marked Yes. The TLS 1.3 The Recommended column for this extension is marked Yes. The TLS 1.3
Column includes CH (ClientHello) and EE (EncryptedExtensions). Column includes CH (ClientHello) and EE (EncryptedExtensions).
+-------+---------------------------+-----+-------------+-----------+ +=======+===========================+=====+=============+===========+
| Value | Extension Name | TLS | Recommended | Reference | | Value | Extension Name | TLS | Recommended | Reference |
| | | 1.3 | | | | | | 1.3 | | |
+-------+---------------------------+-----+-------------+-----------+ +=======+===========================+=====+=============+===========+
| 57 | quic_transport_parameters | CH, | Y | This | | 57 | quic_transport_parameters | CH, | Y | This |
| | | EE | | document | | | | EE | | document |
+-------+---------------------------+-----+-------------+-----------+ +-------+---------------------------+-----+-------------+-----------+
Table 2: TLS ExtensionType Values Registry Entry Table 2: TLS ExtensionType Values Registry Entry
11. References 11. References
11.1. Normative References 11.1. Normative References
[AEAD] McGrew, D., "An Interface and Algorithms for Authenticated [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>. <https://www.rfc-editor.org/info/rfc5116>.
[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,
<https://doi.org/10.6028/nist.fips.197>.
[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>.
[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>.
skipping to change at page 49, line 27 skipping to change at line 2235
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[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>.
[SHA] Dang, Q., "Secure Hash Standard", National Institute of [SHA] Dang, Q., "Secure Hash Standard", National Institute of
Standards and Technology report, Standards and Technology report,
DOI 10.6028/nist.fips.180-4, July 2015. DOI 10.6028/nist.fips.180-4, July 2015,
<https://doi.org/10.6028/nist.fips.180-4>.
[TLS-REGISTRIES] [TLS-REGISTRIES]
Salowey, J. and S. Turner, "IANA Registry Updates for TLS Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/info/rfc8447>. <https://www.rfc-editor.org/info/rfc8447>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
11.2. Informative References 11.2. Informative References
[AEBounds] [AEBounds] Luykx, A. and K. Paterson, "Limits on Authenticated
Luykx, A. and K. Paterson, "Limits on Authenticated Encryption Use in TLS", 28 August 2017,
Encryption Use in TLS", August 2017,
<https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>. <https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
[ASCII] Cerf, V., "ASCII format for network interchange", STD 80, [ASCII] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969, RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>. <https://www.rfc-editor.org/info/rfc20>.
[CCM-ANALYSIS] [CCM-ANALYSIS]
Jonsson, J., "On the Security of CTR + CBC-MAC", Jonsson, J., "On the Security of CTR + CBC-MAC", Selected
DOI 10.1007/3-540-36492-7_7, Selected Areas in Areas in Cryptography, SAC 2002, Lecture Notes in Computer
Cryptography, SAC 2002, Lecture Notes in Computer Science, Science, vol 2595, pp. 76-93, DOI 10.1007/3-540-36492-7_7,
vol 2595, pp. 76-93, 2003. 2003, <https://doi.org/10.1007/3-540-36492-7_7>.
[COMPRESS] [COMPRESS] Ghedini, A. and V. Vasiliev, "TLS Certificate
Ghedini, A. and V. Vasiliev, "TLS Certificate
Compression", RFC 8879, DOI 10.17487/RFC8879, December Compression", RFC 8879, DOI 10.17487/RFC8879, December
2020, <https://www.rfc-editor.org/info/rfc8879>. 2020, <https://www.rfc-editor.org/info/rfc8879>.
[GCM-MU] Hoang, V., Tessaro, S., and A. Thiruvengadam, "The Multi- [GCM-MU] Hoang, V., Tessaro, S., and A. Thiruvengadam, "The Multi-
user Security of GCM, Revisited: Tight Bounds for Nonce user Security of GCM, Revisited: Tight Bounds for Nonce
Randomization", DOI 10.1145/3243734.3243816, CCS '18: Randomization", CCS '18: Proceedings of the 2018 ACM
Proceedings of the 2018 ACM SIGSAC Conference on Computer SIGSAC Conference on Computer and Communications Security,
and Communications Security, pp. 1429-1440, 2018. pp. 1429-1440, DOI 10.1145/3243734.3243816, 2018,
<https://doi.org/10.1145/3243734.3243816>.
[HTTP-REPLAY] [HTTP-REPLAY]
Thomson, M., Nottingham, M., and W. Tarreau, "Using Early Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/info/rfc8470>. 2018, <https://www.rfc-editor.org/info/rfc8470>.
[HTTP2-TLS13] [HTTP2-TLS13]
Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740, Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740,
DOI 10.17487/RFC8740, February 2020, DOI 10.17487/RFC8740, February 2020,
<https://www.rfc-editor.org/info/rfc8740>. <https://www.rfc-editor.org/info/rfc8740>.
[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, 6
November 2014. November 2014.
[NAN] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed: [NAN] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed:
AEAD Revisited", DOI 10.1007/978-3-030-26948-7_9, AEAD Revisited", Advances in Cryptology - CRYPTO 2019,
Advances in Cryptology - CRYPTO 2019, Lecture Notes in Lecture Notes in Computer Science, vol 11692, pp. 235-265,
Computer Science, vol 11692, pp. 235-265, 2019. DOI 10.1007/978-3-030-26948-7_9, 2019,
<https://doi.org/10.1007/978-3-030-26948-7_9>.
[QUIC-HTTP] [QUIC-HTTP]
Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
(HTTP/3)", draft-ietf-quic-http-latest (work in progress). (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
quic-http-34, 2 February 2021,
<https://tools.ietf.org/html/draft-ietf-quic-http-34>.
[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>.
[ROBUST] Fischlin, M., Guenther, F., and C. Janson, "Robust [ROBUST] Fischlin, M., Günther, F., and C. Janson, "Robust
Channels: Handling Unreliable Networks in the Record Channels: Handling Unreliable Networks in the Record
Layers of QUIC and DTLS 1.3", May 2020, Layers of QUIC and DTLS 1.3", 16 May 2020,
<https://eprint.iacr.org/2020/718>. <https://eprint.iacr.org/2020/718>.
Appendix A. Sample Packet Protection Appendix A. Sample Packet Protection
This section shows examples of packet protection so that This section shows examples of packet protection so that
implementations can be verified incrementally. Samples of Initial implementations can be verified incrementally. Samples of Initial
packets from both client and server plus a Retry packet are defined. packets from both client and server plus a Retry packet are defined.
These packets use an 8-byte client-chosen Destination Connection ID These packets use an 8-byte client-chosen Destination Connection ID
of 0x8394c8f03e515708. Some intermediate values are included. All of 0x8394c8f03e515708. Some intermediate values are included. All
values are shown in hexadecimal. values are shown in hexadecimal.
skipping to change at page 57, line 13 skipping to change at line 2559
packet = 4cfe4189655e5cd55c41f69080575d7999c25a5bfb packet = 4cfe4189655e5cd55c41f69080575d7999c25a5bfb
Appendix B. AEAD Algorithm Analysis Appendix B. AEAD Algorithm Analysis
This section documents analyses used in deriving AEAD algorithm This section documents analyses used in deriving AEAD algorithm
limits for AEAD_AES_128_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_GCM. limits for AEAD_AES_128_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_GCM.
The analyses that follow use symbols for multiplication (*), division The analyses that follow use symbols for multiplication (*), division
(/), and exponentiation (^), plus parentheses for establishing (/), and exponentiation (^), plus parentheses for establishing
precedence. The following symbols are also used: precedence. The following symbols are also used:
t: The size of the authentication tag in bits. For these ciphers, t t: The size of the authentication tag in bits. For these ciphers, t
is 128. is 128.
n: The size of the block function in bits. For these ciphers, n is n: The size of the block function in bits. For these ciphers, n is
128. 128.
k: The size of the key in bits. This is 128 for AEAD_AES_128_GCM and k: The size of the key in bits. This is 128 for AEAD_AES_128_GCM
AEAD_AES_128_CCM; 256 for AEAD_AES_256_GCM. and AEAD_AES_128_CCM; 256 for AEAD_AES_256_GCM.
l: The number of blocks in each packet (see below). l: The number of blocks in each packet (see below).
q: The number of genuine packets created and protected by endpoints. q: The number of genuine packets created and protected by endpoints.
This value is the bound on the number of packets that can be This value is the bound on the number of packets that can be
protected before updating keys. protected before updating keys.
v: The number of forged packets that endpoints will accept. This v: The number of forged packets that endpoints will accept. This
value is the bound on the number of forged packets that an value is the bound on the number of forged packets that an
endpoint can reject before updating keys. endpoint can reject before updating keys.
o: The amount of offline ideal cipher queries made by an adversary. o: The amount of offline ideal cipher queries made by an adversary.
The analyses that follow rely on a count of the number of block The analyses that follow rely on a count of the number of block
operations involved in producing each message. This analysis is operations involved in producing each message. This analysis is
performed for packets of size up to 2^11 (l = 2^7) and 2^16 (l = performed for packets of size up to 2^11 (l = 2^7) and 2^16 (l =
2^12). A size of 2^11 is expected to be a limit that matches common 2^12). A size of 2^11 is expected to be a limit that matches common
deployment patterns, whereas the 2^16 is the maximum possible size of deployment patterns, whereas the 2^16 is the maximum possible size of
a QUIC packet. Only endpoints that strictly limit packet size can a QUIC packet. Only endpoints that strictly limit packet size can
use the larger confidentiality and integrity limits that are derived use the larger confidentiality and integrity limits that are derived
using the smaller packet size. using the smaller packet size.
For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the message length (l) is For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the message length (l) is
the length of the associated data in blocks plus the length of the the length of the associated data in blocks plus the length of the
plaintext in blocks. plaintext in blocks.
For AEAD_AES_128_CCM, the total number of block cipher operations is For AEAD_AES_128_CCM, the total number of block cipher operations is
the sum of the following: the length of the associated data in the sum of the following: the length of the associated data in
blocks, the length of the ciphertext in blocks, the length of the blocks, the length of the ciphertext in blocks, the length of the
plaintext in blocks, plus 1. In this analysis, this is simplified to plaintext in blocks, plus 1. In this analysis, this is simplified to
a value of twice the length of the packet in blocks (that is, 2l = a value of twice the length of the packet in blocks (that is, "2l =
2^8 for packets that are limited to 2^11 bytes, or 2l = 2^13 2^8" for packets that are limited to 2^11 bytes, or "2l = 2^13"
otherwise). This simplification is based on the packet containing otherwise). This simplification is based on the packet containing
all of the associated data and ciphertext. This results in a one to all of the associated data and ciphertext. This results in a one to
three block overestimation of the number of operations per packet. three block overestimation of the number of operations per packet.
B.1. Analysis of AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage Limits B.1. Analysis of AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage Limits
[GCM-MU] specifies concrete bounds for AEAD_AES_128_GCM and [GCM-MU] specifies concrete bounds for AEAD_AES_128_GCM and
AEAD_AES_256_GCM as used in TLS 1.3 and QUIC. This section documents AEAD_AES_256_GCM as used in TLS 1.3 and QUIC. This section documents
this analysis using several simplifying assumptions: this analysis using several simplifying assumptions:
o The number of ciphertext blocks an attacker uses in forgery * The number of ciphertext blocks an attacker uses in forgery
attempts is bounded by v * l, which is the number of forgery attempts is bounded by v * l, which is the number of forgery
attempts multiplied by the size of each packet (in blocks). attempts multiplied by the size of each packet (in blocks).
o The amount of offline work done by an attacker does not dominate * The amount of offline work done by an attacker does not dominate
other factors in the analysis. other factors in the analysis.
The bounds in [GCM-MU] are tighter and more complete than those used The bounds in [GCM-MU] are tighter and more complete than those used
in [AEBounds], which allows for larger limits than those described in in [AEBounds], which allows for larger limits than those described in
[TLS13]. [TLS13].
B.1.1. Confidentiality Limit B.1.1. Confidentiality Limit
For confidentiality, Theorem (4.3) in [GCM-MU] establishes that, for For confidentiality, Theorem (4.3) in [GCM-MU] establishes that, for
a single user that does not repeat nonces, the dominant term in a single user that does not repeat nonces, the dominant term in
skipping to change at page 60, line 27 skipping to change at line 2719
therefore have both confidentiality and integrity limits of 2^26.5 therefore have both confidentiality and integrity limits of 2^26.5
packets. Endpoints that do not restrict packet size have a limit of packets. Endpoints that do not restrict packet size have a limit of
2^21.5. 2^21.5.
Contributors Contributors
The IETF QUIC Working Group received an enormous amount of support The IETF QUIC Working Group received an enormous amount of support
from many people. The following people provided substantive from many people. The following people provided substantive
contributions to this document: contributions to this document:
o Adam Langley * Adam Langley
* Alessandro Ghedini
o Alessandro Ghedini * Christian Huitema
* Christopher Wood
o Christian Huitema * David Schinazi
* Dragana Damjanovic
o Christopher Wood * Eric Rescorla
* Felix Günther
o David Schinazi * Ian Swett
* Jana Iyengar
o Dragana Damjanovic * 奥 一穂 (Kazuho Oku)
* Marten Seemann
o Eric Rescorla * Martin Duke
o Felix Guenther * Mike Bishop
* Mikkel Fahnøe Jørgensen
o Ian Swett * Nick Banks
* Nick Harper
o Jana Iyengar * Roberto Peon
* Rui Paulo
o Kazuho Oku * Ryan Hamilton
* Victor Vasiliev
o Marten Seemann
o Martin Duke
o Mike Bishop
o Mikkel Fahnoee Joergensen
o Nick Banks
o Nick Harper
o Roberto Peon
o Rui Paulo
o Ryan Hamilton
o Victor Vasiliev
Authors' Addresses Authors' Addresses
Martin Thomson (editor) Martin Thomson (editor)
Mozilla Mozilla
Email: mt@lowentropy.net Email: mt@lowentropy.net
Sean Turner (editor) Sean Turner (editor)
sn3rd sn3rd
 End of changes. 83 change blocks. 
238 lines changed or deleted 227 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/