idnits 2.17.1 draft-ietf-quic-tls-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 22, 2018) is 2165 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1880 -- Looks like a reference, but probably isn't: '2' on line 1882 -- Looks like a reference, but probably isn't: '3' on line 1884 == Unused Reference: 'QUIC-HTTP' is defined on line 1853, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' ** Obsolete normative reference: RFC 7539 (ref. 'CHACHA') (Obsoleted by RFC 8439) ** Downref: Normative reference to an Informational RFC: RFC 5869 (ref. 'HKDF') == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-12 -- Duplicate reference: RFC5116, mentioned in 'RFC5116', was also mentioned in 'AEAD'. -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' == Outdated reference: A later version (-05) exists of draft-ietf-tls-iana-registry-updates-04 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-21 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-12 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-11 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC M. Thomson, Ed. 3 Internet-Draft Mozilla 4 Intended status: Standards Track S. Turner, Ed. 5 Expires: November 23, 2018 sn3rd 6 May 22, 2018 8 Using Transport Layer Security (TLS) to Secure QUIC 9 draft-ietf-quic-tls-12 11 Abstract 13 This document describes how Transport Layer Security (TLS) is used to 14 secure QUIC. 16 Note to Readers 18 Discussion of this draft takes place on the QUIC working group 19 mailing list (quic@ietf.org), which is archived at 20 https://mailarchive.ietf.org/arch/search/?email_list=quic [1]. 22 Working Group information can be found at https://github.com/quicwg 23 [2]; source code and issues list for this draft can be found at 24 https://github.com/quicwg/base-drafts/labels/-tls [3]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on November 23, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 62 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. TLS Overview . . . . . . . . . . . . . . . . . . . . . . 5 64 3.2. TLS Handshake . . . . . . . . . . . . . . . . . . . . . . 6 65 4. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. Handshake and Setup Sequence . . . . . . . . . . . . . . 8 67 4.2. Interface to TLS . . . . . . . . . . . . . . . . . . . . 9 68 4.2.1. Handshake Interface . . . . . . . . . . . . . . . . . 10 69 4.2.2. Source Address Validation . . . . . . . . . . . . . . 11 70 4.2.3. Key Ready Events . . . . . . . . . . . . . . . . . . 12 71 4.2.4. Secret Export . . . . . . . . . . . . . . . . . . . . 12 72 4.2.5. TLS Interface Summary . . . . . . . . . . . . . . . . 12 73 4.3. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 13 74 4.4. ClientHello Size . . . . . . . . . . . . . . . . . . . . 13 75 4.5. Peer Authentication . . . . . . . . . . . . . . . . . . . 14 76 4.6. Rejecting 0-RTT . . . . . . . . . . . . . . . . . . . . . 14 77 4.7. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 15 78 5. QUIC Packet Protection . . . . . . . . . . . . . . . . . . . 15 79 5.1. Installing New Keys . . . . . . . . . . . . . . . . . . . 15 80 5.2. Enabling 0-RTT . . . . . . . . . . . . . . . . . . . . . 15 81 5.3. QUIC Key Expansion . . . . . . . . . . . . . . . . . . . 16 82 5.3.1. QHKDF-Expand . . . . . . . . . . . . . . . . . . . . 16 83 5.3.2. Handshake Secrets . . . . . . . . . . . . . . . . . . 17 84 5.3.3. 0-RTT Secret . . . . . . . . . . . . . . . . . . . . 17 85 5.3.4. 1-RTT Secrets . . . . . . . . . . . . . . . . . . . . 18 86 5.3.5. Updating 1-RTT Secrets . . . . . . . . . . . . . . . 18 87 5.3.6. Packet Protection Keys . . . . . . . . . . . . . . . 18 88 5.4. QUIC AEAD Usage . . . . . . . . . . . . . . . . . . . . . 19 89 5.5. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 20 90 5.6. Packet Number Protection . . . . . . . . . . . . . . . . 21 91 5.6.1. AES-Based Packet Number Protection . . . . . . . . . 22 92 5.6.2. ChaCha20-Based Packet Number Protection . . . . . . . 22 93 5.7. Receiving Protected Packets . . . . . . . . . . . . . . . 22 94 6. Key Phases . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 6.1. Packet Protection for the TLS Handshake . . . . . . . . . 23 96 6.1.1. Initial Key Transitions . . . . . . . . . . . . . . . 24 97 6.1.2. Retransmission and Acknowledgment of Unprotected 98 Packets . . . . . . . . . . . . . . . . . . . . . . . 24 99 6.2. Key Update . . . . . . . . . . . . . . . . . . . . . . . 25 100 7. Client Address Validation . . . . . . . . . . . . . . . . . . 27 101 7.1. HelloRetryRequest Address Validation . . . . . . . . . . 27 102 7.1.1. Stateless Address Validation . . . . . . . . . . . . 28 103 7.1.2. Sending HelloRetryRequest . . . . . . . . . . . . . . 28 104 7.2. NewSessionTicket Address Validation . . . . . . . . . . . 29 105 7.3. Address Validation Token Integrity . . . . . . . . . . . 29 106 8. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 29 107 8.1. Unprotected Packets Prior to Handshake Completion . . . . 30 108 8.1.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 31 109 8.1.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 31 110 8.1.3. Updates to Data and Stream Limits . . . . . . . . . . 31 111 8.1.4. Handshake Failures . . . . . . . . . . . . . . . . . 32 112 8.1.5. Address Verification . . . . . . . . . . . . . . . . 32 113 8.1.6. Denial of Service with Unprotected Packets . . . . . 32 114 8.2. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 33 115 8.3. Receiving Out-of-Order Protected Frames . . . . . . . . . 33 116 9. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 34 117 9.1. Protocol and Version Negotiation . . . . . . . . . . . . 34 118 9.2. QUIC Transport Parameters Extension . . . . . . . . . . . 34 119 10. Security Considerations . . . . . . . . . . . . . . . . . . . 35 120 10.1. Packet Reflection Attack Mitigation . . . . . . . . . . 35 121 10.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 35 122 10.3. Packet Number Protection Analysis . . . . . . . . . . . 36 123 11. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 37 124 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 125 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 126 13.1. Normative References . . . . . . . . . . . . . . . . . . 38 127 13.2. Informative References . . . . . . . . . . . . . . . . . 39 128 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 40 129 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 40 130 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 40 131 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 40 132 C.1. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 41 133 C.2. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 41 134 C.3. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 41 135 C.4. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 41 136 C.5. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 41 137 C.6. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 41 138 C.7. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 41 139 C.8. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 41 140 C.9. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 41 141 C.10. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 42 142 C.11. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 42 143 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 145 1. Introduction 147 This document describes how QUIC [QUIC-TRANSPORT] is secured using 148 Transport Layer Security (TLS) version 1.3 [TLS13]. TLS 1.3 provides 149 critical latency improvements for connection establishment over 150 previous versions. Absent packet loss, most new connections can be 151 established and secured within a single round trip; on subsequent 152 connections between the same client and server, the client can often 153 send application data immediately, that is, using a zero round trip 154 setup. 156 This document describes how the standardized TLS 1.3 acts a security 157 component of QUIC. The same design could work for TLS 1.2, though 158 few of the benefits QUIC provides would be realized due to the 159 handshake latency in versions of TLS prior to 1.3. 161 2. Notational Conventions 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 165 "OPTIONAL" in this document are to be interpreted as described in BCP 166 14 [RFC2119] [RFC8174] when, and only when, they appear in all 167 capitals, as shown here. 169 This document uses the terminology established in [QUIC-TRANSPORT]. 171 For brevity, the acronym TLS is used to refer to TLS 1.3. 173 TLS terminology is used when referring to parts of TLS. Though TLS 174 assumes a continuous stream of octets, it divides that stream into 175 _records_. Most relevant to QUIC are the records that contain TLS 176 _handshake messages_, which are discrete messages that are used for 177 key agreement, authentication and parameter negotiation. Ordinarily, 178 TLS records can also contain _application data_, though in the QUIC 179 usage there is no use of TLS application data. 181 3. Protocol Overview 183 QUIC [QUIC-TRANSPORT] assumes responsibility for the confidentiality 184 and integrity protection of packets. For this it uses keys derived 185 from a TLS 1.3 connection [TLS13]; QUIC also relies on TLS 1.3 for 186 authentication and negotiation of parameters that are critical to 187 security and performance. 189 Rather than a strict layering, these two protocols are co-dependent: 190 QUIC uses the TLS handshake; TLS uses the reliability and ordered 191 delivery provided by QUIC streams. 193 This document defines how QUIC interacts with TLS. This includes a 194 description of how TLS is used, how keying material is derived from 195 TLS, and the application of that keying material to protect QUIC 196 packets. Figure 1 shows the basic interactions between TLS and QUIC, 197 with the QUIC packet protection being called out specially. 199 +------------+ +------------+ 200 | |------ Handshake ------>| | 201 | |<-- Validate Address ---| | 202 | |-- OK/Error/Validate -->| | 203 | |<----- Handshake -------| | 204 | QUIC |------ Validate ------->| TLS | 205 | | | | 206 | |<------ 0-RTT OK -------| | 207 | |<------ 1-RTT OK -------| | 208 | |<--- Handshake Done ----| | 209 +------------+ +------------+ 210 | ^ ^ | 211 | Protect | Protected | | 212 v | Packet | | 213 +------------+ / / 214 | QUIC | / / 215 | Packet |-------- Get Secret -------' / 216 | Protection |<-------- Secret -----------' 217 +------------+ 219 Figure 1: QUIC and TLS Interactions 221 The initial state of a QUIC connection has packets exchanged without 222 any form of protection. In this state, QUIC is limited to using 223 stream 0 and associated packets. Stream 0 is reserved for a TLS 224 connection. This is a complete TLS connection as it would appear 225 when layered over TCP; the only difference is that QUIC provides the 226 reliability and ordering that would otherwise be provided by TCP. 228 At certain points during the TLS handshake, keying material is 229 exported from the TLS connection for use by QUIC. This keying 230 material is used to derive packet protection keys. Details on how 231 and when keys are derived and used are included in Section 5. 233 3.1. TLS Overview 235 TLS provides two endpoints with a way to establish a means of 236 communication over an untrusted medium (that is, the Internet) that 237 ensures that messages they exchange cannot be observed, modified, or 238 forged. 240 TLS features can be separated into two basic functions: an 241 authenticated key exchange and record protection. QUIC primarily 242 uses the authenticated key exchange provided by TLS but provides its 243 own packet protection. 245 The TLS authenticated key exchange occurs between two entities: 246 client and server. The client initiates the exchange and the server 247 responds. If the key exchange completes successfully, both client 248 and server will agree on a secret. TLS supports both pre-shared key 249 (PSK) and Diffie-Hellman (DH) key exchanges. PSK is the basis for 250 0-RTT; the latter provides perfect forward secrecy (PFS) when the DH 251 keys are destroyed. 253 After completing the TLS handshake, the client will have learned and 254 authenticated an identity for the server and the server is optionally 255 able to learn and authenticate an identity for the client. TLS 256 supports X.509 [RFC5280] certificate-based authentication for both 257 server and client. 259 The TLS key exchange is resistent to tampering by attackers and it 260 produces shared secrets that cannot be controlled by either 261 participating peer. 263 3.2. TLS Handshake 265 TLS 1.3 provides two basic handshake modes of interest to QUIC: 267 o A full 1-RTT handshake in which the client is able to send 268 application data after one round trip and the server immediately 269 responds after receiving the first handshake message from the 270 client. 272 o A 0-RTT handshake in which the client uses information it has 273 previously learned about the server to send application data 274 immediately. This application data can be replayed by an attacker 275 so it MUST NOT carry a self-contained trigger for any non- 276 idempotent action. 278 A simplified TLS 1.3 handshake with 0-RTT application data is shown 279 in Figure 2, see [TLS13] for more options and details. 281 Client Server 283 ClientHello 284 (0-RTT Application Data) --------> 285 ServerHello 286 {EncryptedExtensions} 287 {Finished} 288 <-------- [Application Data] 289 (EndOfEarlyData) 290 {Finished} --------> 292 [Application Data] <-------> [Application Data] 294 Figure 2: TLS Handshake with 0-RTT 296 This 0-RTT handshake is only possible if the client and server have 297 previously communicated. In the 1-RTT handshake, the client is 298 unable to send protected application data until it has received all 299 of the handshake messages sent by the server. 301 Two additional variations on this basic handshake exchange are 302 relevant to this document: 304 o The server can respond to a ClientHello with a HelloRetryRequest, 305 which adds an additional round trip prior to the basic exchange. 306 This is needed if the server wishes to request a different key 307 exchange key from the client. HelloRetryRequest is also used to 308 verify that the client is correctly able to receive packets on the 309 address it claims to have (see [QUIC-TRANSPORT]). 311 o A pre-shared key mode can be used for subsequent handshakes to 312 reduce the number of public key operations. This is the basis for 313 0-RTT data, even if the remainder of the connection is protected 314 by a new Diffie-Hellman exchange. 316 4. TLS Usage 318 QUIC reserves stream 0 for a TLS connection. Stream 0 contains a 319 complete TLS connection, which includes the TLS record layer. Other 320 than the definition of a QUIC-specific extension (see Section 9.2), 321 TLS is unmodified for this use. This means that TLS will apply 322 confidentiality and integrity protection to its records. In 323 particular, TLS record protection is what provides confidentiality 324 protection for the TLS handshake messages sent by the server. 326 QUIC permits a client to send frames on streams starting from the 327 first packet. The initial packet from a client contains a stream 328 frame for stream 0 that contains the first TLS handshake messages 329 from the client. This allows the TLS handshake to start with the 330 first packet that a client sends. 332 QUIC packets are protected using a scheme that is specific to QUIC, 333 see Section 5. Keys are exported from the TLS connection when they 334 become available using a TLS exporter (see Section 7.5 of [TLS13] and 335 Section 5.3). After keys are exported from TLS, QUIC manages its own 336 key schedule. 338 4.1. Handshake and Setup Sequence 340 The integration of QUIC with a TLS handshake is shown in more detail 341 in Figure 3. QUIC "STREAM" frames on stream 0 carry the TLS 342 handshake. QUIC performs loss recovery [QUIC-RECOVERY] for this 343 stream and ensures that TLS handshake messages are delivered in the 344 correct order. 346 Client Server 348 @H QUIC STREAM Frame(s) <0>: 349 ClientHello 350 + QUIC Extension 351 --------> 352 0-RTT Key => @0 354 @0 QUIC STREAM Frame(s) : 355 Replayable QUIC Frames 356 --------> 358 QUIC STREAM Frame <0>: @H 359 ServerHello 360 {TLS Handshake Messages} 361 <-------- 362 1-RTT Key => @1 364 QUIC Frames @1 365 <-------- 366 @H QUIC STREAM Frame(s) <0>: 367 (EndOfEarlyData) 368 {Finished} 369 --------> 371 @1 QUIC Frames <-------> QUIC Frames @1 373 Figure 3: QUIC over TLS Handshake 375 In Figure 3, symbols mean: 377 o "<" and ">" enclose stream numbers. 379 o "@" indicates the keys that are used for protecting the QUIC 380 packet (H = handshake, using keys from the well-known cleartext 381 packet secret; 0 = 0-RTT keys; 1 = 1-RTT keys). 383 o "(" and ")" enclose messages that are protected with TLS 0-RTT 384 handshake or application keys. 386 o "{" and "}" enclose messages that are protected by the TLS 387 Handshake keys. 389 If 0-RTT is not attempted, then the client does not send packets 390 protected by the 0-RTT key (@0). In that case, the only key 391 transition on the client is from handshake packets (@H) to 1-RTT 392 protection (@1), which happens after it sends its final set of TLS 393 handshake messages. 395 Note: two different types of packet are used during the handshake by 396 both client and server. The Initial packet carries a TLS ClientHello 397 message; the remainder of the TLS handshake is carried in Handshake 398 packets. The Retry packet carries a TLS HelloRetryRequest, if it is 399 needed, and Handshake packets carry the remainder of the server 400 handshake. 402 The server sends TLS handshake messages without protection (@H). The 403 server transitions from no protection (@H) to full 1-RTT protection 404 (@1) after it sends the last of its handshake messages. 406 Some TLS handshake messages are protected by the TLS handshake record 407 protection. These keys are not exported from the TLS connection for 408 use in QUIC. QUIC packets from the server are sent in the clear 409 until the final transition to 1-RTT keys. 411 The client transitions from handshake (@H) to 0-RTT keys (@0) when 412 sending 0-RTT data, and subsequently to to 1-RTT keys (@1) after its 413 second flight of TLS handshake messages. This creates the potential 414 for unprotected packets to be received by a server in close proximity 415 to packets that are protected with 1-RTT keys. 417 More information on key transitions is included in Section 6.1. 419 4.2. Interface to TLS 421 As shown in Figure 1, the interface from QUIC to TLS consists of four 422 primary functions: Handshake, Source Address Validation, Key Ready 423 Events, and Secret Export. 425 Additional functions might be needed to configure TLS. 427 4.2.1. Handshake Interface 429 In order to drive the handshake, TLS depends on being able to send 430 and receive handshake messages on stream 0. There are two basic 431 functions on this interface: one where QUIC requests handshake 432 messages and one where QUIC provides handshake packets. 434 Before starting the handshake QUIC provides TLS with the transport 435 parameters (see Section 9.2) that it wishes to carry. 437 A QUIC client starts TLS by requesting TLS handshake octets from TLS. 438 The client acquires handshake octets before sending its first packet. 440 A QUIC server starts the process by providing TLS with stream 0 441 octets. 443 Each time that an endpoint receives data on stream 0, it delivers the 444 octets to TLS if it is able. Each time that TLS is provided with new 445 data, new handshake octets are requested from TLS. TLS might not 446 provide any octets if the handshake messages it has received are 447 incomplete or it has no data to send. 449 At the server, when TLS provides handshake octets, it also needs to 450 indicate whether the octets contain a HelloRetryRequest. A 451 HelloRetryRequest MUST always be sent in a Retry packet, so the QUIC 452 server needs to know whether the octets are a HelloRetryRequest. 454 Once the TLS handshake is complete, this is indicated to QUIC along 455 with any final handshake octets that TLS needs to send. TLS also 456 provides QUIC with the transport parameters that the peer advertised 457 during the handshake. 459 Once the handshake is complete, TLS becomes passive. TLS can still 460 receive data from its peer and respond in kind, but it will not need 461 to send more data unless specifically requested - either by an 462 application or QUIC. One reason to send data is that the server 463 might wish to provide additional or updated session tickets to a 464 client. 466 When the handshake is complete, QUIC only needs to provide TLS with 467 any data that arrives on stream 0. In the same way that is done 468 during the handshake, new data is requested from TLS after providing 469 received data. 471 Important: Until the handshake is reported as complete, the 472 connection and key exchange are not properly authenticated at the 473 server. Even though 1-RTT keys are available to a server after 474 receiving the first handshake messages from a client, the server 475 cannot consider the client to be authenticated until it receives 476 and validates the client's Finished message. 478 The requirement for the server to wait for the client Finished 479 message creates a dependency on that message being delivered. A 480 client can avoid the potential for head-of-line blocking that this 481 implies by sending a copy of the STREAM frame that carries the 482 Finished message in multiple packets. This enables immediate 483 server processing for those packets. 485 4.2.2. Source Address Validation 487 During the processing of the TLS ClientHello, TLS requests that the 488 transport make a decision about whether to request source address 489 validation from the client. 491 An initial TLS ClientHello that resumes a session includes an address 492 validation token in the session ticket; this includes all attempts at 493 0-RTT. If the client does not attempt session resumption, no token 494 will be present. While processing the initial ClientHello, TLS 495 provides QUIC with any token that is present. In response, QUIC 496 provides one of three responses: 498 o proceed with the connection, 500 o ask for client address validation, or 502 o abort the connection. 504 If QUIC requests source address validation, it also provides a new 505 address validation token. TLS includes that along with any 506 information it requires in the cookie extension of a TLS 507 HelloRetryRequest message. In the other cases, the connection either 508 proceeds or terminates with a handshake error. 510 The client echoes the cookie extension in a second ClientHello. A 511 ClientHello that contains a valid cookie extension will always be in 512 response to a HelloRetryRequest. If address validation was requested 513 by QUIC, then this will include an address validation token. TLS 514 makes a second address validation request of QUIC, including the 515 value extracted from the cookie extension. In response to this 516 request, QUIC cannot ask for client address validation, it can only 517 abort or permit the connection attempt to proceed. 519 QUIC can provide a new address validation token for use in session 520 resumption at any time after the handshake is complete. Each time a 521 new token is provided TLS generates a NewSessionTicket message, with 522 the token included in the ticket. 524 See Section 7 for more details on client address validation. 526 4.2.3. Key Ready Events 528 TLS provides QUIC with signals when 0-RTT and 1-RTT keys are ready 529 for use. These events are not asynchronous, they always occur 530 immediately after TLS is provided with new handshake octets, or after 531 TLS produces handshake octets. 533 When TLS completed its handshake, 1-RTT keys can be provided to QUIC. 534 On both client and server, this occurs after sending the TLS Finished 535 message. 537 This ordering means that there could be frames that carry TLS 538 handshake messages ready to send at the same time that application 539 data is available. An implementation MUST ensure that TLS handshake 540 messages are always sent in packets protected with handshake keys 541 (see Section 5.3.2). Separate packets are required for data that 542 needs protection from 1-RTT keys. 544 If 0-RTT is possible, it is ready after the client sends a TLS 545 ClientHello message or the server receives that message. After 546 providing a QUIC client with the first handshake octets, the TLS 547 stack might signal that 0-RTT keys are ready. On the server, after 548 receiving handshake octets that contain a ClientHello message, a TLS 549 server might signal that 0-RTT keys are available. 551 1-RTT keys are used for packets in both directions. 0-RTT keys are 552 only used to protect packets sent by the client. 554 4.2.4. Secret Export 556 Details how secrets are exported from TLS are included in 557 Section 5.3. 559 4.2.5. TLS Interface Summary 561 Figure 4 summarizes the exchange between QUIC and TLS for both client 562 and server. 564 Client Server 566 Get Handshake 567 0-RTT Key Ready 568 --- send/receive ---> 569 Handshake Received 570 0-RTT Key Ready 571 Get Handshake 572 1-RTT Keys Ready 573 <--- send/receive --- 574 Handshake Received 575 Get Handshake 576 Handshake Complete 577 1-RTT Keys Ready 578 --- send/receive ---> 579 Handshake Received 580 Get Handshake 581 Handshake Complete 582 <--- send/receive --- 583 Handshake Received 584 Get Handshake 586 Figure 4: Interaction Summary between QUIC and TLS 588 4.3. TLS Version 590 This document describes how TLS 1.3 [TLS13] is used with QUIC. 592 In practice, the TLS handshake will negotiate a version of TLS to 593 use. This could result in a newer version of TLS than 1.3 being 594 negotiated if both endpoints support that version. This is 595 acceptable provided that the features of TLS 1.3 that are used by 596 QUIC are supported by the newer version. 598 A badly configured TLS implementation could negotiate TLS 1.2 or 599 another older version of TLS. An endpoint MUST terminate the 600 connection if a version of TLS older than 1.3 is negotiated. 602 4.4. ClientHello Size 604 QUIC requires that the initial handshake packet from a client fit 605 within the payload of a single packet. The size limits on QUIC 606 packets mean that a record containing a ClientHello needs to fit 607 within 1129 octets, though endpoints can reduce the size of their 608 connection ID to increase by up to 22 octets. 610 A TLS ClientHello can fit within this limit with ample space 611 remaining. However, there are several variables that could cause 612 this limit to be exceeded. Implementations are reminded that large 613 session tickets or HelloRetryRequest cookies, multiple or large key 614 shares, and long lists of supported ciphers, signature algorithms, 615 versions, QUIC transport parameters, and other negotiable parameters 616 and extensions could cause this message to grow. 618 For servers, the size of the session tickets and HelloRetryRequest 619 cookie extension can have an effect on a client's ability to connect. 620 Choosing a small value increases the probability that these values 621 can be successfully used by a client. 623 The TLS implementation does not need to ensure that the ClientHello 624 is sufficiently large. QUIC PADDING frames are added to increase the 625 size of the packet as necessary. 627 4.5. Peer Authentication 629 The requirements for authentication depend on the application 630 protocol that is in use. TLS provides server authentication and 631 permits the server to request client authentication. 633 A client MUST authenticate the identity of the server. This 634 typically involves verification that the identity of the server is 635 included in a certificate and that the certificate is issued by a 636 trusted entity (see for example [RFC2818]). 638 A server MAY request that the client authenticate during the 639 handshake. A server MAY refuse a connection if the client is unable 640 to authenticate when requested. The requirements for client 641 authentication vary based on application protocol and deployment. 643 A server MUST NOT use post-handshake client authentication (see 644 Section 4.6.2 of [TLS13]). 646 4.6. Rejecting 0-RTT 648 A server rejects 0-RTT by rejecting 0-RTT at the TLS layer. This 649 results in early exporter keys being unavailable, thereby preventing 650 the use of 0-RTT for QUIC. 652 A client that attempts 0-RTT MUST also consider 0-RTT to be rejected 653 if it receives a Retry or Version Negotiation packet. 655 When 0-RTT is rejected, all connection characteristics that the 656 client assumed might be incorrect. This includes the choice of 657 application protocol, transport parameters, and any application 658 configuration. The client therefore MUST reset the state of all 659 streams, including application state bound to those streams. 661 4.7. TLS Errors 663 Errors in the TLS connection SHOULD be signaled using TLS alerts on 664 stream 0. A failure in the handshake MUST be treated as a QUIC 665 connection error of type TLS_HANDSHAKE_FAILED. Once the handshake is 666 complete, an error in the TLS connection that causes a TLS alert to 667 be sent or received MUST be treated as a QUIC connection error of 668 type TLS_FATAL_ALERT_GENERATED or TLS_FATAL_ALERT_RECEIVED 669 respectively. 671 5. QUIC Packet Protection 673 QUIC packet protection provides authenticated encryption of packets. 674 This provides confidentiality and integrity protection for the 675 content of packets (see Section 5.4). Packet protection uses keys 676 that are exported from the TLS connection (see Section 5.3). 678 Different keys are used for QUIC packet protection and TLS record 679 protection. TLS handshake messages are protected solely with TLS 680 record protection, but post-handshake messages are redundantly 681 protected with both the QUIC packet protection and the TLS record 682 protection. These messages are limited in number, and so the 683 additional overhead is small. 685 5.1. Installing New Keys 687 As TLS reports the availability of keying material, the packet 688 protection keys and initialization vectors (IVs) are updated (see 689 Section 5.3). The selection of AEAD function is also updated to 690 match the AEAD negotiated by TLS. 692 For packets other than any handshake packets (see Section 6.1), once 693 a change of keys has been made, packets with higher packet numbers 694 MUST be sent with the new keying material. The KEY_PHASE bit on 695 these packets is inverted each time new keys are installed to signal 696 the use of the new keys to the recipient (see Section 6 for details). 698 An endpoint retransmits stream data in a new packet. New packets 699 have new packet numbers and use the latest packet protection keys. 700 This simplifies key management when there are key updates (see 701 Section 6.2). 703 5.2. Enabling 0-RTT 705 In order to be usable for 0-RTT, TLS MUST provide a NewSessionTicket 706 message that contains the "max_early_data" extension with the value 707 0xffffffff; the amount of data which the client can send in 0-RTT is 708 controlled by the "initial_max_data" transport parameter supplied by 709 the server. A client MUST treat receipt of a NewSessionTicket that 710 contains a "max_early_data" extension with any other value as a 711 connection error of type PROTOCOL_VIOLATION. 713 Early data within the TLS connection MUST NOT be used. As it is for 714 other TLS application data, a server MUST treat receiving early data 715 on the TLS connection as a connection error of type 716 PROTOCOL_VIOLATION. 718 5.3. QUIC Key Expansion 720 QUIC uses a system of packet protection secrets, keys and IVs that 721 are modelled on the system used in TLS [TLS13]. The secrets that 722 QUIC uses as the basis of its key schedule are obtained using TLS 723 exporters (see Section 7.5 of [TLS13]). 725 5.3.1. QHKDF-Expand 727 QUIC uses the Hash-based Key Derivation Function (HKDF) [HKDF] with 728 the same hash function negotiated by TLS for key derivation. For 729 example, if TLS is using the TLS_AES_128_GCM_SHA256, the SHA-256 hash 730 function is used. 732 Most key derivations in this document use the QHKDF-Expand function, 733 which uses the HKDF expand function and is modelled on the HKDF- 734 Expand-Label function from TLS 1.3 (see Section 7.1 of [TLS13]). 735 QHKDF-Expand differs from HKDF-Expand-Label in that it uses a 736 different base label and omits the Context argument. 738 QHKDF-Expand(Secret, Label, Length) = 739 HKDF-Expand(Secret, QhkdfExpandInfo, Length) 741 The HKDF-Expand function used by QHKDF-Expand uses the PRF hash 742 function negotiated by TLS, except for handshake secrets and keys 743 derived from them (see Section 5.3.2). 745 Where the "info" parameter of HKDF-Expand is an encoded 746 "QhkdfExpandInfo" structure: 748 struct { 749 uint16 length = Length; 750 opaque label<6..255> = "QUIC " + Label; 751 } QhkdfExpandInfo; 753 For example, assuming a hash function with a 32 octet output, 754 derivation for a client packet protection key would use HKDF-Expand 755 with an "info" parameter of 0x00200851554943206b6579. 757 5.3.2. Handshake Secrets 759 Packets that carry the TLS handshake (Initial, Retry, and Handshake) 760 are protected with a secret derived from the Destination Connection 761 ID field from the client's Initial packet. Specifically: 763 handshake_salt = 0x9c108f98520a5c5c32968e950e8a2c5fe06d6c38 764 handshake_secret = 765 HKDF-Extract(handshake_salt, client_dst_connection_id) 767 client_handshake_secret = 768 QHKDF-Expand(handshake_secret, "client hs", Hash.length) 769 server_handshake_secret = 770 QHKDF-Expand(handshake_secret, "server hs", Hash.length) 772 The hash function for HKDF when deriving handshake secrets and keys 773 is SHA-256 [SHA]. The connection ID used with QHKDF-Expand is the 774 connection ID chosen by the client. 776 The handshake salt is a 20 octet sequence shown in the figure in 777 hexadecimal notation. Future versions of QUIC SHOULD generate a new 778 salt value, thus ensuring that the keys are different for each 779 version of QUIC. This prevents a middlebox that only recognizes one 780 version of QUIC from seeing or modifying the contents of handshake 781 packets from future versions. 783 Note: The Destination Connection ID is of arbitrary length, and it 784 could be zero length if the server sends a Retry packet with a 785 zero-length Source Connection ID field. In this case, the 786 handshake keys provide no assurance to the client that the server 787 received its packet; the client has to rely on the exchange that 788 included the Retry packet for that property. 790 5.3.3. 0-RTT Secret 792 0-RTT keys are those keys that are used in resumed connections prior 793 to the completion of the TLS handshake. Data sent using 0-RTT keys 794 might be replayed and so has some restrictions on its use, see 795 Section 8.2. 0-RTT keys are used after sending or receiving a 796 ClientHello. 798 The secret is exported from TLS using the exporter label "EXPORTER- 799 QUIC 0rtt" and an empty context. The size of the secret MUST be the 800 size of the hash output for the PRF hash function negotiated by TLS. 801 This uses the TLS early_exporter_secret. The QUIC 0-RTT secret is 802 only used for protection of packets sent by the client. 804 client_0rtt_secret = 805 TLS-Early-Exporter("EXPORTER-QUIC 0rtt", "", Hash.length) 807 5.3.4. 1-RTT Secrets 809 1-RTT keys are used by both client and server after the TLS handshake 810 completes. There are two secrets used at any time: one is used to 811 derive packet protection keys for packets sent by the client, the 812 other for packet protection keys on packets sent by the server. 814 The initial client packet protection secret is exported from TLS 815 using the exporter label "EXPORTER-QUIC client 1rtt"; the initial 816 server packet protection secret uses the exporter label "EXPORTER- 817 QUIC server 1rtt". Both exporters use an empty context. The size of 818 the secret MUST be the size of the hash output for the PRF hash 819 function negotiated by TLS. 821 client_pp_secret<0> = 822 TLS-Exporter("EXPORTER-QUIC client 1rtt", "", Hash.length) 823 server_pp_secret<0> = 824 TLS-Exporter("EXPORTER-QUIC server 1rtt", "", Hash.length) 826 These secrets are used to derive the initial client and server packet 827 protection keys. 829 5.3.5. Updating 1-RTT Secrets 831 After a key update (see Section 6.2), the 1-RTT secrets are updated 832 using QHKDF-Expand. Updated secrets are derived from the existing 833 packet protection secret. A Label parameter of "client 1rtt" is used 834 for the client secret and "server 1rtt" for the server. The Length 835 is the same as the native output of the PRF hash function. 837 client_pp_secret = 838 QHKDF-Expand(client_pp_secret, "client 1rtt", Hash.length) 839 server_pp_secret = 840 QHKDF-Expand(server_pp_secret, "server 1rtt", Hash.length) 842 This allows for a succession of new secrets to be created as needed. 844 5.3.6. Packet Protection Keys 846 The complete key expansion uses a similar process for key expansion 847 to that defined in Section 7.3 of [TLS13], using QHKDF-Expand in 848 place of HKDF-Expand-Label. QUIC uses the AEAD function negotiated 849 by TLS. 851 The packet protection key and IV used to protect the 0-RTT packets 852 sent by a client are derived from the QUIC 0-RTT secret. The packet 853 protection keys and IVs for 1-RTT packets sent by the client and 854 server are derived from the current generation of client and server 855 1-RTT secrets (client_pp_secret and server_pp_secret) 856 respectively. 858 The length of the QHKDF-Expand output is determined by the 859 requirements of the AEAD function selected by TLS. The key length is 860 the AEAD key size. As defined in Section 5.3 of [TLS13], the IV 861 length is the larger of 8 or N_MIN (see Section 4 of [AEAD]; all 862 ciphersuites defined in [TLS13] have N_MIN set to 12). 864 The size of the packet protection key is determined by the packet 865 protection algorithm, see Section 5.6. 867 For any secret S, the AEAD key uses a label of "key", the IV uses a 868 label of "iv", packet number encryption uses a label of "pn": 870 key = QHKDF-Expand(S, "key", key_length) 871 iv = QHKDF-Expand(S, "iv", iv_length) 872 pn_key = QHKDF-Expand(S, "pn", pn_key_length) 874 Separate keys are derived for packet protection by clients and 875 servers. Each endpoint uses the packet protection key of its peer to 876 remove packet protection. For example, client packet protection keys 877 and IVs - which are also used by the server to remove the protection 878 added by a client - for AEAD_AES_128_GCM are derived from 1-RTT 879 secrets as follows: 881 client_pp_key = QHKDF-Expand(client_pp_secret, "key", 16) 882 client_pp_iv = QHKDF-Expand(client_pp_secret, "iv", 12) 883 client_pp_pn = QHKDF-Expand(client_pp_secret, "pn", 12) 885 The QUIC packet protection initially starts with keying material 886 derived from handshake keys. For a client, when the TLS state 887 machine reports that the ClientHello has been sent, 0-RTT keys can be 888 generated and installed for writing, if 0-RTT is available. Finally, 889 the TLS state machine reports completion of the handshake and 1-RTT 890 keys can be generated and installed for writing. 892 5.4. QUIC AEAD Usage 894 The Authentication Encryption with Associated Data (AEAD) [AEAD] 895 function used for QUIC packet protection is AEAD that is negotiated 896 for use with the TLS connection. For example, if TLS is using the 897 TLS_AES_128_GCM_SHA256, the AEAD_AES_128_GCM function is used. 899 QUIC packets are protected prior to applying packet number encryption 900 (Section 5.6). The unprotected packet number is part of the 901 associated data (A). When removing packet protection, an endpoint 902 first removes the protection from the packet number. 904 All QUIC packets other than Version Negotiation and Stateless Reset 905 packets are protected with an AEAD algorithm [AEAD]. Prior to 906 establishing a shared secret, packets are protected with 907 AEAD_AES_128_GCM and a key derived from the client's connection ID 908 (see Section 5.3.2). This provides protection against off-path 909 attackers and robustness against QUIC version unaware middleboxes, 910 but not against on-path attackers. 912 All ciphersuites currently defined for TLS 1.3 - and therefore QUIC - 913 have a 16-byte authentication tag and produce an output 16 bytes 914 larger than their input. 916 Once TLS has provided a key, the contents of regular QUIC packets 917 immediately after any TLS messages have been sent are protected by 918 the AEAD selected by TLS. 920 The key, K, is either the client packet protection key 921 (client_pp_key) or the server packet protection key 922 (server_pp_key), derived as defined in Section 5.3. 924 The nonce, N, is formed by combining the packet protection IV (either 925 client_pp_iv or server_pp_iv) with the packet number. The 64 926 bits of the reconstructed QUIC packet number in network byte order is 927 left-padded with zeros to the size of the IV. The exclusive OR of 928 the padded packet number and the IV forms the AEAD nonce. 930 The associated data, A, for the AEAD is the contents of the QUIC 931 header, starting from the flags octet in either the short or long 932 header. 934 The input plaintext, P, for the AEAD is the content of the QUIC frame 935 following the header, as described in [QUIC-TRANSPORT]. 937 The output ciphertext, C, of the AEAD is transmitted in place of P. 939 5.5. Packet Numbers 941 QUIC has a single, contiguous packet number space. In comparison, 942 TLS restarts its sequence number each time that record protection 943 keys are changed. The sequence number restart in TLS ensures that a 944 compromise of the current traffic keys does not allow an attacker to 945 truncate the data that is sent after a key update by sending 946 additional packets under the old key (causing new packets to be 947 discarded). 949 QUIC does not assume a reliable transport and is required to handle 950 attacks where packets are dropped in other ways. QUIC is therefore 951 not affected by this form of truncation. 953 The QUIC packet number is not reset and it is not permitted to go 954 higher than its maximum value of 2^62-1. This establishes a hard 955 limit on the number of packets that can be sent. 957 Some AEAD functions have limits for how many packets can be encrypted 958 under the same key and IV (see for example [AEBounds]). This might 959 be lower than the packet number limit. An endpoint MUST initiate a 960 key update (Section 6.2) prior to exceeding any limit set for the 961 AEAD that is in use. 963 TLS maintains a separate sequence number that is used for record 964 protection on the connection that is hosted on stream 0. This 965 sequence number is not visible to QUIC. 967 5.6. Packet Number Protection 969 QUIC packets are protected using a key that is derived from the 970 current set of secrets. The key derived using the "pn" label is used 971 to protect the packet number from casual observation. The packet 972 number protection algorithm depends on the negotiated AEAD. 974 Packet number protection is applied after packet protection is 975 applied (see Section 5.4). The ciphertext of the packet is sampled 976 and used as input to an encryption algorithm. 978 In sampling the packet ciphertext, the packet number length is 979 assumed to be the smaller of the maximum possible packet number 980 encoding (4 octets), or the size of the protected packet minus the 981 minimum expansion for the AEAD. For example, the sampled ciphertext 982 for a packet with a short header can be determined by: 984 "sample_offset = min(1 + connection_id_length + 4, packet_length - 985 aead_expansion) sample = 986 packet[sample_offset..sample_offset+sample_length] " 988 To ensure that this process does not sample the packet number, packet 989 number protection algorithms MUST NOT sample more ciphertext than the 990 minimum expansion of the corresponding AEAD. 992 Packet number protection is applied to the packet number encoded as 993 described in Section 4.8 of [QUIC-TRANSPORT]. Since the length of 994 the packet number is stored in the first octet of the encoded packet 995 number, it may be necessary to progressively decrypt the packet 996 number. 998 Before a TLS ciphersuite can be used with QUIC, a packet protection 999 algorithm MUST be specifed for the AEAD used with that ciphersuite. 1000 This document defines algorithms for AEAD_AES_128_GCM, 1001 AEAD_AES_128_CCM, AEAD_AES_256_GCM, AEAD_AES_256_CCM (all AES AEADs 1002 are defined in [RFC5116]), and AEAD_CHACHA20_POLY1305 ([CHACHA]). 1004 5.6.1. AES-Based Packet Number Protection 1006 This section defines the packet protection algorithm for 1007 AEAD_AES_128_GCM, AEAD_AES_128_CCM, AEAD_AES_256_GCM, and 1008 AEAD_AES_256_CCM. AEAD_AES_128_GCM and AEAD_AES_128_CCM use 128-bit 1009 AES [AES] in counter (CTR) mode. AEAD_AES_256_GCM, and 1010 AEAD_AES_256_CCM use 256-bit AES in CTR mode. 1012 This algorithm samples 16 octets from the packet ciphertext. This 1013 value is used as the counter input to AES-CTR. 1015 encrypted_pn = AES-CTR(pn_key, sample, packet_number) 1017 5.6.2. ChaCha20-Based Packet Number Protection 1019 When AEAD_CHACHA20_POLY1305 is in use, packet number protection uses 1020 the raw ChaCha20 function as defined in Section 2.4 of [CHACHA]. 1021 This uses a 256-bit key and 16 octets sampled from the packet 1022 protection output. 1024 The first 4 octets of the sampled ciphertext are interpreted as a 1025 32-bit number in little-endian order and are used as the block count. 1026 The remaining 12 octets are interpreted as three concatenated 32-bit 1027 numbers in little-endian order and used as the nonce. 1029 The encoded packet number is then encrypted with ChaCha20 directly. 1030 In pseudocode: 1032 counter = DecodeLE(sample[0..3]) 1033 nonce = DecodeLE(sample[4..7], sample[8..11], sample[12..15]) 1034 encrypted_pn = ChaCha20(pn_key, counter, nonce, packet_number) 1036 5.7. Receiving Protected Packets 1038 Once an endpoint successfully receives a packet with a given packet 1039 number, it MUST discard all packets with higher packet numbers if 1040 they cannot be successfully unprotected with either the same key, or 1041 - if there is a key update - the next packet protection key (see 1042 Section 6.2). Similarly, a packet that appears to trigger a key 1043 update, but cannot be unprotected successfully MUST be discarded. 1045 Failure to unprotect a packet does not necessarily indicate the 1046 existence of a protocol error in a peer or an attack. The truncated 1047 packet number encoding used in QUIC can cause packet numbers to be 1048 decoded incorrectly if they are delayed significantly. 1050 6. Key Phases 1052 As TLS reports the availability of 0-RTT and 1-RTT keys, new keying 1053 material can be exported from TLS and used for QUIC packet 1054 protection. At each transition during the handshake a new secret is 1055 exported from TLS and packet protection keys are derived from that 1056 secret. 1058 Every time that a new set of keys is used for protecting outbound 1059 packets, the KEY_PHASE bit in the public flags is toggled. 0-RTT 1060 protected packets use the QUIC long header, they do not use the 1061 KEY_PHASE bit to select the correct keys (see Section 6.1.1). 1063 Once the connection is fully enabled, the KEY_PHASE bit allows a 1064 recipient to detect a change in keying material without necessarily 1065 needing to receive the first packet that triggered the change. An 1066 endpoint that notices a changed KEY_PHASE bit can update keys and 1067 decrypt the packet that contains the changed bit, see Section 6.2. 1069 The KEY_PHASE bit is included as the 0x20 bit of the QUIC short 1070 header. 1072 Transitions between keys during the handshake are complicated by the 1073 need to ensure that TLS handshake messages are sent with the correct 1074 packet protection. 1076 6.1. Packet Protection for the TLS Handshake 1078 The initial exchange of packets that carry the TLS handshake are 1079 AEAD-protected using the handshake secrets generated as described in 1080 Section 5.3.2. All TLS handshake messages up to the TLS Finished 1081 message sent by either endpoint use packets protected with handshake 1082 keys. 1084 Any TLS handshake messages that are sent after completing the TLS 1085 handshake do not need special packet protection rules. Packets 1086 containing these messages use the packet protection keys that are 1087 current at the time of sending (or retransmission). 1089 Like the client, a server MUST send retransmissions of its 1090 unprotected handshake messages or acknowledgments for unprotected 1091 handshake messages sent by the client in packets protected with 1092 handshake keys. 1094 6.1.1. Initial Key Transitions 1096 Once the TLS handshake is complete, keying material is exported from 1097 TLS and used to protect QUIC packets. 1099 Packets protected with 1-RTT keys initially have a KEY_PHASE bit set 1100 to 0. This bit inverts with each subsequent key update (see 1101 Section 6.2). 1103 If the client sends 0-RTT data, it uses the 0-RTT packet type. The 1104 packet that contains the TLS EndOfEarlyData and Finished messages are 1105 sent in packets protected with handshake keys. 1107 Using distinct packet types during the handshake for handshake 1108 messages, 0-RTT data, and 1-RTT data ensures that the server is able 1109 to distinguish between the different keys used to remove packet 1110 protection. All of these packets can arrive concurrently at a 1111 server. 1113 A server might choose to retain 0-RTT packets that arrive before a 1114 TLS ClientHello. The server can then use those packets once the 1115 ClientHello arrives. However, the potential for denial of service 1116 from buffering 0-RTT packets is significant. These packets cannot be 1117 authenticated and so might be employed by an attacker to exhaust 1118 server resources. Limiting the number of packets that are saved 1119 might be necessary. 1121 The server transitions to using 1-RTT keys after sending its first 1122 flight of TLS handshake messages, ending in the Finished. From this 1123 point, the server protects all packets with 1-RTT keys. Future 1124 packets are therefore protected with 1-RTT keys. Initially, these 1125 are marked with a KEY_PHASE of 0. 1127 6.1.2. Retransmission and Acknowledgment of Unprotected Packets 1129 TLS handshake messages from both client and server are critical to 1130 the key exchange. The contents of these messages determine the keys 1131 used to protect later messages. If these handshake messages are 1132 included in packets that are protected with these keys, they will be 1133 indecipherable to the recipient. 1135 Even though newer keys could be available when retransmitting, 1136 retransmissions of these handshake messages MUST be sent in packets 1137 protected with handshake keys. An endpoint MUST generate ACK frames 1138 for these messages and send them in packets protected with handshake 1139 keys. 1141 A HelloRetryRequest handshake message might be used to reject an 1142 initial ClientHello. A HelloRetryRequest handshake message is sent 1143 in a Retry packet; any second ClientHello that is sent in response 1144 uses a Initial packet type. These packets are only protected with a 1145 predictable key (see Section 5.3.2). This is natural, because no 1146 shared secret will be available when these messages need to be sent. 1147 Upon receipt of a HelloRetryRequest, a client SHOULD cease any 1148 transmission of 0-RTT data; 0-RTT data will only be discarded by any 1149 server that sends a HelloRetryRequest. 1151 The packet type ensures that protected packets are clearly 1152 distinguished from unprotected packets. Loss or reordering might 1153 cause unprotected packets to arrive once 1-RTT keys are in use, 1154 unprotected packets are easily distinguished from 1-RTT packets using 1155 the packet type. 1157 Once 1-RTT keys are available to an endpoint, it no longer needs the 1158 TLS handshake messages that are carried in unprotected packets. 1159 However, a server might need to retransmit its TLS handshake messages 1160 in response to receiving an unprotected packet that contains ACK 1161 frames. A server MUST process ACK frames in unprotected packets 1162 until the TLS handshake is reported as complete, or it receives an 1163 ACK frame in a protected packet that acknowledges all of its 1164 handshake messages. 1166 To limit the number of key phases that could be active, an endpoint 1167 MUST NOT initiate a key update while there are any unacknowledged 1168 handshake messages, see Section 6.2. 1170 6.2. Key Update 1172 Once the TLS handshake is complete, the KEY_PHASE bit allows for 1173 refreshes of keying material by either peer. Endpoints start using 1174 updated keys immediately without additional signaling; the change in 1175 the KEY_PHASE bit indicates that a new key is in use. 1177 An endpoint MUST NOT initiate more than one key update at a time. A 1178 new key cannot be used until the endpoint has received and 1179 successfully decrypted a packet with a matching KEY_PHASE. Note that 1180 when 0-RTT is attempted the value of the KEY_PHASE bit will be 1181 different on packets sent by either peer. 1183 A receiving endpoint detects an update when the KEY_PHASE bit doesn't 1184 match what it is expecting. It creates a new secret (see 1185 Section 5.3) and the corresponding read key and IV. If the packet 1186 can be decrypted and authenticated using these values, then the keys 1187 it uses for packet protection are also updated. The next packet sent 1188 by the endpoint will then use the new keys. 1190 An endpoint doesn't need to send packets immediately when it detects 1191 that its peer has updated keys. The next packet that it sends will 1192 simply use the new keys. If an endpoint detects a second update 1193 before it has sent any packets with updated keys it indicates that 1194 its peer has updated keys twice without awaiting a reciprocal update. 1195 An endpoint MUST treat consecutive key updates as a fatal error and 1196 abort the connection. 1198 An endpoint SHOULD retain old keys for a short period to allow it to 1199 decrypt packets with smaller packet numbers than the packet that 1200 triggered the key update. This allows an endpoint to consume packets 1201 that are reordered around the transition between keys. Packets with 1202 higher packet numbers always use the updated keys and MUST NOT be 1203 decrypted with old keys. 1205 Keys and their corresponding secrets SHOULD be discarded when an 1206 endpoint has received all packets with packet numbers lower than the 1207 lowest packet number used for the new key. An endpoint might discard 1208 keys if it determines that the length of the delay to affected 1209 packets is excessive. 1211 This ensures that once the handshake is complete, packets with the 1212 same KEY_PHASE will have the same packet protection keys, unless 1213 there are multiple key updates in a short time frame succession and 1214 significant packet reordering. 1216 Initiating Peer Responding Peer 1218 @M QUIC Frames 1219 New Keys -> @N 1220 @N QUIC Frames 1221 --------> 1222 QUIC Frames @M 1223 New Keys -> @N 1224 QUIC Frames @N 1225 <-------- 1227 Figure 5: Key Update 1229 As shown in Figure 3 and Figure 5, there is never a situation where 1230 there are more than two different sets of keying material that might 1231 be received by a peer. Once both sending and receiving keys have 1232 been updated, the peers immediately begin to use them. 1234 A server cannot initiate a key update until it has received the 1235 client's Finished message. Otherwise, packets protected by the 1236 updated keys could be confused for retransmissions of handshake 1237 messages. A client cannot initiate a key update until all of its 1238 handshake messages have been acknowledged by the server. 1240 A packet that triggers a key update could arrive after successfully 1241 processing a packet with a higher packet number. This is only 1242 possible if there is a key compromise and an attack, or if the peer 1243 is incorrectly reverting to use of old keys. Because the latter 1244 cannot be differentiated from an attack, an endpoint MUST immediately 1245 terminate the connection if it detects this condition. 1247 7. Client Address Validation 1249 Two tools are provided by TLS to enable validation of client source 1250 addresses at a server: the cookie in the HelloRetryRequest message, 1251 and the ticket in the NewSessionTicket message. 1253 7.1. HelloRetryRequest Address Validation 1255 The cookie extension in the TLS HelloRetryRequest message allows a 1256 server to perform source address validation during the handshake. 1258 When QUIC requests address validation during the processing of the 1259 first ClientHello, the token it provides is included in the cookie 1260 extension of a HelloRetryRequest. As long as the cookie cannot be 1261 successfully guessed by a client, the server can be assured that the 1262 client received the HelloRetryRequest if it includes the value in a 1263 second ClientHello. 1265 An initial ClientHello never includes a cookie extension. Thus, if a 1266 server constructs a cookie that contains all the information 1267 necessary to reconstruct state, it can discard local state after 1268 sending a HelloRetryRequest. Presence of a valid cookie in a 1269 ClientHello indicates that the ClientHello is a second attempt from 1270 the client. 1272 An address validation token can be extracted from a second 1273 ClientHello and passed to the transport for further validation. If 1274 that validation fails, the server MUST fail the TLS handshake and 1275 send an illegal_parameter alert. 1277 Combining address validation with the other uses of HelloRetryRequest 1278 ensures that there are fewer ways in which an additional round-trip 1279 can be added to the handshake. In particular, this makes it possible 1280 to combine a request for address validation with a request for a 1281 different client key share. 1283 If TLS needs to send a HelloRetryRequest for other reasons, it needs 1284 to ensure that it can correctly identify the reason that the 1285 HelloRetryRequest was generated. During the processing of a second 1286 ClientHello, TLS does not need to consult the transport protocol 1287 regarding address validation if address validation was not requested 1288 originally. In such cases, the cookie extension could either be 1289 absent or it could indicate that an address validation token is not 1290 present. 1292 7.1.1. Stateless Address Validation 1294 A server can use the cookie extension to store all state necessary to 1295 continue the connection. This allows a server to avoid committing 1296 state for clients that have unvalidated source addresses. 1298 For instance, a server could use a statically-configured key to 1299 encrypt the information that it requires and include that information 1300 in the cookie. In addition to address validation information, a 1301 server that uses encryption also needs to be able recover the hash of 1302 the ClientHello and its length, plus any information it needs in 1303 order to reconstruct the HelloRetryRequest. 1305 7.1.2. Sending HelloRetryRequest 1307 A server does not need to maintain state for the connection when 1308 sending a HelloRetryRequest message. This might be necessary to 1309 avoid creating a denial of service exposure for the server. However, 1310 this means that information about the transport will be lost at the 1311 server. This includes the stream offset of stream 0, the packet 1312 number that the server selects, and any opportunity to measure round 1313 trip time. 1315 A server MUST send a TLS HelloRetryRequest in a Retry packet. Using 1316 a Retry packet causes the client to reset stream offsets. It also 1317 avoids the need for the server select an initial packet number, which 1318 would need to be remembered so that subsequent packets could be 1319 correctly numbered. 1321 A HelloRetryRequest message MUST NOT be split between multiple Retry 1322 packets. This means that HelloRetryRequest is subject to the same 1323 size constraints as a ClientHello (see Section 4.4). 1325 A client might send multiple Initial packets in response to loss. If 1326 a server sends a Retry packet in response to an Initial packet, it 1327 does not have to generate the same Retry packet each time. 1328 Variations in Retry packet, if used by a client, could lead to 1329 multiple connections derived from the same ClientHello. Reuse of the 1330 client nonce is not supported by TLS and could lead to security 1331 vulnerabilities. Clients that receive multiple Retry packets MUST 1332 use only one and discard the remainder. 1334 7.2. NewSessionTicket Address Validation 1336 The ticket in the TLS NewSessionTicket message allows a server to 1337 provide a client with a similar sort of token. When a client resumes 1338 a TLS connection - whether or not 0-RTT is attempted - it includes 1339 the ticket in the handshake message. As with the HelloRetryRequest 1340 cookie, the server includes the address validation token in the 1341 ticket. TLS provides the token it extracts from the session ticket 1342 to the transport when it asks whether source address validation is 1343 needed. 1345 If both a HelloRetryRequest cookie and a session ticket are present 1346 in the ClientHello, only the token from the cookie is passed to the 1347 transport. The presence of a cookie indicates that this is a second 1348 ClientHello - the token from the session ticket will have been 1349 provided to the transport when it appeared in the first ClientHello. 1351 A server can send a NewSessionTicket message at any time. This 1352 allows it to update the state - and the address validation token - 1353 that is included in the ticket. This might be done to refresh the 1354 ticket or token, or it might be generated in response to changes in 1355 the state of the connection. QUIC can request that a 1356 NewSessionTicket be sent by providing a new address validation token. 1358 A server that intends to support 0-RTT SHOULD provide an address 1359 validation token immediately after completing the TLS handshake. 1361 7.3. Address Validation Token Integrity 1363 TLS MUST provide integrity protection for address validation token 1364 unless the transport guarantees integrity protection by other means. 1365 For a NewSessionTicket that includes confidential information - such 1366 as the resumption secret - including the token under authenticated 1367 encryption ensures that the token gains both confidentiality and 1368 integrity protection without duplicating the overheads of that 1369 protection. 1371 8. Pre-handshake QUIC Messages 1373 Implementations MUST NOT exchange data on any stream other than 1374 stream 0 without packet protection. QUIC requires the use of several 1375 types of frame for managing loss detection and recovery during this 1376 phase. In addition, it might be useful to use the data acquired 1377 during the exchange of unauthenticated messages for congestion 1378 control. 1380 This section generally only applies to TLS handshake messages from 1381 both peers and acknowledgments of the packets carrying those 1382 messages. In many cases, the need for servers to provide 1383 acknowledgments is minimal, since the messages that clients send are 1384 small and implicitly acknowledged by the server's responses. 1386 The actions that a peer takes as a result of receiving an 1387 unauthenticated packet needs to be limited. In particular, state 1388 established by these packets cannot be retained once record 1389 protection commences. 1391 There are several approaches possible for dealing with 1392 unauthenticated packets prior to handshake completion: 1394 o discard and ignore them 1396 o use them, but reset any state that is established once the 1397 handshake completes 1399 o use them and authenticate them afterwards; failing the handshake 1400 if they can't be authenticated 1402 o save them and use them when they can be properly authenticated 1404 o treat them as a fatal error 1406 Different strategies are appropriate for different types of data. 1407 This document proposes that all strategies are possible depending on 1408 the type of message. 1410 o Transport parameters are made usable and authenticated as part of 1411 the TLS handshake (see Section 9.2). 1413 o Most unprotected messages are treated as fatal errors when 1414 received except for the small number necessary to permit the 1415 handshake to complete (see Section 8.1). 1417 o Protected packets can either be discarded or saved and later used 1418 (see Section 8.3). 1420 8.1. Unprotected Packets Prior to Handshake Completion 1422 This section describes the handling of messages that are sent and 1423 received prior to the completion of the TLS handshake. 1425 Sending and receiving unprotected messages is hazardous. Unless 1426 expressly permitted, receipt of an unprotected message of any kind 1427 MUST be treated as a fatal error. 1429 8.1.1. STREAM Frames 1431 "STREAM" frames for stream 0 are permitted. These carry the TLS 1432 handshake messages. Once 1-RTT keys are available, unprotected 1433 "STREAM" frames on stream 0 can be ignored. 1435 Receiving unprotected "STREAM" frames for other streams MUST be 1436 treated as a fatal error. 1438 8.1.2. ACK Frames 1440 "ACK" frames are permitted prior to the handshake being complete. 1441 Information learned from "ACK" frames cannot be entirely relied upon, 1442 since an attacker is able to inject these packets. Timing and packet 1443 retransmission information from "ACK" frames is critical to the 1444 functioning of the protocol, but these frames might be spoofed or 1445 altered. 1447 Endpoints MUST NOT use an "ACK" frame in an unprotected packet to 1448 acknowledge packets that were protected by 0-RTT or 1-RTT keys. An 1449 endpoint MUST treat receipt of an "ACK" frame in an unprotected 1450 packet that claims to acknowledge protected packets as a connection 1451 error of type OPTIMISTIC_ACK. An endpoint that can read protected 1452 data is always able to send protected data. 1454 Note: 0-RTT data can be acknowledged by the server as it receives 1455 it, but any packets containing acknowledgments of 0-RTT data 1456 cannot have packet protection removed by the client until the TLS 1457 handshake is complete. The 1-RTT keys necessary to remove packet 1458 protection cannot be derived until the client receives all server 1459 handshake messages. 1461 An endpoint SHOULD use data from "ACK" frames carried in unprotected 1462 packets or packets protected with 0-RTT keys only during the initial 1463 handshake. All "ACK" frames contained in unprotected packets that 1464 are received after successful receipt of a packet protected with 1465 1-RTT keys MUST be discarded. An endpoint SHOULD therefore include 1466 acknowledgments for unprotected and any packets protected with 0-RTT 1467 keys until it sees an acknowledgment for a packet that is both 1468 protected with 1-RTT keys and contains an "ACK" frame. 1470 8.1.3. Updates to Data and Stream Limits 1472 "MAX_DATA", "MAX_STREAM_DATA", "BLOCKED", "STREAM_BLOCKED", and 1473 "MAX_STREAM_ID" frames MUST NOT be sent unprotected. 1475 Though data is exchanged on stream 0, the initial flow control window 1476 on that stream is sufficiently large to allow the TLS handshake to 1477 complete. This limits the maximum size of the TLS handshake and 1478 would prevent a server or client from using an abnormally large 1479 certificate chain. 1481 Stream 0 is exempt from the connection-level flow control window. 1483 Consequently, there is no need to signal being blocked on flow 1484 control. 1486 Similarly, there is no need to increase the number of allowed streams 1487 until the handshake completes. 1489 8.1.4. Handshake Failures 1491 The "CONNECTION_CLOSE" frame MAY be sent by either endpoint in a 1492 Handshake packet. This allows an endpoint to signal a fatal error 1493 with connection establishment. A "STREAM" frame carrying a TLS alert 1494 MAY be included in the same packet. 1496 8.1.5. Address Verification 1498 In order to perform source-address verification before the handshake 1499 is complete, "PATH_CHALLENGE" and "PATH_RESPONSE" frames MAY be 1500 exchanged unprotected. 1502 8.1.6. Denial of Service with Unprotected Packets 1504 Accepting unprotected - specifically unauthenticated - packets 1505 presents a denial of service risk to endpoints. An attacker that is 1506 able to inject unprotected packets can cause a recipient to drop even 1507 protected packets with a matching packet number. The spurious packet 1508 shadows the genuine packet, causing the genuine packet to be ignored 1509 as redundant. 1511 Once the TLS handshake is complete, both peers MUST ignore 1512 unprotected packets. From that point onward, unprotected messages 1513 can be safely dropped. 1515 Since only TLS handshake packets and acknowledgments are sent in the 1516 clear, an attacker is able to force implementations to rely on 1517 retransmission for packets that are lost or shadowed. Thus, an 1518 attacker that intends to deny service to an endpoint has to drop or 1519 shadow protected packets in order to ensure that their victim 1520 continues to accept unprotected packets. The ability to shadow 1521 packets means that an attacker does not need to be on path. 1523 In addition to causing valid packets to be dropped, an attacker can 1524 generate packets with an intent of causing the recipient to expend 1525 processing resources. See Section 10.2 for a discussion of these 1526 risks. 1528 To avoid receiving TLS packets that contain no useful data, a TLS 1529 implementation MUST reject empty TLS handshake records and any record 1530 that is not permitted by the TLS state machine. Any TLS application 1531 data or alerts that are received prior to the end of the handshake 1532 MUST be treated as a connection error of type PROTOCOL_VIOLATION. 1534 8.2. Use of 0-RTT Keys 1536 If 0-RTT keys are available (see Section 5.2), the lack of replay 1537 protection means that restrictions on their use are necessary to 1538 avoid replay attacks on the protocol. 1540 A client MUST only use 0-RTT keys to protect data that is idempotent. 1541 A client MAY wish to apply additional restrictions on what data it 1542 sends prior to the completion of the TLS handshake. A client 1543 otherwise treats 0-RTT keys as equivalent to 1-RTT keys. 1545 A client that receives an indication that its 0-RTT data has been 1546 accepted by a server can send 0-RTT data until it receives all of the 1547 server's handshake messages. A client SHOULD stop sending 0-RTT data 1548 if it receives an indication that 0-RTT data has been rejected. 1550 A server MUST NOT use 0-RTT keys to protect packets. 1552 If a server rejects 0-RTT, then the TLS stream will not include any 1553 TLS records protected with 0-RTT keys. 1555 8.3. Receiving Out-of-Order Protected Frames 1557 Due to reordering and loss, protected packets might be received by an 1558 endpoint before the final TLS handshake messages are received. A 1559 client will be unable to decrypt 1-RTT packets from the server, 1560 whereas a server will be able to decrypt 1-RTT packets from the 1561 client. 1563 Packets protected with 1-RTT keys MAY be stored and later decrypted 1564 and used once the handshake is complete. A server MUST NOT use 1-RTT 1565 protected packets before verifying either the client Finished message 1566 or - in the case that the server has chosen to use a pre-shared key - 1567 the pre-shared key binder (see Section 4.2.8 of [TLS13]). Verifying 1568 these values provides the server with an assurance that the 1569 ClientHello has not been modified. 1571 A server could receive packets protected with 0-RTT keys prior to 1572 receiving a TLS ClientHello. The server MAY retain these packets for 1573 later decryption in anticipation of receiving a ClientHello. 1575 Receiving and verifying the TLS Finished message is critical in 1576 ensuring the integrity of the TLS handshake. A server MUST NOT use 1577 protected packets from the client prior to verifying the client 1578 Finished message if its response depends on client authentication. 1580 9. QUIC-Specific Additions to the TLS Handshake 1582 QUIC uses the TLS handshake for more than just negotiation of 1583 cryptographic parameters. The TLS handshake validates protocol 1584 version selection, provides preliminary values for QUIC transport 1585 parameters, and allows a server to perform return routeability checks 1586 on clients. 1588 9.1. Protocol and Version Negotiation 1590 The QUIC version negotiation mechanism is used to negotiate the 1591 version of QUIC that is used prior to the completion of the 1592 handshake. However, this packet is not authenticated, enabling an 1593 active attacker to force a version downgrade. 1595 To ensure that a QUIC version downgrade is not forced by an attacker, 1596 version information is copied into the TLS handshake, which provides 1597 integrity protection for the QUIC negotiation. This does not prevent 1598 version downgrade prior to the completion of the handshake, though it 1599 means that a downgrade causes a handshake failure. 1601 TLS uses Application Layer Protocol Negotiation (ALPN) [RFC7301] to 1602 select an application protocol. The application-layer protocol MAY 1603 restrict the QUIC versions that it can operate over. Servers MUST 1604 select an application protocol compatible with the QUIC version that 1605 the client has selected. 1607 If the server cannot select a compatible combination of application 1608 protocol and QUIC version, it MUST abort the connection. A client 1609 MUST abort a connection if the server picks an incompatible 1610 combination of QUIC version and ALPN identifier. 1612 9.2. QUIC Transport Parameters Extension 1614 QUIC transport parameters are carried in a TLS extension. Different 1615 versions of QUIC might define a different format for this struct. 1617 Including transport parameters in the TLS handshake provides 1618 integrity protection for these values. 1620 enum { 1621 quic_transport_parameters(26), (65535) 1622 } ExtensionType; 1624 The "extension_data" field of the quic_transport_parameters extension 1625 contains a value that is defined by the version of QUIC that is in 1626 use. The quic_transport_parameters extension carries a 1627 TransportParameters when the version of QUIC defined in 1628 [QUIC-TRANSPORT] is used. 1630 The quic_transport_parameters extension is carried in the ClientHello 1631 and the EncryptedExtensions messages during the handshake. 1633 10. Security Considerations 1635 There are likely to be some real clangers here eventually, but the 1636 current set of issues is well captured in the relevant sections of 1637 the main text. 1639 Never assume that because it isn't in the security considerations 1640 section it doesn't affect security. Most of this document does. 1642 10.1. Packet Reflection Attack Mitigation 1644 A small ClientHello that results in a large block of handshake 1645 messages from a server can be used in packet reflection attacks to 1646 amplify the traffic generated by an attacker. 1648 Certificate caching [RFC7924] can reduce the size of the server's 1649 handshake messages significantly. 1651 QUIC requires that the packet containing a ClientHello be padded to a 1652 minimum size. A server is less likely to generate a packet 1653 reflection attack if the data it sends is a small multiple of this 1654 size. A server SHOULD use a HelloRetryRequest if the size of the 1655 handshake messages it sends is likely to significantly exceed the 1656 size of the packet containing the ClientHello. 1658 10.2. Peer Denial of Service 1660 QUIC, TLS and HTTP/2 all contain a messages that have legitimate uses 1661 in some contexts, but that can be abused to cause a peer to expend 1662 processing resources without having any observable impact on the 1663 state of the connection. If processing is disproportionately large 1664 in comparison to the observable effects on bandwidth or state, then 1665 this could allow a malicious peer to exhaust processing capacity 1666 without consequence. 1668 QUIC prohibits the sending of empty "STREAM" frames unless they are 1669 marked with the FIN bit. This prevents "STREAM" frames from being 1670 sent that only waste effort. 1672 TLS records SHOULD always contain at least one octet of a handshake 1673 messages or alert. Records containing only padding are permitted 1674 during the handshake, but an excessive number might be used to 1675 generate unnecessary work. Once the TLS handshake is complete, 1676 endpoints MUST NOT send TLS application data records. Receiving TLS 1677 application data MUST be treated as a connection error of type 1678 PROTOCOL_VIOLATION. 1680 While there are legitimate uses for some redundant packets, 1681 implementations SHOULD track redundant packets and treat excessive 1682 volumes of any non-productive packets as indicative of an attack. 1684 10.3. Packet Number Protection Analysis 1686 Packet number protection relies the packet protection AEAD being a 1687 pseudorandom function (PRF), which is not a property that AEAD 1688 algorithms guarantee. Therefore, no strong assurances about the 1689 general security of this mechanism can be shown in the general case. 1690 The AEAD algorithms described in this document are assumed to be 1691 PRFs. 1693 The packet number protection algorithms defined in this document take 1694 the form: 1696 "encrypted_pn = packet_number XOR PRF(pn_key, sample) " 1698 This construction is secure against chosen plaintext attacks (IND- 1699 CPA) [IMC]. 1701 Use of the same key and ciphertext sample more than once risks 1702 compromising packet number protection. Protecting two different 1703 packet numbers with the same key and ciphertext sample reveals the 1704 exclusive OR of those packet numbers. Assuming that the AEAD acts as 1705 a PRF, if L bits are sampled, the odds of two ciphertext samples 1706 being identical approach 2^(-L/2), that is, the birthday bound. For 1707 the algorithms described in this document, that probability is one in 1708 2^64. 1710 Note: In some cases, inputs shorter than the full size required by 1711 the packet protection algorithm might be used. 1713 To prevent an attacker from modifying packet numbers, values of 1714 packet numbers are transitively authenticated using packet 1715 protection; packet numbers are part of the authenticated additional 1716 data. A falsified or modified packet number can only be detected 1717 once the packet protection is removed. 1719 An attacker can guess values for packet numbers and have an endpoint 1720 confirm guesses through timing side channels. If the recipient of a 1721 packet discards packets with duplicate packet numbers without 1722 attempting to remove packet protection they could reveal through 1723 timing side-channels that the packet number matches a received 1724 packet. For authentication to be free from side-channels, the entire 1725 process of packet number protection removal, packet number recovery, 1726 and packet protection removal MUST be applied together without timing 1727 and other side-channels. 1729 For the sending of packets, construction and protection of packet 1730 payloads and packet numbers MUST be free from side-channels that 1731 would reveal the packet number or its encoded size. 1733 11. Error Codes 1735 This section defines error codes from the error code space used in 1736 [QUIC-TRANSPORT]. 1738 The following error codes are defined when TLS is used for the crypto 1739 handshake: 1741 TLS_HANDSHAKE_FAILED (0x201): The TLS handshake failed. 1743 TLS_FATAL_ALERT_GENERATED (0x202): A TLS fatal alert was sent, 1744 causing the TLS connection to end prematurely. 1746 TLS_FATAL_ALERT_RECEIVED (0x203): A TLS fatal alert was received, 1747 causing the TLS connection to end prematurely. 1749 12. IANA Considerations 1751 This document does not create any new IANA registries, but it 1752 registers the values in the following registries: 1754 o QUIC Transport Error Codes Registry [QUIC-TRANSPORT] - IANA is to 1755 register the three error codes found in Section 11, these are 1756 summarized in Table 1. 1758 o TLS ExtensionsType Registry [TLS-REGISTRIES] - IANA is to register 1759 the quic_transport_parameters extension found in Section 9.2. 1760 Assigning 26 to the extension would be greatly appreciated. The 1761 Recommended column is to be marked Yes. The TLS 1.3 Column is to 1762 include CH and EE. 1764 o TLS Exporter Label Registry [TLS-REGISTRIES] - IANA is requested 1765 to register "EXPORTER-QUIC 0rtt" from Section 5.3.3; "EXPORTER- 1766 QUIC client 1rtt" and "EXPORTER-QUIC server 1-RTT" from 1767 Section 5.3.4. The DTLS column is to be marked No. The 1768 Recommended column is to be marked Yes. 1770 +-------+---------------------------+---------------+---------------+ 1771 | Value | Error | Description | Specification | 1772 +-------+---------------------------+---------------+---------------+ 1773 | 0x201 | TLS_HANDSHAKE_FAILED | TLS handshake | Section 11 | 1774 | | | failure | | 1775 | | | | | 1776 | 0x202 | TLS_FATAL_ALERT_GENERATED | Sent TLS | Section 11 | 1777 | | | alert | | 1778 | | | | | 1779 | 0x203 | TLS_FATAL_ALERT_RECEIVED | Receives TLS | Section 11 | 1780 | | | alert | | 1781 +-------+---------------------------+---------------+---------------+ 1783 Table 1: QUIC Transport Error Codes for TLS 1785 13. References 1787 13.1. Normative References 1789 [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated 1790 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1791 . 1793 [AES] "Advanced encryption standard (AES)", National Institute 1794 of Standards and Technology report, 1795 DOI 10.6028/nist.fips.197, November 2001. 1797 [CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 1798 Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, 1799 . 1801 [HKDF] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1802 Key Derivation Function (HKDF)", RFC 5869, 1803 DOI 10.17487/RFC5869, May 2010, 1804 . 1806 [QUIC-TRANSPORT] 1807 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1808 Multiplexed and Secure Transport", draft-ietf-quic- 1809 transport-12 (work in progress), May 2018. 1811 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1812 Requirement Levels", BCP 14, RFC 2119, 1813 DOI 10.17487/RFC2119, March 1997, 1814 . 1816 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1817 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1818 . 1820 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1821 "Transport Layer Security (TLS) Application-Layer Protocol 1822 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1823 July 2014, . 1825 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1826 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1827 May 2017, . 1829 [SHA] Dang, Q., "Secure Hash Standard", National Institute of 1830 Standards and Technology report, 1831 DOI 10.6028/nist.fips.180-4, July 2015. 1833 [TLS-REGISTRIES] 1834 Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1835 and DTLS", draft-ietf-tls-iana-registry-updates-04 (work 1836 in progress), February 2018. 1838 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1839 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 1840 July 2017. 1842 13.2. Informative References 1844 [AEBounds] 1845 Luykx, A. and K. Paterson, "Limits on Authenticated 1846 Encryption Use in TLS", March 2016, 1847 . 1849 [IMC] Katz, J. and Y. Lindell, "Introduction to Modern 1850 Cryptography, Second Edition", ISBN 978-1466570269, 1851 November 2014. 1853 [QUIC-HTTP] 1854 Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over 1855 QUIC", draft-ietf-quic-http-12 (work in progress), May 1856 2018. 1858 [QUIC-RECOVERY] 1859 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 1860 and Congestion Control", draft-ietf-quic-recovery-11 (work 1861 in progress), May 2018. 1863 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1864 DOI 10.17487/RFC2818, May 2000, 1865 . 1867 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1868 Housley, R., and W. Polk, "Internet X.509 Public Key 1869 Infrastructure Certificate and Certificate Revocation List 1870 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1871 . 1873 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 1874 (TLS) Cached Information Extension", RFC 7924, 1875 DOI 10.17487/RFC7924, July 2016, 1876 . 1878 13.3. URIs 1880 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 1882 [2] https://github.com/quicwg 1884 [3] https://github.com/quicwg/base-drafts/labels/-tls 1886 Appendix A. Contributors 1888 Ryan Hamilton was originally an author of this specification. 1890 Appendix B. Acknowledgments 1892 This document has benefited from input from Dragana Damjanovic, 1893 Christian Huitema, Jana Iyengar, Adam Langley, Roberto Peon, Eric 1894 Rescorla, Ian Swett, and many others. 1896 Appendix C. Change Log 1898 *RFC Editor's Note:* Please remove this section prior to 1899 publication of a final version of this document. 1901 Issue and pull request numbers are listed with a leading octothorp. 1903 C.1. Since draft-ietf-quic-tls-10 1905 o No significant changes. 1907 C.2. Since draft-ietf-quic-tls-09 1909 o Cleaned up key schedule and updated the salt used for handshake 1910 packet protection (#1077) 1912 C.3. Since draft-ietf-quic-tls-08 1914 o Specify value for max_early_data_size to enable 0-RTT (#942) 1916 o Update key derivation function (#1003, #1004) 1918 C.4. Since draft-ietf-quic-tls-07 1920 o Handshake errors can be reported with CONNECTION_CLOSE (#608, 1921 #891) 1923 C.5. Since draft-ietf-quic-tls-05 1925 No significant changes. 1927 C.6. Since draft-ietf-quic-tls-04 1929 o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) 1931 C.7. Since draft-ietf-quic-tls-03 1933 No significant changes. 1935 C.8. Since draft-ietf-quic-tls-02 1937 o Updates to match changes in transport draft 1939 C.9. Since draft-ietf-quic-tls-01 1941 o Use TLS alerts to signal TLS errors (#272, #374) 1943 o Require ClientHello to fit in a single packet (#338) 1945 o The second client handshake flight is now sent in the clear (#262, 1946 #337) 1948 o The QUIC header is included as AEAD Associated Data (#226, #243, 1949 #302) 1951 o Add interface necessary for client address validation (#275) 1953 o Define peer authentication (#140) 1955 o Require at least TLS 1.3 (#138) 1957 o Define transport parameters as a TLS extension (#122) 1959 o Define handling for protected packets before the handshake 1960 completes (#39) 1962 o Decouple QUIC version and ALPN (#12) 1964 C.10. Since draft-ietf-quic-tls-00 1966 o Changed bit used to signal key phase 1968 o Updated key phase markings during the handshake 1970 o Added TLS interface requirements section 1972 o Moved to use of TLS exporters for key derivation 1974 o Moved TLS error code definitions into this document 1976 C.11. Since draft-thomson-quic-tls-01 1978 o Adopted as base for draft-ietf-quic-tls 1980 o Updated authors/editors list 1982 o Added status note 1984 Authors' Addresses 1986 Martin Thomson (editor) 1987 Mozilla 1989 Email: martin.thomson@gmail.com 1991 Sean Turner (editor) 1992 sn3rd 1994 Email: sean@sn3rd.com