draft-ietf-quic-tls-28.txt   draft-ietf-quic-tls-29.txt 
QUIC M. Thomson, Ed. QUIC M. Thomson, Ed.
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track S. Turner, Ed. Intended status: Standards Track S. Turner, Ed.
Expires: 21 November 2020 sn3rd Expires: 11 December 2020 sn3rd
20 May 2020 9 June 2020
Using TLS to Secure QUIC Using TLS to Secure QUIC
draft-ietf-quic-tls-28 draft-ietf-quic-tls-29
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 (mailto:quic@ietf.org)), which is mailing list (quic@ietf.org (mailto:quic@ietf.org)), which is
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 21 November 2020. This Internet-Draft will expire on 11 December 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
2.1. TLS Overview . . . . . . . . . . . . . . . . . . . . . . 4 2.1. TLS Overview . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
4. Carrying TLS Messages . . . . . . . . . . . . . . . . . . . . 8 4. Carrying TLS Messages . . . . . . . . . . . . . . . . . . . . 8
4.1. Interface to TLS . . . . . . . . . . . . . . . . . . . . 10 4.1. Interface to TLS . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Handshake Complete . . . . . . . . . . . . . . . . . 10 4.1.1. Handshake Complete . . . . . . . . . . . . . . . . . 10
4.1.2. Handshake Confirmed . . . . . . . . . . . . . . . . . 11 4.1.2. Handshake Confirmed . . . . . . . . . . . . . . . . . 11
4.1.3. Sending and Receiving Handshake Messages . . . . . . 11 4.1.3. Sending and Receiving Handshake Messages . . . . . . 11
4.1.4. Encryption Level Changes . . . . . . . . . . . . . . 13 4.1.4. Encryption Level Changes . . . . . . . . . . . . . . 13
4.1.5. TLS Interface Summary . . . . . . . . . . . . . . . . 14 4.1.5. TLS Interface Summary . . . . . . . . . . . . . . . . 14
4.2. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. ClientHello Size . . . . . . . . . . . . . . . . . . . . 15 4.3. ClientHello Size . . . . . . . . . . . . . . . . . . . . 15
skipping to change at page 3, line 11 skipping to change at page 3, line 11
5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 29 5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 29
5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 29 5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 29
5.8. Retry Packet Integrity . . . . . . . . . . . . . . . . . 30 5.8. Retry Packet Integrity . . . . . . . . . . . . . . . . . 30
6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 32 6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.1. Initiating a Key Update . . . . . . . . . . . . . . . . . 33 6.1. Initiating a Key Update . . . . . . . . . . . . . . . . . 33
6.2. Responding to a Key Update . . . . . . . . . . . . . . . 34 6.2. Responding to a Key Update . . . . . . . . . . . . . . . 34
6.3. Timing of Receive Key Generation . . . . . . . . . . . . 34 6.3. Timing of Receive Key Generation . . . . . . . . . . . . 34
6.4. Sending with Updated Keys . . . . . . . . . . . . . . . . 35 6.4. Sending with Updated Keys . . . . . . . . . . . . . . . . 35
6.5. Receiving with Different Keys . . . . . . . . . . . . . . 35 6.5. Receiving with Different Keys . . . . . . . . . . . . . . 35
6.6. Key Update Frequency . . . . . . . . . . . . . . . . . . 36 6.6. Minimum Key Update Frequency . . . . . . . . . . . . . . 36
6.7. Key Update Error Code . . . . . . . . . . . . . . . . . . 36 6.7. Key Update Error Code . . . . . . . . . . . . . . . . . . 37
7. Security of Initial Messages . . . . . . . . . . . . . . . . 37 7. Security of Initial Messages . . . . . . . . . . . . . . . . 38
8. QUIC-Specific Adjustments to the TLS Handshake . . . . . . . 37 8. QUIC-Specific Adjustments to the TLS Handshake . . . . . . . 38
8.1. Protocol Negotiation . . . . . . . . . . . . . . . . . . 37 8.1. Protocol Negotiation . . . . . . . . . . . . . . . . . . 38
8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 38 8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 39
8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 38 8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 39
8.4. Prohibit TLS Middlebox Compatibility Mode . . . . . . . . 39 8.4. Prohibit TLS Middlebox Compatibility Mode . . . . . . . . 40
9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40
9.1. Session Linkability . . . . . . . . . . . . . . . . . . . 39 9.1. Session Linkability . . . . . . . . . . . . . . . . . . . 40
9.2. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 39 9.2. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 40
9.3. Packet Reflection Attack Mitigation . . . . . . . . . . . 40 9.3. Packet Reflection Attack Mitigation . . . . . . . . . . . 41
9.4. Header Protection Analysis . . . . . . . . . . . . . . . 41 9.4. Header Protection Analysis . . . . . . . . . . . . . . . 42
9.5. Header Protection Timing Side-Channels . . . . . . . . . 42 9.5. Header Protection Timing Side-Channels . . . . . . . . . 43
9.6. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 42 9.6. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 43
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
11.1. Normative References . . . . . . . . . . . . . . . . . . 43 11.1. Normative References . . . . . . . . . . . . . . . . . . 44
11.2. Informative References . . . . . . . . . . . . . . . . . 44 11.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Sample Packet Protection . . . . . . . . . . . . . . 45 Appendix A. Sample Packet Protection . . . . . . . . . . . . . . 46
A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 45 A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 47
A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 46 A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 48
A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 48 A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 49
A.4. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 49 A.4. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 49 A.5. ChaCha20-Poly1305 Short Header Packet . . . . . . . . . . 50
B.1. Since draft-ietf-quic-tls-27 . . . . . . . . . . . . . . 49 Appendix B. Analysis of Limits on AEAD_AES_128_CCM Usage . . . . 52
B.2. Since draft-ietf-quic-tls-26 . . . . . . . . . . . . . . 49 B.1. Confidentiality Limits . . . . . . . . . . . . . . . . . 53
B.3. Since draft-ietf-quic-tls-25 . . . . . . . . . . . . . . 50 B.2. Integrity Limits . . . . . . . . . . . . . . . . . . . . 53
B.4. Since draft-ietf-quic-tls-24 . . . . . . . . . . . . . . 50 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 53
B.5. Since draft-ietf-quic-tls-23 . . . . . . . . . . . . . . 50 C.1. Since draft-ietf-quic-tls-28 . . . . . . . . . . . . . . 53
B.6. Since draft-ietf-quic-tls-22 . . . . . . . . . . . . . . 50 C.2. Since draft-ietf-quic-tls-27 . . . . . . . . . . . . . . 54
B.7. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 50 C.3. Since draft-ietf-quic-tls-26 . . . . . . . . . . . . . . 54
B.8. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 50 C.4. Since draft-ietf-quic-tls-25 . . . . . . . . . . . . . . 54
B.9. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 51 C.5. Since draft-ietf-quic-tls-24 . . . . . . . . . . . . . . 54
B.10. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 51 C.6. Since draft-ietf-quic-tls-23 . . . . . . . . . . . . . . 54
B.11. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 51 C.7. Since draft-ietf-quic-tls-22 . . . . . . . . . . . . . . 54
B.12. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 51 C.8. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 55
B.13. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 51 C.9. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 55
B.14. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 52 C.10. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 55
B.15. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 52 C.11. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 55
B.16. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 52 C.12. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 55
B.17. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 52 C.13. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 56
B.18. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 52 C.14. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 56
B.19. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 52 C.15. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 56
B.20. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 52 C.16. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 56
B.21. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 52 C.17. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 56
B.22. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 53 C.18. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 56
B.23. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 53 C.19. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 56
B.24. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 53 C.20. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 57
B.25. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 53 C.21. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 57
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 54 C.22. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 C.23. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 57
C.24. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 57
C.25. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 57
C.26. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 58
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
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 17, line 17 skipping to change at page 17, line 17
QUIC can use the session resumption feature of TLS 1.3. It does this QUIC can use the session resumption feature of TLS 1.3. It does this
by carrying NewSessionTicket messages in CRYPTO frames after the by carrying NewSessionTicket messages in CRYPTO frames after the
handshake is complete. Session resumption is the basis of 0-RTT, but handshake is complete. Session resumption is the basis of 0-RTT, but
can be used without also enabling 0-RTT. can be used without also enabling 0-RTT.
Endpoints that use session resumption might need to remember some Endpoints that use session resumption might need to remember some
information about the current connection when creating a resumed information about the current connection when creating a resumed
connection. TLS requires that some information be retained; see connection. TLS requires that some information be retained; see
Section 4.6.1 of [TLS13]. QUIC itself does not depend on any state Section 4.6.1 of [TLS13]. QUIC itself does not depend on any state
being retained when resuming a connection, unless 0-RTT is also used; being retained when resuming a connection, unless 0-RTT is also used;
see Section 4.6 and Section 7.3.1 of [QUIC-TRANSPORT]. Application see Section 4.6 and Section 7.4.1 of [QUIC-TRANSPORT]. Application
protocols could depend on state that is retained between resumed protocols could depend on state that is retained between resumed
connections. connections.
Clients can store any state required for resumption along with the Clients can store any state required for resumption along with the
session ticket. Servers can use the session ticket to help carry session ticket. Servers can use the session ticket to help carry
state. state.
Session resumption allows servers to link activity on the original Session resumption allows servers to link activity on the original
connection with the resumed connection, which might be a privacy connection with the resumed connection, which might be a privacy
issue for clients. Clients can choose not to enable resumption to issue for clients. Clients can choose not to enable resumption to
skipping to change at page 22, line 5 skipping to change at page 22, line 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 Initial packet. Destination Connection ID field from the client's Initial packet.
Specifically: Specifically:
initial_salt = 0xc3eef712c72ebb5a11a7d2432bb46365bef9f502 initial_salt = 0xafbfec289993d24c9e9786f19c6111e04390a899
initial_secret = HKDF-Extract(initial_salt, initial_secret = HKDF-Extract(initial_salt,
client_dst_connection_id) client_dst_connection_id)
client_initial_secret = HKDF-Expand-Label(initial_secret, client_initial_secret = HKDF-Expand-Label(initial_secret,
"client in", "", "client in", "",
Hash.length) Hash.length)
server_initial_secret = HKDF-Expand-Label(initial_secret, server_initial_secret = HKDF-Expand-Label(initial_secret,
"server in", "", "server in", "",
Hash.length) Hash.length)
skipping to change at page 26, line 18 skipping to change at page 26, line 18
Long Packet Type (2) = 0, Long Packet Type (2) = 0,
Reserved Bits (2), # Protected Reserved Bits (2), # Protected
Packet Number Length (2), # Protected Packet Number Length (2), # Protected
Version (32), Version (32),
DCID Len (8), DCID Len (8),
Destination Connection ID (0..160), Destination Connection ID (0..160),
SCID Len (8), SCID Len (8),
Source Connection ID (0..160), Source Connection ID (0..160),
Token Length (i), Token Length (i),
Token (..), Token (..),
Length (i),
Packet Number (8..32), # Protected Packet Number (8..32), # Protected
Protected Payload (0..24), # Skipped Part Protected Payload (0..24), # Skipped Part
Protected Payload (128), # Sampled Part Protected Payload (128), # Sampled Part
Protected Payload (..) # Remainder Protected Payload (..) # Remainder
} }
Short Header Packet { Short Header Packet {
Header Form (1) = 0, Header Form (1) = 0,
Fixed Bit (1) = 1, Fixed Bit (1) = 1,
Spin Bit (1), Spin Bit (1),
skipping to change at page 31, line 9 skipping to change at page 31, line 9
Retry packets (see the Retry Packet section of [QUIC-TRANSPORT]) Retry packets (see the Retry Packet section of [QUIC-TRANSPORT])
carry a Retry Integrity Tag that provides two properties: it allows carry a Retry Integrity Tag that provides two properties: it allows
discarding packets that have accidentally been corrupted by the discarding packets that have accidentally been corrupted by the
network, and it diminishes off-path attackers' ability to send valid network, and it diminishes off-path attackers' ability to send valid
Retry packets. Retry packets.
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:
* The secret key, K, is 128 bits equal to * The secret key, K, is 128 bits equal to
0x4d32ecdb2a2133c841e4043df27d4430. 0xccce187ed09a09d05728155a6cb96be1.
* The nonce, N, is 96 bits equal to 0x4d1611d05513a552c587d575. * The nonce, N, is 96 bits equal to 0xe54930f97f2136f0530a8c1c.
* The plaintext, P, is empty. * The plaintext, P, is empty.
* 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
0x656e61e336ae9417f7f0edd8d78d461e2aa7084aba7a14c1e9f726d55709169a as 0x8b0d37eb8535022ebc8d76a207d80df22646ec06dc809642c30a8baa2baaff4c 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),
Header Form (1) = 1, Header Form (1) = 1,
Fixed Bit (1) = 1, Fixed Bit (1) = 1,
Long Packet Type (2) = 3, Long Packet Type (2) = 3,
Type-Specific Bits (4), Type-Specific Bits (4),
Version (32), Version (32),
skipping to change at page 36, line 35 skipping to change at page 36, line 35
able to decrypt packets that initiate a key update during the period able to decrypt packets that initiate a key update during the period
when it retains old keys. Endpoints SHOULD wait three times the PTO when it retains old keys. Endpoints SHOULD wait three times the PTO
before initiating a key update after receiving an acknowledgment that before initiating a key update after receiving an acknowledgment that
confirms that the previous key update was received. Failing to allow confirms that the previous key update was received. Failing to allow
sufficient time could lead to packets being discarded. sufficient time could lead to packets being discarded.
An endpoint SHOULD retain old read keys for no more than three times An endpoint SHOULD retain old read keys for no more than three times
the PTO. After this period, old read keys and their corresponding the PTO. After this period, old read keys and their corresponding
secrets SHOULD be discarded. secrets SHOULD be discarded.
6.6. Key Update Frequency 6.6. Minimum Key Update Frequency
Key updates MUST be initiated before usage limits on packet Key updates MUST be initiated before usage limits on packet
protection keys are exceeded. For the cipher suites mentioned in protection keys are exceeded. For the cipher suites mentioned in
this document, the limits in Section 5.5 of [TLS13] apply. Other this document, the limits in Section 5.5 of [TLS13] apply. [TLS13]
cipher suites MUST define usage limits in order to be used with QUIC. does not specify a limit for AEAD_AES_128_CCM, but the analysis in
Appendix B shows that a limit of 2^23 packets can be used to obtain
the same confidentiality protection as the limits specified in TLS.
The usage limits defined in TLS 1.3 exist for protection against
attacks on confidentiality and apply to successful applications of
AEAD protection. The integrity protections in authenticated
encryption also depend on limiting the number of attempts to forge
packets. TLS achieves this by closing connections after any record
fails an authentication check. In comparison, QUIC ignores any
packet that cannot be authenticated, allowing multiple forgery
attempts.
Endpoints MUST count the number of received packets that fail
authentication for each set of keys. If the number of packets that
fail authentication with the same key exceeds a limit that is
specific to the AEAD in use, the endpoint MUST stop using those keys.
Endpoints MUST initiate a key update before reaching this limit. If
a key update is not possible, the endpoint MUST immediately close the
connection. Applying a limit reduces the probability that an
attacker is able to successfully forge a packet; see [AEBounds] and
[ROBUST].
Note: Due to the way that header protection protects the Key Phase,
packets that are discarded are likely to have an even distribution
of both Key Phase values. This means that packets that fail
authentication will often use the packet protection keys from the
next key phase. It is therefore necessary to also track the
number of packets that fail authentication with the next set of
packet protection keys. To avoid exhaustion of both sets of keys,
it might be necessary to initiate two key updates in succession.
For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305,
the limit on the number of packets that fail authentication is 2^36.
Note that the analysis in [AEBounds] supports a higher limit for the
AEAD_AES_128_GCM and AEAD_AES_256_GCM, but this specification
recommends a lower limit. For AEAD_AES_128_CCM, the limit on the
number of packets that fail authentication is 2^23.5; see Appendix B.
Note: These limits were originally calculated using assumptions
about the limits on TLS record size. The maximum size of a TLS
record is 2^14 bytes. In comparison, QUIC packets can be up to
2^16 bytes. However, it is expected that QUIC packets will
generally be smaller than TLS records. Where packets might be
larger than 2^14 bytes in length, smaller limits might be needed.
Any TLS cipher suite that is specified for use with QUIC MUST define
limits on the use of the associated AEAD function that preserves
margins for confidentiality and integrity. That is, limits MUST be
specified for the number of packets that can be authenticated and for
the number packets that can fail authentication. Providing a
reference to any analysis upon which values are based - and any
assumptions used in that analysis - allows limits to be adapted to
varying usage conditions.
6.7. Key Update Error Code 6.7. Key Update Error Code
The KEY_UPDATE_ERROR error code (0xE) is used to signal errors The KEY_UPDATE_ERROR error code (0xE) is used to signal errors
related to key updates. related to key updates.
7. Security of Initial Messages 7. Security of Initial Messages
Initial packets are not protected with a secret key, so they are Initial packets are not protected with a secret key, so they are
subject to potential tampering by an attacker. QUIC provides subject to potential tampering by an attacker. QUIC provides
skipping to change at page 39, line 25 skipping to change at page 40, line 25
handshake as a workaround for bugs in some middleboxes. The TLS 1.3 handshake as a workaround for bugs in some middleboxes. The TLS 1.3
middlebox compatibility mode involves setting the legacy_session_id middlebox compatibility mode involves setting the legacy_session_id
field to a 32-byte value in the ClientHello and ServerHello, then field to a 32-byte value in the ClientHello and ServerHello, then
sending a change_cipher_spec record. Both field and record carry no sending a change_cipher_spec record. Both field and record carry no
semantic content and are ignored. semantic content and are ignored.
This mode has no use in QUIC as it only applies to middleboxes that This mode has no use in QUIC as it only applies to middleboxes that
interfere with TLS over TCP. QUIC also provides no means to carry a interfere with TLS over TCP. QUIC also provides no means to carry a
change_cipher_spec record. A client MUST NOT request the use of the change_cipher_spec record. A client MUST NOT request the use of the
TLS 1.3 compatibility mode. A server SHOULD treat the receipt of a TLS 1.3 compatibility mode. A server SHOULD treat the receipt of a
TLS ClientHello that with a non-empty legacy_session_id field as a TLS ClientHello with a non-empty legacy_session_id field as a
connection error of type PROTOCOL_VIOLATION. connection error of type PROTOCOL_VIOLATION.
9. Security Considerations 9. Security Considerations
All of the security considerations that apply to TLS also apply to All of the security considerations that apply to TLS also apply to
the use of TLS in QUIC. Reading all of [TLS13] and its appendices is the use of TLS in QUIC. Reading all of [TLS13] and its appendices is
the best way to gain an understanding of the security properties of the best way to gain an understanding of the security properties of
QUIC. QUIC.
This section summarizes some of the more important security aspects This section summarizes some of the more important security aspects
skipping to change at page 44, line 8 skipping to change at page 45, line 8
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>.
[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", Work in Progress, Internet-Draft, and Congestion Control", Work in Progress, Internet-Draft,
draft-ietf-quic-recovery-28, 20 May 2020, draft-ietf-quic-recovery-29, 9 June 2020,
<https://tools.ietf.org/html/draft-ietf-quic-recovery-28>. <https://tools.ietf.org/html/draft-ietf-quic-recovery-29>.
[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", Work in Progress, Multiplexed and Secure Transport", Work in Progress,
Internet-Draft, draft-ietf-quic-transport-28, 20 May 2020, Internet-Draft, draft-ietf-quic-transport-29, 9 June 2020,
<https://tools.ietf.org/html/draft-ietf-quic-transport- <https://tools.ietf.org/html/draft-ietf-quic-transport-
28>. 29>.
[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>.
[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>.
skipping to change at page 44, line 47 skipping to change at page 45, line 47
[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] Luykx, A. and K. Paterson, "Limits on Authenticated [AEBounds] Luykx, A. and K. Paterson, "Limits on Authenticated
Encryption Use in TLS", 8 March 2016, Encryption Use in TLS", 8 March 2016,
<http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>. <http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
[CCM-ANALYSIS]
Jonsson, J., "On the Security of CTR + CBC-MAC",
DOI 10.1007/3-540-36492-7_7, Selected Areas in
Cryptography pp. 76-93, 2003,
<https://doi.org/10.1007/3-540-36492-7_7>.
[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, 6 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, Advances AEAD Revisited", DOI 10.1007/978-3-030-26948-7_9, Advances
in Cryptology - CRYPTO 2019 pp. 235-265, 2019, in Cryptology - CRYPTO 2019 pp. 235-265, 2019,
<https://doi.org/10.1007/978-3-030-26948-7_9>. <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)", Work in Progress, Internet-Draft, draft-ietf- (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
quic-http-28, 20 May 2020, quic-http-29, 9 June 2020,
<https://tools.ietf.org/html/draft-ietf-quic-http-28>. <https://tools.ietf.org/html/draft-ietf-quic-http-29>.
[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., Günther, F., and C. Janson, "Robust
Channels: Handling Unreliable Networks in the Record
Layers of QUIC and DTLS", 21 February 2020,
<https://www.felixguenther.info/docs/
QUIPS2020_RobustChannels.pdf>.
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.
A.1. Keys A.1. Keys
skipping to change at page 46, line 4 skipping to change at page 47, line 18
client in: 00200f746c73313320636c69656e7420696e00 client in: 00200f746c73313320636c69656e7420696e00
server in: 00200f746c7331332073657276657220696e00 server in: 00200f746c7331332073657276657220696e00
quic key: 00100e746c7331332071756963206b657900 quic key: 00100e746c7331332071756963206b657900
quic iv: 000c0d746c733133207175696320697600 quic iv: 000c0d746c733133207175696320697600
quic hp: 00100d746c733133207175696320687000 quic hp: 00100d746c733133207175696320687000
The initial secret is common: The initial secret is common:
initial_secret = HKDF-Extract(initial_salt, cid) initial_secret = HKDF-Extract(initial_salt, cid)
= 524e374c6da8cf8b496f4bcb69678350 = 1e7e7764529715b1e0ddc8e9753c6157
7aafee6198b202b4bc823ebf7514a423 6769605187793ed366f8bbf8c9e986eb
The secrets for protecting client packets are: The secrets for protecting client packets are:
client_initial_secret client_initial_secret
= HKDF-Expand-Label(initial_secret, "client in", _, 32) = HKDF-Expand-Label(initial_secret, "client in", _, 32)
= fda3953aecc040e48b34e27ef87de3a6 = 0088119288f1d866733ceeed15ff9d50
098ecf0e38b7e032c5c57bcbd5975b84 902cf82952eee27e9d4d4918ea371d87
key = HKDF-Expand-Label(client_initial_secret, "quic key", _, 16) key = HKDF-Expand-Label(client_initial_secret, "quic key", _, 16)
= af7fd7efebd21878ff66811248983694 = 175257a31eb09dea9366d8bb79ad80ba
iv = HKDF-Expand-Label(client_initial_secret, "quic iv", _, 12) iv = HKDF-Expand-Label(client_initial_secret, "quic iv", _, 12)
= 8681359410a70bb9c92f0420 = 6b26114b9cba2b63a9e8dd4f
hp = HKDF-Expand-Label(client_initial_secret, "quic hp", _, 16) hp = HKDF-Expand-Label(client_initial_secret, "quic hp", _, 16)
= a980b8b4fb7d9fbc13e814c23164253d = 9ddd12c994c0698b89374a9c077a3077
The secrets for protecting server packets are: The secrets for protecting server packets are:
server_initial_secret server_initial_secret
= HKDF-Expand-Label(initial_secret, "server in", _, 32) = HKDF-Expand-Label(initial_secret, "server in", _, 32)
= 554366b81912ff90be41f17e80222130 = 006f881359244dd9ad1acf85f595bad6
90ab17d8149179bcadf222f29ff2ddd5 7c13f9f5586f5e64e1acae1d9ea8f616
key = HKDF-Expand-Label(server_initial_secret, "quic key", _, 16) key = HKDF-Expand-Label(server_initial_secret, "quic key", _, 16)
= 5d51da9ee897a21b2659ccc7e5bfa577 = 149d0b1662ab871fbe63c49b5e655a5d
iv = HKDF-Expand-Label(server_initial_secret, "quic iv", _, 12) iv = HKDF-Expand-Label(server_initial_secret, "quic iv", _, 12)
= 5e5ae651fd1e8495af13508b = bab2b12a4c76016ace47856d
hp = HKDF-Expand-Label(server_initial_secret, "quic hp", _, 16) hp = HKDF-Expand-Label(server_initial_secret, "quic hp", _, 16)
= a8ed82e6664f865aedf6106943f95fb8 = c0c499a65a60024a18a250974ea01dfa
A.2. Client Initial A.2. Client Initial
The client sends an Initial packet. The unprotected payload of this The client sends an Initial packet. The unprotected payload of this
packet contains the following CRYPTO frame, plus enough PADDING packet contains the following CRYPTO frame, plus enough PADDING
frames to make a 1162 byte payload: frames to make a 1162 byte payload:
060040c4010000c003036660261ff947 cea49cce6cfad687f457cf1b14531ba1 060040c4010000c003036660261ff947 cea49cce6cfad687f457cf1b14531ba1
4131a0e8f309a1d0b9c4000006130113 031302010000910000000b0009000006 4131a0e8f309a1d0b9c4000006130113 031302010000910000000b0009000006
736572766572ff01000100000a001400 12001d00170018001901000101010201 736572766572ff01000100000a001400 12001d00170018001901000101010201
03010400230000003300260024001d00 204cfdfcd178b784bf328cae793b136f 03010400230000003300260024001d00 204cfdfcd178b784bf328cae793b136f
2aedce005ff183d7bb14952072366470 37002b0003020304000d0020001e0403 2aedce005ff183d7bb14952072366470 37002b0003020304000d0020001e0403
05030603020308040805080604010501 060102010402050206020202002d0002 05030603020308040805080604010501 060102010402050206020202002d0002
0101001c00024001 0101001c00024001
The unprotected header includes the connection ID and a 4 byte packet The unprotected header includes the connection ID and a 4 byte packet
number encoding for a packet number of 2: number encoding for a packet number of 2:
c3ff00001c088394c8f03e5157080000449e00000002 c3ff00001d088394c8f03e5157080000449e00000002
Protecting the payload produces output that is sampled for header Protecting the payload produces output that is sampled for header
protection. Because the header uses a 4 byte packet number encoding, protection. Because the header uses a 4 byte packet number encoding,
the first 16 bytes of the protected payload is sampled, then applied the first 16 bytes of the protected payload is sampled, then applied
to the header: to the header:
sample = 535064a4268a0d9d7b1c9d250ae35516 sample = fb66bc5f93032b7ddd89fe0ff15d9c4f
mask = AES-ECB(hp, sample)[0..4] mask = AES-ECB(hp, sample)[0..4]
= 833b343aaa = d64a952459
header[0] ^= mask[0] & 0x0f header[0] ^= mask[0] & 0x0f
= c0 = c5
header[18..21] ^= mask[1..4] header[18..21] ^= mask[1..4]
= 3b343aa8 = 4a95245b
header = c0ff00001c088394c8f03e5157080000449e3b343aa8 header = c5ff00001d088394c8f03e5157080000449e4a95245b
The resulting protected packet is: The resulting protected packet is:
c0ff00001c088394c8f03e5157080000 449e3b343aa8535064a4268a0d9d7b1c c5ff00001d088394c8f03e5157080000 449e4a95245bfb66bc5f93032b7ddd89
9d250ae355162276e9b1e3011ef6bbc0 ab48ad5bcc2681e953857ca62becd752 fe0ff15d9c4f7050fccdb71c1cd80512 d4431643a53aafa1b0b518b44968b18b
4daac473e68d7405fbba4e9ee616c870 38bdbe908c06d9605d9ac49030359eec 8d3e7a4d04c30b3ed9410325b2abb2da fb1c12f8b70479eb8df98abcaf95dd8f
b1d05a14e117db8cede2bb09d0dbbfee 271cb374d8f10abec82d0f59a1dee29f 3d1c78660fbc719f88b23c8aef6771f3 d50e10fdfb4c9d92386d44481b6c52d5
e95638ed8dd41da07487468791b719c5 5c46968eb3b54680037102a28e53dc1d 9e5538d3d3942de9f13a7f8b702dc317 24180da9df22714d01003fc5e3d165c9
12903db0af5821794b41c4a93357fa59 ce69cfe7f6bdfa629eef78616447e1d6 50e630b8540fbd81c9df0ee63f949970 26c4f2e1887a2def79050ac2d86ba318
11c4baf71bf33febcb03137c2c75d253 17d3e13b684370f668411c0f00304b50 e0b3adc4c5aa18bcf63c7cf8e85f5692 49813a2236a7e72269447cd1c755e451
1c8fd422bd9b9ad81d643b20da89ca05 25d24d2b142041cae0af205092e43008 f5e77470eb3de64c8849d29282069802 9cfa18e5d66176fe6e5ba4ed18026f90
0cd8559ea4c5c6e4fa3f66082b7d303e 52ce0162baa958532b0bbc2bc785681f 900a5b4980e2f58e39151d5cd685b109 29636d4f02e7fad2a5a458249f5c0298
cf37485dff6595e01e739c8ac9efba31 b985d5f656cc092432d781db95221724 a6d53acbe41a7fc83fa7cc01973f7a74 d1237a51974e097636b6203997f921d0
87641c4d3ab8ece01e39bc85b1543661 4775a98ba8fa12d46f9b35e2a55eb72d 7bc1940a6f2d0de9f5a11432946159ed 6cc21df65c4ddd1115f86427259a196c
7f85181a366663387ddc20551807e007 673bd7e26bf9b29b5ab10a1ca87cbb7a 7148b25b6478b0dc7766e1c4d1b1f515 9f90eabc61636226244642ee148b464c
d97e99eb66959c2a9bc3cbde4707ff77 20b110fa95354674e395812e47a0ae53 9e619ee50a5e3ddc836227cad938987c 4ea3c1fa7c75bbf88d89e9ada642b2b8
b464dcb2d1f345df360dc227270c7506 76f6724eb479f0d2fbb6124429990457 8fe8107b7ea375b1b64889a4e9e5c38a 1c896ce275a5658d250e2d76e1ed3a34
ac6c9167f40aab739998f38b9eccb24f d47c8410131bf65a52af841275d5b3d1 ce7e3a3f383d0c996d0bed106c2899ca 6fc263ef0455e74bb6ac1640ea7bfedc
880b197df2b5dea3e6de56ebce3ffb6e 9277a82082f8d9677a6767089b671ebd 59f03fee0e1725ea150ff4d69a7660c5 542119c71de270ae7c3ecfd1af2c4ce5
244c214f0bde95c2beb02cd1172d58bd f39dce56ff68eb35ab39b49b4eac7c81 51986949cc34a66b3e216bfe18b347e6 c05fd050f85912db303a8f054ec23e38
5ea60451d6e6ab82119118df02a58684 4a9ffe162ba006d0669ef57668cab38b f44d1c725ab641ae929fecc8e3cefa56 19df4231f5b4c009fa0c0bbc60bc75f7
62f71a2523a084852cd1d079b3658dc2 f3e87949b550bab3e177cfc49ed190df 6d06ef154fc8577077d9d6a1d2bd9bf0 81dc783ece60111bea7da9e5a9748069
f0630e43077c30de8f6ae081537f1e83 da537da980afa668e7b7fb25301cf741 d078b2bef48de04cabe3755b197d52b3 2046949ecaa310274b4aac0d008b1948
524be3c49884b42821f17552fbd1931a 813017b6b6590a41ea18b6ba49cd48a4 c1082cdfe2083e386d4fd84c0ed0666d 3ee26c4515c4fee73433ac703b690a9f
40bd9a3346a7623fb4ba34a3ee571e3c 731f35a7a3cf25b551a680fa68763507 7bf278a77486ace44c489a0c7ac8dfe4 d1a58fb3a730b993ff0f0d61b4d89557
b7fde3aaf023c50b9d22da6876ba337e b5e9dd9ec3daf970242b6c5aab3aa4b2 831eb4c752ffd39c10f6b9f46d8db278 da624fd800e4af85548a294c1518893a
96ad8b9f6832f686ef70fa938b31b4e5 ddd7364442d3ea72e73d668fb0937796 8778c4f6d6d73c93df200960104e062b 388ea97dcf4016bced7f62b4f062cb6c
f462923a81a47e1cee7426ff6d922126 9b5a62ec03d6ec94d12606cb485560ba 04c20693d9a0e3b74ba8fe74cc012378 84f40d765ae56a51688d985cf0ceaef4
b574816009e96504249385bb61a819be 04f62c2066214d8360a2022beb316240 3045ed8c3f0c33bced08537f6882613a cd3b08d665fce9dd8aa73171e2d3771a
b6c7d78bbe56c13082e0ca272661210a bf020bf3b5783f1426436cf9ff418405 61dba2790e491d413d93d987e2745af2 9418e428be34941485c93447520ffe23
93a5d0638d32fc51c5c65ff291a3a7a5 2fd6775e623a4439cc08dd25582febc9 1da2304d6a0fd5d07d08372202369661 59bef3cf904d722324dd852513df39ae
44ef92d8dbd329c91de3e9c9582e41f1 7f3d186f104ad3f90995116c682a2a14 030d8173908da6364786d3c1bfcb19ea 77a63b25f1e7fc661def480c5d00d444
a3b4b1f547c335f0be710fc9fc03e0e5 87b8cda31ce65b969878a4ad4283e6d5 56269ebd84efd8e3a8b2c257eec76060 682848cbf5194bc99e49ee75e4d0d254
b0373f43da86e9e0ffe1ae0fddd35162 55bd74566f36a38703d5f34249ded1f6 bad4bfd74970c30e44b65511d4ad0e6e c7398e08e01307eeeea14e46ccd87cf3
6b3d9b45b9af2ccfefe984e13376b1b2 c6404aa48c8026132343da3f3a33659e 6b285221254d8fc6a6765c524ded0085 dca5bd688ddf722e2c0faf9d0fb2ce7a
c1b3e95080540b28b7f3fcd35fa5d843 b579a84c089121a60d8c1754915c344e 0c3f2cee19ca0ffba461ca8dc5d2c817 8b0762cf67135558494d2a96f1a139f0
eaf45a9bf27dc0c1e784161691220913 13eb0e87555abd706626e557fc36a04f edb42d2af89a9c9122b07acbc29e5e72 2df8615c343702491098478a389c9872
cd191a58829104d6075c5594f627ca50 6bf181daec940f4a4f3af0074eee89da a10b0c9875125e257c7bfdf27eef4060 bd3d00f4c14fd3e3496c38d3c5d1a566
acde6758312622d4fa675b39f728e062 d2bee680d8f41a597c262648bb18bcfc 8c39350effbc2d16ca17be4ce29f02ed 969504dda2a8c6b9ff919e693ee79e09
13c8b3d97b1a77b2ac3af745d61a34cc 4709865bac824a94bb19058015e4e42d 089316e7d1d89ec099db3b2b268725d8 88536a4b8bf9aee8fb43e82a4d919d48
ea5388b911e76d2856d68cf6cf394185 43b1ca70a2d8d3f725ead1391377dcc0
A.3. Server Initial A.3. Server Initial
The server sends the following payload in response, including an ACK The server sends the following payload in response, including an ACK
frame, a CRYPTO frame, and no PADDING frames: frame, a CRYPTO frame, and no PADDING frames:
0d0000000018410a020000560303eefc e7f7b37ba1d1632e96677825ddf73988 0d0000000018410a020000560303eefc e7f7b37ba1d1632e96677825ddf73988
cfc79825df566dc5430b9a045a120013 0100002e00330024001d00209d3c940d cfc79825df566dc5430b9a045a120013 0100002e00330024001d00209d3c940d
89690b84d08a60993c144eca684d1081 287c834d5311bcf32bb9da1a002b0002 89690b84d08a60993c144eca684d1081 287c834d5311bcf32bb9da1a002b0002
0304 0304
skipping to change at page 49, line 4 skipping to change at page 50, line 9
A.3. Server Initial A.3. Server Initial
The server sends the following payload in response, including an ACK The server sends the following payload in response, including an ACK
frame, a CRYPTO frame, and no PADDING frames: frame, a CRYPTO frame, and no PADDING frames:
0d0000000018410a020000560303eefc e7f7b37ba1d1632e96677825ddf73988 0d0000000018410a020000560303eefc e7f7b37ba1d1632e96677825ddf73988
cfc79825df566dc5430b9a045a120013 0100002e00330024001d00209d3c940d cfc79825df566dc5430b9a045a120013 0100002e00330024001d00209d3c940d
89690b84d08a60993c144eca684d1081 287c834d5311bcf32bb9da1a002b0002 89690b84d08a60993c144eca684d1081 287c834d5311bcf32bb9da1a002b0002
0304 0304
The header from the server includes a new connection ID and a 2-byte The header from the server includes a new connection ID and a 2-byte
packet number encoding for a packet number of 1: packet number encoding for a packet number of 1:
c1ff00001c0008f067a5502a4262b50040740001 c1ff00001d0008f067a5502a4262b50040740001
As a result, after protection, the header protection sample is taken As a result, after protection, the header protection sample is taken
starting from the third protected octet: starting from the third protected octet:
sample = 7002596f99ae67abf65a5852f54f58c3 sample = 823a5d3a1207c86ee49132824f046524
mask = 38168a0c25 mask = abaaf34fdc
header = c9ff00001c0008f067a5502a4262b5004074168b header = caff00001d0008f067a5502a4262b5004074aaf2
The final protected packet is then: The final protected packet is then:
c9ff00001c0008f067a5502a4262b500 4074168bf22b7002596f99ae67abf65a caff00001d0008f067a5502a4262b500 4074aaf2f007823a5d3a1207c86ee491
5852f54f58c37c808682e2e40492d8a3 899fb04fc0afe9aabc8767b18a0aa493 32824f0465243d082d868b107a38092b c80528664cbf9456ebf27673fb5fa506
537426373b48d502214dd856d63b78ce e37bc664b3fe86d487ac7a77c53038a3 1ab573c9f001b81da028a00d52ab00b1 5bebaa70640e106cf2acd043e9c6b441
cd32f0b5004d9f5754c4f7f2d1f35cf3 f7116351c92bda5b23c81034ab74f54c 1c0a79637134d8993701fe779e58c2fe 753d14b0564021565ea92e57bc6faf56
b1bd72951256 dfc7a40870e6
A.4. Retry A.4. Retry
This shows a Retry packet that might be sent in response to the This shows a Retry packet that might be sent in response to the
Initial packet in Appendix A.2. The integrity check includes the Initial packet in Appendix A.2. The integrity check includes the
client-chosen connection ID value of 0x8394c8f03e515708, but that client-chosen connection ID value of 0x8394c8f03e515708, but that
value is not included in the final Retry packet: value is not included in the final Retry packet:
ffff00001c0008f067a5502a4262b574 6f6b656ef71a5f12afe3ecf8001a920e ffff00001d0008f067a5502a4262b574 6f6b656ed16926d81f6f9ca2953a8aa4
6fdf1d63 575e1e49
Appendix B. Change Log A.5. ChaCha20-Poly1305 Short Header Packet
This example shows some of the steps required to protect a packet
with a short header. This example uses AEAD_CHACHA20_POLY1305.
In this example, TLS produces an application write secret from which
a server uses HKDF-Expand-Label to produce four values: a key, an IV,
a header protection key, and the secret that will be used after keys
are updated (this last value is not used further in this example).
secret
= 9ac312a7f877468ebe69422748ad00a1
5443f18203a07d6060f688f30f21632b
key = HKDF-Expand-Label(secret, "quic key", _, 32)
= c6d98ff3441c3fe1b2182094f69caa2e
d4b716b65488960a7a984979fb23e1c8
iv = HKDF-Expand-Label(secret, "quic iv", _, 12)
= e0459b3474bdd0e44a41c144
hp = HKDF-Expand-Label(secret, "quic hp", _, 32)
= 25a282b9e82f06f21f488917a4fc8f1b
73573685608597d0efcb076b0ab7a7a4
ku = HKDF-Expand-Label(secret, "quic ku", _, 32)
= 1223504755036d556342ee9361d25342
1a826c9ecdf3c7148684b36b714881f9
The following shows the steps involved in protecting a minimal packet
with an empty Destination Connection ID. This packet contains a
single PING frame (that is, a payload of just 0x01) and has a packet
number of 654360564. In this example, using a packet number of
length 3 (that is, 49140 is encoded) avoids having to pad the payload
of the packet; PADDING frames would be needed if the packet number is
encoded on fewer octets.
pn = 654360564 (decimal)
nonce = e0459b3474bdd0e46d417eb0
unprotected header = 4200bff4
payload plaintext = 01
payload ciphertext = 655e5cd55c41f69080575d7999c25a5bfb
The resulting ciphertext is the minimum size possible. One byte is
skipped to produce the sample for header protection.
sample = 5e5cd55c41f69080575d7999c25a5bfb
mask = aefefe7d03
header = 4cfe4189
The protected packet is the smallest possible packet size of 21
bytes.
packet = 4cfe4189655e5cd55c41f69080575d7999c25a5bfb
Appendix B. Analysis of Limits on AEAD_AES_128_CCM Usage
TLS [TLS13] and [AEBounds] do not specify limits on usage for
AEAD_AES_128_CCM. However, any AEAD that is used with QUIC requires
limits on use that ensure that both confidentiality and integrity are
preserved. This section documents that analysis.
[CCM-ANALYSIS] is used as the basis of this analysis. The results of
that analysis are used to derive usage limits that are based on those
chosen in [TLS13].
This analysis uses symbols for multiplication (*), division (/), and
exponentiation (^), plus parentheses for establishing precedence.
The following symbols are also used:
t: The size of the authentication tag in bits. For this cipher, t
is 128.
n: The size of the block function in bits. For this cipher, n is
128.
l: The number of blocks in each packet (see below).
q: The number of genuine packets created and protected by endpoints.
This value is the bound on the number of packets that can be
protected before updating keys.
v: The number of forged packets that endpoints will accept. This
value is the bound on the number of forged packets that an
endpoint can reject before updating keys.
The analysis of AEAD_AES_128_CCM relies on a count of the number of
block operations involved in producing each message. For simplicity,
and to match the analysis of other AEAD functions in [AEBounds], this
analysis assumes a packet length of 2^10 blocks and a packet size
limit of 2^14.
For AEAD_AES_128_CCM, the total number of block cipher operations is
the sum of: the length of the associated data in blocks, the length
of the ciphertext in blocks, the length of the 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 = 2^11"). This
simplification is based on the packet containing all of the
associated data and ciphertext. This results in a negligible 1 to 3
block overestimation of the number of operations.
B.1. Confidentiality Limits
For confidentiality, Theorem 2 in [CCM-ANALYSIS] establishes that an
attacker gains a distinguishing advantage over an ideal pseudorandom
permutation (PRP) of no more than:
(2l * q)^2 / 2^n
For a target advantage of 2^-60, which matches that used by [TLS13],
this results in the relation:
q <= 2^23
That is, endpoints cannot protect more than 2^23 packets with the
same set of keys without causing an attacker to gain an larger
advantage than the target of 2^-60.
B.2. Integrity Limits
For integrity, Theorem 1 in [CCM-ANALYSIS] establishes that an
attacker gains an advantage over an ideal PRP of no more than:
v / 2^t + (2l * (v + q))^2 / 2^n
The goal is to limit this advantage to 2^-57, to match the target in
[TLS13]. As "t" and "n" are both 128, the first term is negligible
relative to the second, so that term can be removed without a
significant effect on the result. This produces the relation:
v + q <= 2^24.5
Using the previously-established value of 2^23 for "q" and rounding,
this leads to an upper limit on "v" of 2^23.5. That is, endpoints
cannot attempt to authenticate more than 2^23.5 packets with the same
set of keys without causing an attacker to gain an larger advantage
than the target of 2^-57.
Appendix C. 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-27 C.1. Since draft-ietf-quic-tls-28
* Defined limits on the number of packets that can be protected with
a single key and limits on the number of packets that can fail
authentication (#3619, #3620)
C.2. Since draft-ietf-quic-tls-27
* Allowed CONNECTION_CLOSE in any packet number space, with * Allowed CONNECTION_CLOSE in any packet number space, with
restrictions on use of the application-specific variant (#3430, restrictions on use of the application-specific variant (#3430,
#3435, #3440) #3435, #3440)
* Prohibit the use of the compatibility mode from TLS 1.3 (#3594, * Prohibit the use of the compatibility mode from TLS 1.3 (#3594,
#3595) #3595)
B.2. Since draft-ietf-quic-tls-26 C.3. Since draft-ietf-quic-tls-26
* No changes * No changes
B.3. Since draft-ietf-quic-tls-25 C.4. Since draft-ietf-quic-tls-25
* No changes * No changes
B.4. Since draft-ietf-quic-tls-24 C.5. Since draft-ietf-quic-tls-24
* Rewrite key updates (#3050) * Rewrite key updates (#3050)
- Allow but don't recommend deferring key updates (#2792, #3263) - Allow but don't recommend deferring key updates (#2792, #3263)
- More completely define received behavior (#2791) - More completely define received behavior (#2791)
- Define the label used with HKDF-Expand-Label (#3054) - Define the label used with HKDF-Expand-Label (#3054)
B.5. Since draft-ietf-quic-tls-23 C.6. Since draft-ietf-quic-tls-23
* Key update text update (#3050): * Key update text update (#3050):
- Recommend constant-time key replacement (#2792) - Recommend constant-time key replacement (#2792)
- Provide explicit labels for key update key derivation (#3054) - Provide explicit labels for key update key derivation (#3054)
* Allow first Initial from a client to span multiple packets (#2928, * Allow first Initial from a client to span multiple packets (#2928,
#3045) #3045)
* PING can be sent at any encryption level (#3034, #3035) * PING can be sent at any encryption level (#3034, #3035)
B.6. Since draft-ietf-quic-tls-22 C.7. Since draft-ietf-quic-tls-22
* Update the salt used for Initial secrets (#2887, #2980) * Update the salt used for Initial secrets (#2887, #2980)
B.7. Since draft-ietf-quic-tls-21 C.8. Since draft-ietf-quic-tls-21
* No changes * No changes
B.8. Since draft-ietf-quic-tls-20 C.9. Since draft-ietf-quic-tls-20
* Mandate the use of the QUIC transport parameters extension (#2528, * Mandate the use of the QUIC transport parameters extension (#2528,
#2560) #2560)
* Define handshake completion and confirmation; define clearer rules * Define handshake completion and confirmation; define clearer rules
when it encryption keys should be discarded (#2214, #2267, #2673) when it encryption keys should be discarded (#2214, #2267, #2673)
B.9. Since draft-ietf-quic-tls-18 C.10. Since draft-ietf-quic-tls-18
* Increased the set of permissible frames in 0-RTT (#2344, #2355) * Increased the set of permissible frames in 0-RTT (#2344, #2355)
* Transport parameter extension is mandatory (#2528, #2560) * Transport parameter extension is mandatory (#2528, #2560)
B.10. Since draft-ietf-quic-tls-17 C.11. Since draft-ietf-quic-tls-17
* Endpoints discard initial keys as soon as handshake keys are * Endpoints discard initial keys as soon as handshake keys are
available (#1951, #2045) available (#1951, #2045)
* Use of ALPN or equivalent is mandatory (#2263, #2284) * Use of ALPN or equivalent is mandatory (#2263, #2284)
B.11. Since draft-ietf-quic-tls-14 C.12. Since draft-ietf-quic-tls-14
* Update the salt used for Initial secrets (#1970) * Update the salt used for Initial secrets (#1970)
* Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019) * Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019)
* Change header protection * 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,
skipping to change at page 51, line 41 skipping to change at page 56, line 5
* TLS provides an AEAD and KDF function (#2046) * 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)
* Initial keys are discarded once Handshake keys are available * Initial keys are discarded once Handshake keys are available
(#1951, #2045) (#1951, #2045)
B.12. Since draft-ietf-quic-tls-13 C.13. Since draft-ietf-quic-tls-13
* Updated to TLS 1.3 final (#1660) * Updated to TLS 1.3 final (#1660)
B.13. Since draft-ietf-quic-tls-12 C.14. Since draft-ietf-quic-tls-12
* Changes to integration of the TLS handshake (#829, #1018, #1094, * 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)
* Changed codepoint of TLS extension (#1395, #1402) * Changed codepoint of TLS extension (#1395, #1402)
B.14. Since draft-ietf-quic-tls-11 C.15. Since draft-ietf-quic-tls-11
* Encrypted packet numbers. * Encrypted packet numbers.
B.15. Since draft-ietf-quic-tls-10 C.16. Since draft-ietf-quic-tls-10
* No significant changes. * No significant changes.
B.16. Since draft-ietf-quic-tls-09 C.17. Since draft-ietf-quic-tls-09
* Cleaned up key schedule and updated the salt used for handshake * Cleaned up key schedule and updated the salt used for handshake
packet protection (#1077) packet protection (#1077)
B.17. Since draft-ietf-quic-tls-08 C.18. Since draft-ietf-quic-tls-08
* Specify value for max_early_data_size to enable 0-RTT (#942) * Specify value for max_early_data_size to enable 0-RTT (#942)
* Update key derivation function (#1003, #1004) * Update key derivation function (#1003, #1004)
B.18. Since draft-ietf-quic-tls-07 C.19. Since draft-ietf-quic-tls-07
* Handshake errors can be reported with CONNECTION_CLOSE (#608, * Handshake errors can be reported with CONNECTION_CLOSE (#608,
#891) #891)
B.19. Since draft-ietf-quic-tls-05 C.20. Since draft-ietf-quic-tls-05
No significant changes. No significant changes.
B.20. Since draft-ietf-quic-tls-04 C.21. Since draft-ietf-quic-tls-04
* Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) * Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
B.21. Since draft-ietf-quic-tls-03 C.22. Since draft-ietf-quic-tls-03
No significant changes. No significant changes.
B.22. Since draft-ietf-quic-tls-02 C.23. Since draft-ietf-quic-tls-02
* Updates to match changes in transport draft * Updates to match changes in transport draft
B.23. Since draft-ietf-quic-tls-01 C.24. Since draft-ietf-quic-tls-01
* Use TLS alerts to signal TLS errors (#272, #374) * Use TLS alerts to signal TLS errors (#272, #374)
* Require ClientHello to fit in a single packet (#338) * Require ClientHello to fit in a single packet (#338)
* The second client handshake flight is now sent in the clear (#262, * The second client handshake flight is now sent in the clear (#262,
#337) #337)
* The QUIC header is included as AEAD Associated Data (#226, #243, * The QUIC header is included as AEAD Associated Data (#226, #243,
#302) #302)
skipping to change at page 53, line 34 skipping to change at page 57, line 46
* Require at least TLS 1.3 (#138) * Require at least TLS 1.3 (#138)
* Define transport parameters as a TLS extension (#122) * Define transport parameters as a TLS extension (#122)
* Define handling for protected packets before the handshake * Define handling for protected packets before the handshake
completes (#39) completes (#39)
* Decouple QUIC version and ALPN (#12) * Decouple QUIC version and ALPN (#12)
B.24. Since draft-ietf-quic-tls-00 C.25. Since draft-ietf-quic-tls-00
* Changed bit used to signal key phase * Changed bit used to signal key phase
* Updated key phase markings during the handshake * Updated key phase markings during the handshake
* Added TLS interface requirements section * Added TLS interface requirements section
* Moved to use of TLS exporters for key derivation * Moved to use of TLS exporters for key derivation
* Moved TLS error code definitions into this document * Moved TLS error code definitions into this document
B.25. Since draft-thomson-quic-tls-01 C.26. Since draft-thomson-quic-tls-01
* Adopted as base for draft-ietf-quic-tls * Adopted as base for draft-ietf-quic-tls
* Updated authors/editors list * Updated authors/editors list
* Added status note * Added status note
Contributors Contributors
The IETF QUIC Working Group received an enormous amount of support The IETF QUIC Working Group received an enormous amount of support
skipping to change at page 54, line 25 skipping to change at page 58, line 36
* Christian Huitema * Christian Huitema
* Christopher Wood * Christopher Wood
* David Schinazi * David Schinazi
* Dragana Damjanovic * Dragana Damjanovic
* Eric Rescorla * Eric Rescorla
* Felix Guenther
* Ian Swett * Ian Swett
* Jana Iyengar * Jana Iyengar
* 奥 一穂 (Kazuho Oku) * 奥 一穂 (Kazuho Oku)
* Marten Seemann * Marten Seemann
* Martin Duke * Martin Duke
 End of changes. 70 change blocks. 
167 lines changed or deleted 385 lines changed or added

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