idnits 2.17.1 draft-ietf-quic-tls-17.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o If the packet is from a previously installed encryption level, it MUST not contain data which extends past the end of previously received data in that flow. Implementations MUST treat any violations of this requirement as a connection error of type PROTOCOL_VIOLATION. -- The document date (December 18, 2018) is 1954 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 1530 -- Looks like a reference, but probably isn't: '2' on line 1532 -- Looks like a reference, but probably isn't: '3' on line 1534 -- Looks like a reference, but probably isn't: '0' on line 953 == Unused Reference: 'QUIC-HTTP' is defined on line 1513, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' ** Downref: Normative reference to an Informational RFC: RFC 8439 (ref. 'CHACHA') == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-17 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-17 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-17 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 6 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: June 21, 2019 sn3rd 6 December 18, 2018 8 Using TLS to Secure QUIC 9 draft-ietf-quic-tls-17 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 June 21, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 62 2.1. TLS Overview . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Carrying TLS Messages . . . . . . . . . . . . . . . . . . . . 7 65 4.1. Interface to TLS . . . . . . . . . . . . . . . . . . . . 9 66 4.1.1. Sending and Receiving Handshake Messages . . . . . . 9 67 4.1.2. Encryption Level Changes . . . . . . . . . . . . . . 11 68 4.1.3. TLS Interface Summary . . . . . . . . . . . . . . . . 12 69 4.2. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 13 70 4.3. ClientHello Size . . . . . . . . . . . . . . . . . . . . 14 71 4.4. Peer Authentication . . . . . . . . . . . . . . . . . . . 14 72 4.5. Enabling 0-RTT . . . . . . . . . . . . . . . . . . . . . 15 73 4.6. Rejecting 0-RTT . . . . . . . . . . . . . . . . . . . . . 15 74 4.7. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 15 75 4.8. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 16 76 4.9. Discarding Unused Keys . . . . . . . . . . . . . . . . . 16 77 4.10. Discarding Initial Keys . . . . . . . . . . . . . . . . . 17 78 5. Packet Protection . . . . . . . . . . . . . . . . . . . . . . 18 79 5.1. Packet Protection Keys . . . . . . . . . . . . . . . . . 18 80 5.2. Initial Secrets . . . . . . . . . . . . . . . . . . . . . 18 81 5.3. AEAD Usage . . . . . . . . . . . . . . . . . . . . . . . 19 82 5.4. Header Protection . . . . . . . . . . . . . . . . . . . . 20 83 5.4.1. Header Protection Application . . . . . . . . . . . . 21 84 5.4.2. Header Protection Sample . . . . . . . . . . . . . . 22 85 5.4.3. AES-Based Header Protection . . . . . . . . . . . . . 23 86 5.4.4. ChaCha20-Based Header Protection . . . . . . . . . . 24 87 5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 24 88 5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 24 89 5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 25 90 6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 25 91 7. Security of Initial Messages . . . . . . . . . . . . . . . . 27 92 8. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 28 93 8.1. Protocol and Version Negotiation . . . . . . . . . . . . 28 94 8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 28 95 8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 29 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 98 9.1. Packet Reflection Attack Mitigation . . . . . . . . . . . 29 99 9.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 30 100 9.3. Header Protection Analysis . . . . . . . . . . . . . . . 30 101 9.4. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 31 102 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 103 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 104 11.1. Normative References . . . . . . . . . . . . . . . . . . 32 105 11.2. Informative References . . . . . . . . . . . . . . . . . 33 106 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34 107 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 34 108 A.1. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 34 109 A.2. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 34 110 A.3. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 34 111 A.4. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 35 112 A.5. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 35 113 A.6. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 35 114 A.7. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 35 115 A.8. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 35 116 A.9. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 35 117 A.10. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 35 118 A.11. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 36 119 A.12. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 36 120 A.13. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 36 121 A.14. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 36 122 A.15. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 37 123 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 37 124 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 37 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 127 1. Introduction 129 This document describes how QUIC [QUIC-TRANSPORT] is secured using 130 TLS [TLS13]. 132 TLS 1.3 provides critical latency improvements for connection 133 establishment over previous versions. Absent packet loss, most new 134 connections can be established and secured within a single round 135 trip; on subsequent connections between the same client and server, 136 the client can often send application data immediately, that is, 137 using a zero round trip setup. 139 This document describes how TLS acts as a security component of QUIC. 141 2. Notational Conventions 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 This document uses the terminology established in [QUIC-TRANSPORT]. 151 For brevity, the acronym TLS is used to refer to TLS 1.3, though a 152 newer version could be used (see Section 4.2). 154 2.1. TLS Overview 156 TLS provides two endpoints with a way to establish a means of 157 communication over an untrusted medium (that is, the Internet) that 158 ensures that messages they exchange cannot be observed, modified, or 159 forged. 161 Internally, TLS is a layered protocol, with the structure shown 162 below: 164 +--------------+--------------+--------------+ 165 | Handshake | Alerts | Application | 166 | Layer | | Data | 167 | | | | 168 +--------------+--------------+--------------+ 169 | | 170 | Record Layer | 171 | | 172 +--------------------------------------------+ 174 Each upper layer (handshake, alerts, and application data) is carried 175 as a series of typed TLS records. Records are individually 176 cryptographically protected and then transmitted over a reliable 177 transport (typically TCP) which provides sequencing and guaranteed 178 delivery. 180 Change Cipher Spec records cannot be sent in QUIC. 182 The TLS authenticated key exchange occurs between two entities: 183 client and server. The client initiates the exchange and the server 184 responds. If the key exchange completes successfully, both client 185 and server will agree on a secret. TLS supports both pre-shared key 186 (PSK) and Diffie-Hellman (DH) key exchanges. PSK is the basis for 187 0-RTT; the latter provides perfect forward secrecy (PFS) when the DH 188 keys are destroyed. 190 After completing the TLS handshake, the client will have learned and 191 authenticated an identity for the server and the server is optionally 192 able to learn and authenticate an identity for the client. TLS 193 supports X.509 [RFC5280] certificate-based authentication for both 194 server and client. 196 The TLS key exchange is resistant to tampering by attackers and it 197 produces shared secrets that cannot be controlled by either 198 participating peer. 200 TLS provides two basic handshake modes of interest to QUIC: 202 o A full 1-RTT handshake in which the client is able to send 203 application data after one round trip and the server immediately 204 responds after receiving the first handshake message from the 205 client. 207 o A 0-RTT handshake in which the client uses information it has 208 previously learned about the server to send application data 209 immediately. This application data can be replayed by an attacker 210 so it MUST NOT carry a self-contained trigger for any non- 211 idempotent action. 213 A simplified TLS handshake with 0-RTT application data is shown in 214 Figure 1. Note that this omits the EndOfEarlyData message, which is 215 not used in QUIC (see Section 8.3). 217 Client Server 219 ClientHello 220 (0-RTT Application Data) --------> 221 ServerHello 222 {EncryptedExtensions} 223 {Finished} 224 <-------- [Application Data] 225 {Finished} --------> 227 [Application Data] <-------> [Application Data] 229 () Indicates messages protected by early data (0-RTT) keys 230 {} Indicates messages protected using handshake keys 231 [] Indicates messages protected using application data 232 (1-RTT) keys 234 Figure 1: TLS Handshake with 0-RTT 236 Data is protected using a number of encryption levels: 238 o Plaintext 240 o Early Data (0-RTT) Keys 242 o Handshake Keys 244 o Application Data (1-RTT) Keys 246 Application data may appear only in the early data and application 247 data levels. Handshake and Alert messages may appear in any level. 249 The 0-RTT handshake is only possible if the client and server have 250 previously communicated. In the 1-RTT handshake, the client is 251 unable to send protected application data until it has received all 252 of the handshake messages sent by the server. 254 3. Protocol Overview 256 QUIC [QUIC-TRANSPORT] assumes responsibility for the confidentiality 257 and integrity protection of packets. For this it uses keys derived 258 from a TLS handshake [TLS13], but instead of carrying TLS records 259 over QUIC (as with TCP), TLS Handshake and Alert messages are carried 260 directly over the QUIC transport, which takes over the 261 responsibilities of the TLS record layer, as shown below. 263 +--------------+--------------+ +-------------+ 264 | TLS | TLS | | QUIC | 265 | Handshake | Alerts | | Applications| 266 | | | | (h2q, etc.) | 267 +--------------+--------------+-+-------------+ 268 | | 269 | QUIC Transport | 270 | (streams, reliability, congestion, etc.) | 271 | | 272 +---------------------------------------------+ 273 | | 274 | QUIC Packet Protection | 275 | | 276 +---------------------------------------------+ 278 QUIC also relies on TLS for authentication and negotiation of 279 parameters that are critical to security and performance. 281 Rather than a strict layering, these two protocols are co-dependent: 282 QUIC uses the TLS handshake; TLS uses the reliability, ordered 283 delivery, and record layer provided by QUIC. 285 At a high level, there are two main interactions between the TLS and 286 QUIC components: 288 o The TLS component sends and receives messages via the QUIC 289 component, with QUIC providing a reliable stream abstraction to 290 TLS. 292 o The TLS component provides a series of updates to the QUIC 293 component, including (a) new packet protection keys to install (b) 294 state changes such as handshake completion, the server 295 certificate, etc. 297 Figure 2 shows these interactions in more detail, with the QUIC 298 packet protection being called out specially. 300 +------------+ +------------+ 301 | |<- Handshake Messages ->| | 302 | |<---- 0-RTT Keys -------| | 303 | |<--- Handshake Keys-----| | 304 | QUIC |<---- 1-RTT Keys -------| TLS | 305 | |<--- Handshake Done ----| | 306 +------------+ +------------+ 307 | ^ 308 | Protect | Protected 309 v | Packet 310 +------------+ 311 | QUIC | 312 | Packet | 313 | Protection | 314 +------------+ 316 Figure 2: QUIC and TLS Interactions 318 Unlike TLS over TCP, QUIC applications which want to send data do not 319 send it through TLS "application_data" records. Rather, they send it 320 as QUIC STREAM frames which are then carried in QUIC packets. 322 4. Carrying TLS Messages 324 QUIC carries TLS handshake data in CRYPTO frames, each of which 325 consists of a contiguous block of handshake data identified by an 326 offset and length. Those frames are packaged into QUIC packets and 327 encrypted under the current TLS encryption level. As with TLS over 328 TCP, once TLS handshake data has been delivered to QUIC, it is QUIC's 329 responsibility to deliver it reliably. Each chunk of data that is 330 produced by TLS is associated with the set of keys that TLS is 331 currently using. If QUIC needs to retransmit that data, it MUST use 332 the same keys even if TLS has already updated to newer keys. 334 One important difference between TLS records (used with TCP) and QUIC 335 CRYPTO frames is that in QUIC multiple frames may appear in the same 336 QUIC packet as long as they are associated with the same encryption 337 level. For instance, an implementation might bundle a Handshake 338 message and an ACK for some Handshake data into the same packet. 340 Each encryption level has a specific list of frames which may appear 341 in it. The rules here generalize those of TLS, in that frames 342 associated with establishing the connection can usually appear at any 343 encryption level, whereas those associated with transferring data can 344 only appear in the 0-RTT and 1-RTT encryption levels: 346 o CRYPTO frames MAY appear in packets of any encryption level except 347 0-RTT. 349 o CONNECTION_CLOSE MAY appear in packets of any encryption level 350 other than 0-RTT. 352 o PADDING frames MAY appear in packets of any encryption level. 354 o ACK frames MAY appear in packets of any encryption level other 355 than 0-RTT, but can only acknowledge packets which appeared in 356 that packet number space. 358 o STREAM frames MUST ONLY appear in the 0-RTT and 1-RTT levels. 360 o All other frame types MUST only appear at the 1-RTT levels. 362 Because packets could be reordered on the wire, QUIC uses the packet 363 type to indicate which level a given packet was encrypted under, as 364 shown in Table 1. When multiple packets of different encryption 365 levels need to be sent, endpoints SHOULD use coalesced packets to 366 send them in the same UDP datagram. 368 +-----------------+------------------+-----------+ 369 | Packet Type | Encryption Level | PN Space | 370 +-----------------+------------------+-----------+ 371 | Initial | Initial secrets | Initial | 372 | | | | 373 | 0-RTT Protected | 0-RTT | 0/1-RTT | 374 | | | | 375 | Handshake | Handshake | Handshake | 376 | | | | 377 | Retry | N/A | N/A | 378 | | | | 379 | Short Header | 1-RTT | 0/1-RTT | 380 +-----------------+------------------+-----------+ 382 Table 1: Encryption Levels by Packet Type 384 Section 17 of [QUIC-TRANSPORT] shows how packets at the various 385 encryption levels fit into the handshake process. 387 4.1. Interface to TLS 389 As shown in Figure 2, the interface from QUIC to TLS consists of 390 three primary functions: 392 o Sending and receiving handshake messages 394 o Rekeying (both transmit and receive) 396 o Handshake state updates 398 Additional functions might be needed to configure TLS. 400 4.1.1. Sending and Receiving Handshake Messages 402 In order to drive the handshake, TLS depends on being able to send 403 and receive handshake messages. There are two basic functions on 404 this interface: one where QUIC requests handshake messages and one 405 where QUIC provides handshake packets. 407 Before starting the handshake QUIC provides TLS with the transport 408 parameters (see Section 8.2) that it wishes to carry. 410 A QUIC client starts TLS by requesting TLS handshake bytes from TLS. 411 The client acquires handshake bytes before sending its first packet. 412 A QUIC server starts the process by providing TLS with the client's 413 handshake bytes. 415 At any given time, the TLS stack at an endpoint will have a current 416 sending encryption level and receiving encryption level. Each 417 encryption level is associated with a different flow of bytes, which 418 is reliably transmitted to the peer in CRYPTO frames. When TLS 419 provides handshake bytes to be sent, they are appended to the current 420 flow and any packet that includes the CRYPTO frame is protected using 421 keys from the corresponding encryption level. 423 QUIC takes the unprotected content of TLS handshake records as the 424 content of CRYPTO frames. TLS record protection is not used by QUIC. 425 QUIC assembles CRYPTO frames into QUIC packets, which are protected 426 using QUIC packet protection. 428 When an endpoint receives a QUIC packet containing a CRYPTO frame 429 from the network, it proceeds as follows: 431 o If the packet was in the TLS receiving encryption level, sequence 432 the data into the input flow as usual. As with STREAM frames, the 433 offset is used to find the proper location in the data sequence. 434 If the result of this process is that new data is available, then 435 it is delivered to TLS in order. 437 o If the packet is from a previously installed encryption level, it 438 MUST not contain data which extends past the end of previously 439 received data in that flow. Implementations MUST treat any 440 violations of this requirement as a connection error of type 441 PROTOCOL_VIOLATION. 443 o If the packet is from a new encryption level, it is saved for 444 later processing by TLS. Once TLS moves to receiving from this 445 encryption level, saved data can be provided. When providing data 446 from any new encryption level to TLS, if there is data from a 447 previous encryption level that TLS has not consumed, this MUST be 448 treated as a connection error of type PROTOCOL_VIOLATION. 450 Each time that TLS is provided with new data, new handshake bytes are 451 requested from TLS. TLS might not provide any bytes if the handshake 452 messages it has received are incomplete or it has no data to send. 454 Once the TLS handshake is complete, this is indicated to QUIC along 455 with any final handshake bytes 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 in CRYPTO streams. In the same way that is 468 done during the handshake, new data is requested from TLS after 469 providing 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 CRYPTO frame that carries the 482 Finished message in multiple packets. This enables immediate 483 server processing for those packets. 485 4.1.2. Encryption Level Changes 487 As keys for new encryption levels become available, TLS provides QUIC 488 with those keys. Separately, as TLS starts using keys at a given 489 encryption level, TLS indicates to QUIC that it is now reading or 490 writing with keys at that encryption level. These events are not 491 asynchronous; they always occur immediately after TLS is provided 492 with new handshake bytes, or after TLS produces handshake bytes. 494 TLS provides QUIC with three items as a new encryption level becomes 495 available: 497 o A secret 499 o An Authenticated Encryption with Associated Data (AEAD) function 501 o A Key Derivation Function (KDF) 503 These values are based on the values that TLS negotiates and are used 504 by QUIC to generate packet and header protection keys (see Section 5 505 and Section 5.4). 507 If 0-RTT is possible, it is ready after the client sends a TLS 508 ClientHello message or the server receives that message. After 509 providing a QUIC client with the first handshake bytes, the TLS stack 510 might signal the change to 0-RTT keys. On the server, after 511 receiving handshake bytes that contain a ClientHello message, a TLS 512 server might signal that 0-RTT keys are available. 514 Although TLS only uses one encryption level at a time, QUIC may use 515 more than one level. For instance, after sending its Finished 516 message (using a CRYPTO frame at the Handshake encryption level) an 517 endpoint can send STREAM data (in 1-RTT encryption). If the Finished 518 message is lost, the endpoint uses the Handshake encryption level to 519 retransmit the lost message. Reordering or loss of packets can mean 520 that QUIC will need to handle packets at multiple encryption levels. 521 During the handshake, this means potentially handling packets at 522 higher and lower encryption levels than the current encryption level 523 used by TLS. 525 In particular, server implementations need to be able to read packets 526 at the Handshake encryption level at the same time as the 0-RTT 527 encryption level. A client could interleave ACK frames that are 528 protected with Handshake keys with 0-RTT data and the server needs to 529 process those acknowledgments in order to detect lost Handshake 530 packets. 532 4.1.3. TLS Interface Summary 534 Figure 3 summarizes the exchange between QUIC and TLS for both client 535 and server. Each arrow is tagged with the encryption level used for 536 that transmission. 538 Client Server 540 Get Handshake 541 Initial -------------> 542 Rekey tx to 0-RTT Keys 543 0-RTT ---------------> 544 Handshake Received 545 Get Handshake 546 <------------- Initial 547 Rekey rx to 0-RTT keys 548 Handshake Received 549 Rekey rx to Handshake keys 550 Get Handshake 551 <----------- Handshake 552 Rekey tx to 1-RTT keys 553 <--------------- 1-RTT 554 Handshake Received 555 Rekey rx to Handshake keys 556 Handshake Received 557 Get Handshake 558 Handshake Complete 559 Handshake -----------> 560 Rekey tx to 1-RTT keys 561 1-RTT ---------------> 562 Handshake Received 563 Rekey rx to 1-RTT keys 564 Get Handshake 565 Handshake Complete 566 <--------------- 1-RTT 567 Handshake Received 569 Figure 3: Interaction Summary between QUIC and TLS 571 4.2. TLS Version 573 This document describes how TLS 1.3 [TLS13] is used with QUIC. 575 In practice, the TLS handshake will negotiate a version of TLS to 576 use. This could result in a newer version of TLS than 1.3 being 577 negotiated if both endpoints support that version. This is 578 acceptable provided that the features of TLS 1.3 that are used by 579 QUIC are supported by the newer version. 581 A badly configured TLS implementation could negotiate TLS 1.2 or 582 another older version of TLS. An endpoint MUST terminate the 583 connection if a version of TLS older than 1.3 is negotiated. 585 4.3. ClientHello Size 587 QUIC requires that the first Initial packet from a client contain an 588 entire cryptographic handshake message, which for TLS is the 589 ClientHello. Though a packet larger than 1200 bytes might be 590 supported by the path, a client improves the likelihood that a packet 591 is accepted if it ensures that the first ClientHello message is small 592 enough to stay within this limit. 594 QUIC packet and framing add at least 36 bytes of overhead to the 595 ClientHello message. That overhead increases if the client chooses a 596 connection ID without zero length. Overheads also do not include the 597 token or a connection ID longer than 8 bytes, both of which might be 598 required if a server sends a Retry packet. 600 A typical TLS ClientHello can easily fit into a 1200 byte packet. 601 However, in addition to the overheads added by QUIC, there are 602 several variables that could cause this limit to be exceeded. Large 603 session tickets, multiple or large key shares, and long lists of 604 supported ciphers, signature algorithms, versions, QUIC transport 605 parameters, and other negotiable parameters and extensions could 606 cause this message to grow. 608 For servers, in addition to connection IDs and tokens, the size of 609 TLS session tickets can have an effect on a client's ability to 610 connect. Minimizing the size of these values increases the 611 probability that they can be successfully used by a client. 613 A client is not required to fit the ClientHello that it sends in 614 response to a HelloRetryRequest message into a single UDP datagram. 616 The TLS implementation does not need to ensure that the ClientHello 617 is sufficiently large. QUIC PADDING frames are added to increase the 618 size of the packet as necessary. 620 4.4. Peer Authentication 622 The requirements for authentication depend on the application 623 protocol that is in use. TLS provides server authentication and 624 permits the server to request client authentication. 626 A client MUST authenticate the identity of the server. This 627 typically involves verification that the identity of the server is 628 included in a certificate and that the certificate is issued by a 629 trusted entity (see for example [RFC2818]). 631 A server MAY request that the client authenticate during the 632 handshake. A server MAY refuse a connection if the client is unable 633 to authenticate when requested. The requirements for client 634 authentication vary based on application protocol and deployment. 636 A server MUST NOT use post-handshake client authentication (see 637 Section 4.6.2 of [TLS13]). 639 4.5. Enabling 0-RTT 641 In order to be usable for 0-RTT, TLS MUST provide a NewSessionTicket 642 message that contains the "max_early_data" extension with the value 643 0xffffffff; the amount of data which the client can send in 0-RTT is 644 controlled by the "initial_max_data" transport parameter supplied by 645 the server. A client MUST treat receipt of a NewSessionTicket that 646 contains a "max_early_data" extension with any other value as a 647 connection error of type PROTOCOL_VIOLATION. 649 Early data within the TLS connection MUST NOT be used. As it is for 650 other TLS application data, a server MUST treat receiving early data 651 on the TLS connection as a connection error of type 652 PROTOCOL_VIOLATION. 654 4.6. Rejecting 0-RTT 656 A server rejects 0-RTT by rejecting 0-RTT at the TLS layer. This 657 also prevents QUIC from sending 0-RTT data. A server will always 658 reject 0-RTT if it sends a TLS HelloRetryRequest. 660 When 0-RTT is rejected, all connection characteristics that the 661 client assumed might be incorrect. This includes the choice of 662 application protocol, transport parameters, and any application 663 configuration. The client therefore MUST reset the state of all 664 streams, including application state bound to those streams. 666 A client MAY attempt to send 0-RTT again if it receives a Retry or 667 Version Negotiation packet. These packets do not signify rejection 668 of 0-RTT. 670 4.7. HelloRetryRequest 672 In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of 673 [TLS13]) can be used to correct a client's incorrect KeyShare 674 extension as well as for a stateless round-trip check. From the 675 perspective of QUIC, this just looks like additional messages carried 676 in the Initial encryption level. Although it is in principle 677 possible to use this feature for address verification in QUIC, QUIC 678 implementations SHOULD instead use the Retry feature (see Section 8.1 679 of [QUIC-TRANSPORT]). HelloRetryRequest is still used to request key 680 shares. 682 4.8. TLS Errors 684 If TLS experiences an error, it generates an appropriate alert as 685 defined in Section 6 of [TLS13]. 687 A TLS alert is turned into a QUIC connection error by converting the 688 one-byte alert description into a QUIC error code. The alert 689 description is added to 0x100 to produce a QUIC error code from the 690 range reserved for CRYPTO_ERROR. The resulting value is sent in a 691 QUIC CONNECTION_CLOSE frame. 693 The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT 694 generate alerts at the "warning" level. 696 4.9. Discarding Unused Keys 698 After QUIC moves to a new encryption level, packet protection keys 699 for previous encryption levels can be discarded. This occurs several 700 times during the handshake, as well as when keys are updated (see 701 Section 6). Initial packet protection keys are treated specially, 702 see Section 4.10. 704 Packet protection keys are not discarded immediately when new keys 705 are available. If packets from a lower encryption level contain 706 CRYPTO frames, frames that retransmit that data MUST be sent at the 707 same encryption level. Similarly, an endpoint generates 708 acknowledgements for packets at the same encryption level as the 709 packet being acknowledged. Thus, it is possible that keys for a 710 lower encryption level are needed for a short time after keys for a 711 newer encryption level are available. 713 An endpoint cannot discard keys for a given encryption level unless 714 it has both received and acknowledged all CRYPTO frames for that 715 encryption level and when all CRYPTO frames for that encryption level 716 have been acknowledged by its peer. However, this does not guarantee 717 that no further packets will need to be received or sent at that 718 encryption level because a peer might not have received all the 719 acknowledgements necessary to reach the same state. 721 After all CRYPTO frames for a given encryption level have been sent 722 and all expected CRYPTO frames received, and all the corresponding 723 acknowledgments have been received or sent, an endpoint starts a 724 timer. For 0-RTT keys, which do not carry CRYPTO frames, this timer 725 starts when the first packets protected with 1-RTT are sent or 726 received. To limit the effect of packet loss around a change in 727 keys, endpoints MUST retain packet protection keys for that 728 encryption level for at least three times the current Retransmission 729 Timeout (RTO) interval as defined in [QUIC-RECOVERY]. Retaining keys 730 for this interval allows packets containing CRYPTO or ACK frames at 731 that encryption level to be sent if packets are determined to be lost 732 or new packets require acknowledgment. 734 Though an endpoint might retain older keys, new data MUST be sent at 735 the highest currently-available encryption level. Only ACK frames 736 and retransmissions of data in CRYPTO frames are sent at a previous 737 encryption level. These packets MAY also include PADDING frames. 739 Once this timer expires, an endpoint MUST NOT either accept or 740 generate new packets using those packet protection keys. An endpoint 741 can discard packet protection keys for that encryption level. 743 Key updates (see Section 6) can be used to update 1-RTT keys before 744 keys from other encryption levels are discarded. In that case, 745 packets protected with the newest packet protection keys and packets 746 sent two updates prior will appear to use the same keys. After the 747 handshake is complete, endpoints only need to maintain the two latest 748 sets of packet protection keys and MAY discard older keys. Updating 749 keys multiple times rapidly can cause packets to be effectively lost 750 if packets are significantly delayed. Because key updates can only 751 be performed once per round trip time, only packets that are delayed 752 by more than a round trip will be lost as a result of changing keys; 753 such packets will be marked as lost before this, as they leave a gap 754 in the sequence of packet numbers. 756 4.10. Discarding Initial Keys 758 Packets protected with Initial secrets (Section 5.2) are not 759 authenticated, meaning that an attacker could spoof packets with the 760 intent to disrupt a connection. To limit these attacks, Initial 761 packet protection keys can be discarded more aggressively than other 762 keys. 764 The successful use of Handshake packets indicates that no more 765 Initial packets need to be exchanged, as these keys can only be 766 produced after receiving all CRYPTO frames from Initial packets. 767 Thus, a client MUST discard Initial keys when it first sends a 768 Handshake packet and a server MUST discard Initial keys when it first 769 successfully processes a Handshake packet. Endpoints MUST NOT send 770 Initial packets after this point. 772 This results in abandoning loss recovery state for the Initial 773 encryption level and ignoring any outstanding Initial packets. 775 5. Packet Protection 777 As with TLS over TCP, QUIC protects packets with keys derived from 778 the TLS handshake, using the AEAD algorithm negotiated by TLS. 780 5.1. Packet Protection Keys 782 QUIC derives packet protection keys in the same way that TLS derives 783 record protection keys. 785 Each encryption level has separate secret values for protection of 786 packets sent in each direction. These traffic secrets are derived by 787 TLS (see Section 7.1 of [TLS13]) and are used by QUIC for all 788 encryption levels except the Initial encryption level. The secrets 789 for the Initial encryption level are computed based on the client's 790 initial Destination Connection ID, as described in Section 5.2. 792 The keys used for packet protection are computed from the TLS secrets 793 using the KDF provided by TLS. In TLS 1.3, the HKDF-Expand-Label 794 function described in Section 7.1 of [TLS13]) is used, using the hash 795 function from the negotiated cipher suite. Other versions of TLS 796 MUST provide a similar function in order to be used QUIC. 798 The current encryption level secret and the label "quic key" are 799 input to the KDF to produce the AEAD key; the label "quic iv" is used 800 to derive the IV, see Section 5.3. The header protection key uses 801 the "quic hp" label, see Section 5.4). Using these labels provides 802 key separation between QUIC and TLS, see Section 9.4. 804 The KDF used for initial secrets is always the HKDF-Expand-Label 805 function from TLS 1.3 (see Section 5.2). 807 5.2. Initial Secrets 809 Initial packets are protected with a secret derived from the 810 Destination Connection ID field from the client's first Initial 811 packet of the connection. Specifically: 813 initial_salt = 0xef4fb0abb47470c41befcf8031334fae485e09a0 814 initial_secret = HKDF-Extract(initial_salt, 815 client_dst_connection_id) 817 client_initial_secret = HKDF-Expand-Label(initial_secret, 818 "client in", "", 819 Hash.length) 820 server_initial_secret = HKDF-Expand-Label(initial_secret, 821 "server in", "", 822 Hash.length) 824 The hash function for HKDF when deriving initial secrets and keys is 825 SHA-256 [SHA]. 827 The connection ID used with HKDF-Expand-Label is the Destination 828 Connection ID in the Initial packet sent by the client. This will be 829 a randomly-selected value unless the client creates the Initial 830 packet after receiving a Retry packet, where the Destination 831 Connection ID is selected by the server. 833 The value of initial_salt is a 20 byte sequence shown in the figure 834 in hexadecimal notation. Future versions of QUIC SHOULD generate a 835 new salt value, thus ensuring that the keys are different for each 836 version of QUIC. This prevents a middlebox that only recognizes one 837 version of QUIC from seeing or modifying the contents of handshake 838 packets from future versions. 840 The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for 841 Initial packets even where the TLS versions offered do not include 842 TLS 1.3. 844 Note: The Destination Connection ID is of arbitrary length, and it 845 could be zero length if the server sends a Retry packet with a 846 zero-length Source Connection ID field. In this case, the Initial 847 keys provide no assurance to the client that the server received 848 its packet; the client has to rely on the exchange that included 849 the Retry packet for that property. 851 5.3. AEAD Usage 853 The Authentication Encryption with Associated Data (AEAD) [AEAD] 854 function used for QUIC packet protection is the AEAD that is 855 negotiated for use with the TLS connection. For example, if TLS is 856 using the TLS_AES_128_GCM_SHA256, the AEAD_AES_128_GCM function is 857 used. 859 Packets are protected prior to applying header protection 860 (Section 5.4). The unprotected packet header is part of the 861 associated data (A). When removing packet protection, an endpoint 862 first removes the header protection. 864 All QUIC packets other than Version Negotiation and Retry packets are 865 protected with an AEAD algorithm [AEAD]. Prior to establishing a 866 shared secret, packets are protected with AEAD_AES_128_GCM and a key 867 derived from the destination connection ID in the client's first 868 Initial packet (see Section 5.2). This provides protection against 869 off-path attackers and robustness against QUIC version unaware 870 middleboxes, but not against on-path attackers. 872 QUIC can use any of the ciphersuites defined in [TLS13] with the 873 exception of TLS_AES_128_CCM_8_SHA256. The AEAD for that 874 ciphersuite, AEAD_AES_128_CCM_8 [CCM], does not produce a large 875 enough authentication tag for use with the header protection designs 876 provided (see Section 5.4). All other ciphersuites defined in 877 [TLS13] have a 16-byte authentication tag and produce an output 16 878 bytes larger than their input. 880 The key and IV for the packet are computed as described in 881 Section 5.1. The nonce, N, is formed by combining the packet 882 protection IV with the packet number. The 64 bits of the 883 reconstructed QUIC packet number in network byte order are left- 884 padded with zeros to the size of the IV. The exclusive OR of the 885 padded packet number and the IV forms the AEAD nonce. 887 The associated data, A, for the AEAD is the contents of the QUIC 888 header, starting from the flags byte in either the short or long 889 header, up to and including the unprotected packet number. 891 The input plaintext, P, for the AEAD is the payload of the QUIC 892 packet, as described in [QUIC-TRANSPORT]. 894 The output ciphertext, C, of the AEAD is transmitted in place of P. 896 Some AEAD functions have limits for how many packets can be encrypted 897 under the same key and IV (see for example [AEBounds]). This might 898 be lower than the packet number limit. An endpoint MUST initiate a 899 key update (Section 6) prior to exceeding any limit set for the AEAD 900 that is in use. 902 5.4. Header Protection 904 Parts of QUIC packet headers, in particular the Packet Number field, 905 are protected using a key that is derived separate to the packet 906 protection key and IV. The key derived using the "quic hp" label is 907 used to provide confidentiality protection for those fields that are 908 not exposed to on-path elements. 910 This protection applies to the least-significant bits of the first 911 byte, plus the Packet Number field. The four least-significant bits 912 of the first byte are protected for packets with long headers; the 913 five least significant bits of the first byte are protected for 914 packets with short headers. For both header forms, this covers the 915 reserved bits and the Packet Number Length field; the Key Phase bit 916 is also protected for packets with a short header. 918 The same header protection key is used for the duration of the 919 connection, with the value not changing after a key update (see 920 Section 6). This allows header protection to be used to protect the 921 key phase. 923 This process does not apply to Retry or Version Negotiation packets, 924 which do not contain a protected payload or any of the fields that 925 are protected by this process. 927 5.4.1. Header Protection Application 929 Header protection is applied after packet protection is applied (see 930 Section 5.3). The ciphertext of the packet is sampled and used as 931 input to an encryption algorithm. The algorithm used depends on the 932 negotiated AEAD. 934 The output of this algorithm is a 5 byte mask which is applied to the 935 protected header fields using exclusive OR. The least significant 936 bits of the first byte of the packet are masked by the least 937 significant bits of the first mask byte, and the packet number is 938 masked with the remaining bytes. Any unused bytes of mask that might 939 result from a shorter packet number encoding are unused. 941 Figure 4 shows a sample algorithm for applying header protection. 942 Removing header protection only differs in the order in which the 943 packet number length (pn_length) is determined. 945 mask = header_protection(hp_key, sample) 947 pn_length = (packet[0] & 0x03) + 1 948 if (packet[0] & 0x80) == 0x80: 949 # Long header: 4 bits masked 950 packet[0] ^= mask[0] & 0x0f 951 else: 952 # Short header: 5 bits masked 953 packet[0] ^= mask[0] & 0x1f 955 # pn_offset is the start of the Packet Number field. 956 packet[pn_offset:pn_offset+pn_length] ^= mask[1:1+pn_length] 958 Figure 4: Header Protection Pseudocode 960 Figure 5 shows the protected fields of long and short headers marked 961 with an E. Figure 5 also shows the sampled fields. 963 Long Header: 964 +-+-+-+-+-+-+-+-+ 965 |1|1|T T|E E E E| 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Version -> Length Fields ... 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 Short Header: 971 +-+-+-+-+-+-+-+-+ 972 |0|1|S|E E E E E| 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | Destination Connection ID (0/32..144) ... 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 Common Fields: 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 |E E E E E E E E E Packet Number (8/16/24/32) E E E E E E E E... 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | [Protected Payload (8/16/24)] ... 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | Sampled part of Protected Payload (128) ... 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | Protected Payload Remainder (*) ... 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 Figure 5: Header Protection and Ciphertext Sample 990 Before a TLS ciphersuite can be used with QUIC, a header protection 991 algorithm MUST be specified for the AEAD used with that ciphersuite. 992 This document defines algorithms for AEAD_AES_128_GCM, 993 AEAD_AES_128_CCM, AEAD_AES_256_GCM, AEAD_AES_256_CCM (all AES AEADs 994 are defined in [AEAD]), and AEAD_CHACHA20_POLY1305 [CHACHA]. Prior 995 to TLS selecting a ciphersuite, AES header protection is used 996 (Section 5.4.3), matching the AEAD_AES_128_GCM packet protection. 998 5.4.2. Header Protection Sample 1000 The header protection algorithm uses both the header protection key 1001 and a sample of the ciphertext from the packet Payload field. 1003 The same number of bytes are always sampled, but an allowance needs 1004 to be made for the endpoint removing protection, which will not know 1005 the length of the Packet Number field. In sampling the packet 1006 ciphertext, the Packet Number field is assumed to be 4 bytes long 1007 (its maximum possible encoded length). 1009 An endpoint MUST discard packets that are not long enough to contain 1010 a complete sample. 1012 To ensure that sufficient data is available for sampling, packets are 1013 padded so that the combined lengths of the encoded packet number and 1014 protected payload is at least 4 bytes longer than the sample required 1015 for header protection. For the AEAD functions defined in [TLS13], 1016 which have 16-byte expansions and 16-byte header protection samples, 1017 this results in needing at least 3 bytes of frames in the unprotected 1018 payload if the packet number is encoded on a single byte, or 2 bytes 1019 of frames for a 2-byte packet number encoding. 1021 The sampled ciphertext for a packet with a short header can be 1022 determined by the following pseudocode: 1024 sample_offset = 1 + len(connection_id) + 4 1026 sample = packet[sample_offset..sample_offset+sample_length] 1028 For example, for a packet with a short header, an 8 byte connection 1029 ID, and protected with AEAD_AES_128_GCM, the sample takes bytes 13 to 1030 28 inclusive (using zero-based indexing). 1032 A packet with a long header is sampled in the same way, noting that 1033 multiple QUIC packets might be included in the same UDP datagram and 1034 that each one is handled separately. 1036 sample_offset = 6 + len(destination_connection_id) + 1037 len(source_connection_id) + 1038 len(payload_length) + 4 1039 if packet_type == Initial: 1040 sample_offset += len(token_length) + 1041 len(token) 1043 sample = packet[sample_offset..sample_offset+sample_length] 1045 5.4.3. AES-Based Header Protection 1047 This section defines the packet protection algorithm for 1048 AEAD_AES_128_GCM, AEAD_AES_128_CCM, AEAD_AES_256_GCM, and 1049 AEAD_AES_256_CCM. AEAD_AES_128_GCM and AEAD_AES_128_CCM use 128-bit 1050 AES [AES] in electronic code-book (ECB) mode. AEAD_AES_256_GCM, and 1051 AEAD_AES_256_CCM use 256-bit AES in ECB mode. 1053 This algorithm samples 16 bytes from the packet ciphertext. This 1054 value is used as the counter input to AES-ECB. In pseudocode: 1056 mask = AES-ECB(pn_key, sample) 1058 5.4.4. ChaCha20-Based Header Protection 1060 When AEAD_CHACHA20_POLY1305 is in use, header protection uses the raw 1061 ChaCha20 function as defined in Section 2.4 of [CHACHA]. This uses a 1062 256-bit key and 16 bytes sampled from the packet protection output. 1064 The first 4 bytes of the sampled ciphertext are interpreted as a 1065 32-bit number in little-endian order and are used as the block count. 1066 The remaining 12 bytes are interpreted as three concatenated 32-bit 1067 numbers in little-endian order and used as the nonce. 1069 The encryption mask is produced by invoking ChaCha20 to protect 5 1070 zero bytes. In pseudocode: 1072 counter = DecodeLE(sample[0..3]) 1073 nonce = DecodeLE(sample[4..7], sample[8..11], sample[12..15]) 1074 mask = ChaCha20(pn_key, counter, nonce, {0,0,0,0,0}) 1076 5.5. Receiving Protected Packets 1078 Once an endpoint successfully receives a packet with a given packet 1079 number, it MUST discard all packets in the same packet number space 1080 with higher packet numbers if they cannot be successfully unprotected 1081 with either the same key, or - if there is a key update - the next 1082 packet protection key (see Section 6). Similarly, a packet that 1083 appears to trigger a key update, but cannot be unprotected 1084 successfully MUST be discarded. 1086 Failure to unprotect a packet does not necessarily indicate the 1087 existence of a protocol error in a peer or an attack. The truncated 1088 packet number encoding used in QUIC can cause packet numbers to be 1089 decoded incorrectly if they are delayed significantly. 1091 5.6. Use of 0-RTT Keys 1093 If 0-RTT keys are available (see Section 4.5), the lack of replay 1094 protection means that restrictions on their use are necessary to 1095 avoid replay attacks on the protocol. 1097 A client MUST only use 0-RTT keys to protect data that is idempotent. 1098 A client MAY wish to apply additional restrictions on what data it 1099 sends prior to the completion of the TLS handshake. A client 1100 otherwise treats 0-RTT keys as equivalent to 1-RTT keys, except that 1101 it MUST NOT send ACKs with 0-RTT keys. 1103 A client that receives an indication that its 0-RTT data has been 1104 accepted by a server can send 0-RTT data until it receives all of the 1105 server's handshake messages. A client SHOULD stop sending 0-RTT data 1106 if it receives an indication that 0-RTT data has been rejected. 1108 A server MUST NOT use 0-RTT keys to protect packets; it uses 1-RTT 1109 keys to protect acknowledgements of 0-RTT packets. A client MUST NOT 1110 attempt to decrypt 0-RTT packets it receives and instead MUST discard 1111 them. 1113 Note: 0-RTT data can be acknowledged by the server as it receives 1114 it, but any packets containing acknowledgments of 0-RTT data 1115 cannot have packet protection removed by the client until the TLS 1116 handshake is complete. The 1-RTT keys necessary to remove packet 1117 protection cannot be derived until the client receives all server 1118 handshake messages. 1120 5.7. Receiving Out-of-Order Protected Frames 1122 Due to reordering and loss, protected packets might be received by an 1123 endpoint before the final TLS handshake messages are received. A 1124 client will be unable to decrypt 1-RTT packets from the server, 1125 whereas a server will be able to decrypt 1-RTT packets from the 1126 client. 1128 However, a server MUST NOT process data from incoming 1-RTT protected 1129 packets before verifying either the client Finished message or - in 1130 the case that the server has chosen to use a pre-shared key - the 1131 pre-shared key binder (see Section 4.2.11 of [TLS13]). Verifying 1132 these values provides the server with an assurance that the 1133 ClientHello has not been modified. Packets protected with 1-RTT keys 1134 MAY be stored and later decrypted and used once the handshake is 1135 complete. 1137 A server could receive packets protected with 0-RTT keys prior to 1138 receiving a TLS ClientHello. The server MAY retain these packets for 1139 later decryption in anticipation of receiving a ClientHello. 1141 6. Key Update 1143 Once the 1-RTT keys are established and the short header is in use, 1144 it is possible to update the keys. The KEY_PHASE bit in the short 1145 header is used to indicate whether key updates have occurred. The 1146 KEY_PHASE bit is initially set to 0 and then inverted with each key 1147 update. 1149 The KEY_PHASE bit allows a recipient to detect a change in keying 1150 material without necessarily needing to receive the first packet that 1151 triggered the change. An endpoint that notices a changed KEY_PHASE 1152 bit can update keys and decrypt the packet that contains the changed 1153 bit. 1155 This mechanism replaces the TLS KeyUpdate message. Endpoints MUST 1156 NOT send a TLS KeyUpdate message. Endpoints MUST treat the receipt 1157 of a TLS KeyUpdate message as a connection error of type 0x10a, 1158 equivalent to a fatal TLS alert of unexpected_message (see 1159 Section 4.8). 1161 An endpoint MUST NOT initiate more than one key update at a time. A 1162 new key cannot be used until the endpoint has received and 1163 successfully decrypted a packet with a matching KEY_PHASE. 1165 A receiving endpoint detects an update when the KEY_PHASE bit does 1166 not match what it is expecting. It creates a new secret (see 1167 Section 7.2 of [TLS13]) and the corresponding read key and IV using 1168 the KDF function provided by TLS. The header protection key is not 1169 updated. 1171 If the packet can be decrypted and authenticated using the updated 1172 key and IV, then the keys the endpoint uses for packet protection are 1173 also updated. The next packet sent by the endpoint will then use the 1174 new keys. 1176 An endpoint does not always need to send packets when it detects that 1177 its peer has updated keys. The next packet that it sends will simply 1178 use the new keys. If an endpoint detects a second update before it 1179 has sent any packets with updated keys, it indicates that its peer 1180 has updated keys twice without awaiting a reciprocal update. An 1181 endpoint MUST treat consecutive key updates as a fatal error and 1182 abort the connection. 1184 An endpoint SHOULD retain old keys for a period of no more than three 1185 times the Probe Timeout (PTO, see [QUIC-RECOVERY]). After this 1186 period, old keys and their corresponding secrets SHOULD be discarded. 1187 Retaining keys allow endpoints to process packets that were sent with 1188 old keys and delayed in the network. Packets with higher packet 1189 numbers always use the updated keys and MUST NOT be decrypted with 1190 old keys. 1192 This ensures that once the handshake is complete, packets with the 1193 same KEY_PHASE will have the same packet protection keys, unless 1194 there are multiple key updates in a short time frame succession and 1195 significant packet reordering. 1197 Initiating Peer Responding Peer 1199 @M QUIC Frames 1200 New Keys -> @N 1201 @N QUIC Frames 1202 --------> 1203 QUIC Frames @M 1204 New Keys -> @N 1205 QUIC Frames @N 1206 <-------- 1208 Figure 6: Key Update 1210 A packet that triggers a key update could arrive after successfully 1211 processing a packet with a higher packet number. This is only 1212 possible if there is a key compromise and an attack, or if the peer 1213 is incorrectly reverting to use of old keys. Because the latter 1214 cannot be differentiated from an attack, an endpoint MUST immediately 1215 terminate the connection if it detects this condition. 1217 In deciding when to update keys, endpoints MUST NOT exceed the limits 1218 for use of specific keys, as described in Section 5.5 of [TLS13]. 1220 7. Security of Initial Messages 1222 Initial packets are not protected with a secret key, so they are 1223 subject to potential tampering by an attacker. QUIC provides 1224 protection against attackers that cannot read packets, but does not 1225 attempt to provide additional protection against attacks where the 1226 attacker can observe and inject packets. Some forms of tampering - 1227 such as modifying the TLS messages themselves - are detectable, but 1228 some - such as modifying ACKs - are not. 1230 For example, an attacker could inject a packet containing an ACK 1231 frame that makes it appear that a packet had not been received or to 1232 create a false impression of the state of the connection (e.g., by 1233 modifying the ACK Delay). Note that such a packet could cause a 1234 legitimate packet to be dropped as a duplicate. Implementations 1235 SHOULD use caution in relying on any data which is contained in 1236 Initial packets that is not otherwise authenticated. 1238 It is also possible for the attacker to tamper with data that is 1239 carried in Handshake packets, but because that tampering requires 1240 modifying TLS handshake messages, that tampering will cause the TLS 1241 handshake to fail. 1243 8. QUIC-Specific Additions to the TLS Handshake 1245 QUIC uses the TLS handshake for more than just negotiation of 1246 cryptographic parameters. The TLS handshake validates protocol 1247 version selection, provides preliminary values for QUIC transport 1248 parameters, and allows a server to perform return routeability checks 1249 on clients. 1251 8.1. Protocol and Version Negotiation 1253 The QUIC version negotiation mechanism is used to negotiate the 1254 version of QUIC that is used prior to the completion of the 1255 handshake. However, this packet is not authenticated, enabling an 1256 active attacker to force a version downgrade. 1258 To ensure that a QUIC version downgrade is not forced by an attacker, 1259 version information is copied into the TLS handshake, which provides 1260 integrity protection for the QUIC negotiation. This does not prevent 1261 version downgrade prior to the completion of the handshake, though it 1262 means that a downgrade causes a handshake failure. 1264 TLS uses Application Layer Protocol Negotiation (ALPN) [RFC7301] to 1265 select an application protocol. The application-layer protocol MAY 1266 restrict the QUIC versions that it can operate over. Servers MUST 1267 select an application protocol compatible with the QUIC version that 1268 the client has selected. 1270 If the server cannot select a compatible combination of application 1271 protocol and QUIC version, it MUST abort the connection. A client 1272 MUST abort a connection if the server picks an incompatible 1273 combination of QUIC version and ALPN identifier. 1275 8.2. QUIC Transport Parameters Extension 1277 QUIC transport parameters are carried in a TLS extension. Different 1278 versions of QUIC might define a different format for this struct. 1280 Including transport parameters in the TLS handshake provides 1281 integrity protection for these values. 1283 enum { 1284 quic_transport_parameters(0xffa5), (65535) 1285 } ExtensionType; 1287 The "extension_data" field of the quic_transport_parameters extension 1288 contains a value that is defined by the version of QUIC that is in 1289 use. The quic_transport_parameters extension carries a 1290 TransportParameters when the version of QUIC defined in 1291 [QUIC-TRANSPORT] is used. 1293 The quic_transport_parameters extension is carried in the ClientHello 1294 and the EncryptedExtensions messages during the handshake. 1296 While the transport parameters are technically available prior to the 1297 completion of the handshake, they cannot be fully trusted until the 1298 handshake completes, and reliance on them should be minimized. 1299 However, any tampering with the parameters will cause the handshake 1300 to fail. 1302 Endpoints MUST NOT send this extension in a TLS connection that does 1303 not use QUIC (such as the use of TLS with TCP defined in [TLS13]). A 1304 fatal unsupported_extension alert MUST be sent if this extension is 1305 received when the transport is not QUIC. 1307 8.3. Removing the EndOfEarlyData Message 1309 The TLS EndOfEarlyData message is not used with QUIC. QUIC does not 1310 rely on this message to mark the end of 0-RTT data or to signal the 1311 change to Handshake keys. 1313 Clients MUST NOT send the EndOfEarlyData message. A server MUST 1314 treat receipt of a CRYPTO frame in a 0-RTT packet as a connection 1315 error of type PROTOCOL_VIOLATION. 1317 As a result, EndOfEarlyData does not appear in the TLS handshake 1318 transcript. 1320 9. Security Considerations 1322 There are likely to be some real clangers here eventually, but the 1323 current set of issues is well captured in the relevant sections of 1324 the main text. 1326 Never assume that because it isn't in the security considerations 1327 section it doesn't affect security. Most of this document does. 1329 9.1. Packet Reflection Attack Mitigation 1331 A small ClientHello that results in a large block of handshake 1332 messages from a server can be used in packet reflection attacks to 1333 amplify the traffic generated by an attacker. 1335 QUIC includes three defenses against this attack. First, the packet 1336 containing a ClientHello MUST be padded to a minimum size. Second, 1337 if responding to an unverified source address, the server is 1338 forbidden to send more than three UDP datagrams in its first flight 1339 (see Section 8.1 of [QUIC-TRANSPORT]). Finally, because 1340 acknowledgements of Handshake packets are authenticated, a blind 1341 attacker cannot forge them. Put together, these defenses limit the 1342 level of amplification. 1344 9.2. Peer Denial of Service 1346 QUIC, TLS, and HTTP/2 all contain messages that have legitimate uses 1347 in some contexts, but that can be abused to cause a peer to expend 1348 processing resources without having any observable impact on the 1349 state of the connection. If processing is disproportionately large 1350 in comparison to the observable effects on bandwidth or state, then 1351 this could allow a malicious peer to exhaust processing capacity 1352 without consequence. 1354 QUIC prohibits the sending of empty "STREAM" frames unless they are 1355 marked with the FIN bit. This prevents "STREAM" frames from being 1356 sent that only waste effort. 1358 While there are legitimate uses for some redundant packets, 1359 implementations SHOULD track redundant packets and treat excessive 1360 volumes of any non-productive packets as indicative of an attack. 1362 9.3. Header Protection Analysis 1364 Header protection relies on the packet protection AEAD being a 1365 pseudorandom function (PRF), which is not a property that AEAD 1366 algorithms guarantee. Therefore, no strong assurances about the 1367 general security of this mechanism can be shown in the general case. 1368 The AEAD algorithms described in this document are assumed to be 1369 PRFs. 1371 The header protection algorithms defined in this document take the 1372 form: 1374 protected_field = field XOR PRF(pn_key, sample) 1376 This construction is secure against chosen plaintext attacks (IND- 1377 CPA) [IMC]. 1379 Use of the same key and ciphertext sample more than once risks 1380 compromising header protection. Protecting two different headers 1381 with the same key and ciphertext sample reveals the exclusive OR of 1382 the protected fields. Assuming that the AEAD acts as a PRF, if L 1383 bits are sampled, the odds of two ciphertext samples being identical 1384 approach 2^(-L/2), that is, the birthday bound. For the algorithms 1385 described in this document, that probability is one in 2^64. 1387 Note: In some cases, inputs shorter than the full size required by 1388 the packet protection algorithm might be used. 1390 To prevent an attacker from modifying packet headers, the header is 1391 transitively authenticated using packet protection; the entire packet 1392 header is part of the authenticated additional data. Protected 1393 fields that are falsified or modified can only be detected once the 1394 packet protection is removed. 1396 An attacker could guess values for packet numbers and have an 1397 endpoint confirm guesses through timing side channels. Similarly, 1398 guesses for the packet number length can be trialed and exposed. If 1399 the recipient of a packet discards packets with duplicate packet 1400 numbers without attempting to remove packet protection they could 1401 reveal through timing side-channels that the packet number matches a 1402 received packet. For authentication to be free from side-channels, 1403 the entire process of header protection removal, packet number 1404 recovery, and packet protection removal MUST be applied together 1405 without timing and other side-channels. 1407 For the sending of packets, construction and protection of packet 1408 payloads and packet numbers MUST be free from side-channels that 1409 would reveal the packet number or its encoded size. 1411 9.4. Key Diversity 1413 In using TLS, the central key schedule of TLS is used. As a result 1414 of the TLS handshake messages being integrated into the calculation 1415 of secrets, the inclusion of the QUIC transport parameters extension 1416 ensures that handshake and 1-RTT keys are not the same as those that 1417 might be produced by a server running TLS over TCP. However, 0-RTT 1418 keys only include the ClientHello message and might therefore use the 1419 same secrets. To avoid the possibility of cross-protocol key 1420 synchronization, additional measures are provided to improve key 1421 separation. 1423 The QUIC packet protection keys and IVs are derived using a different 1424 label than the equivalent keys in TLS. 1426 To preserve this separation, a new version of QUIC SHOULD define new 1427 labels for key derivation for packet protection key and IV, plus the 1428 packet number protection keys. 1430 The initial secrets also use a key that is specific to the negotiated 1431 QUIC version. New QUIC versions SHOULD define a new salt value used 1432 in calculating initial secrets. 1434 10. IANA Considerations 1436 This document does not create any new IANA registries, but it 1437 registers the values in the following registries: 1439 o TLS ExtensionsType Registry [TLS-REGISTRIES] - IANA is to register 1440 the quic_transport_parameters extension found in Section 8.2. The 1441 Recommended column is to be marked Yes. The TLS 1.3 Column is to 1442 include CH and EE. 1444 11. References 1446 11.1. Normative References 1448 [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated 1449 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1450 . 1452 [AES] "Advanced encryption standard (AES)", National Institute 1453 of Standards and Technology report, 1454 DOI 10.6028/nist.fips.197, November 2001. 1456 [CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 1457 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, 1458 . 1460 [QUIC-RECOVERY] 1461 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 1462 and Congestion Control", draft-ietf-quic-recovery-17 (work 1463 in progress), December 2018. 1465 [QUIC-TRANSPORT] 1466 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1467 Multiplexed and Secure Transport", draft-ietf-quic- 1468 transport-17 (work in progress), December 2018. 1470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1471 Requirement Levels", BCP 14, RFC 2119, 1472 DOI 10.17487/RFC2119, March 1997, 1473 . 1475 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1476 "Transport Layer Security (TLS) Application-Layer Protocol 1477 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1478 July 2014, . 1480 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1481 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1482 May 2017, . 1484 [SHA] Dang, Q., "Secure Hash Standard", National Institute of 1485 Standards and Technology report, 1486 DOI 10.6028/nist.fips.180-4, July 2015. 1488 [TLS-REGISTRIES] 1489 Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1490 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 1491 . 1493 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1494 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1495 . 1497 11.2. Informative References 1499 [AEBounds] 1500 Luykx, A. and K. Paterson, "Limits on Authenticated 1501 Encryption Use in TLS", March 2016, 1502 . 1504 [CCM] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 1505 Transport Layer Security (TLS)", RFC 6655, 1506 DOI 10.17487/RFC6655, July 2012, 1507 . 1509 [IMC] Katz, J. and Y. Lindell, "Introduction to Modern 1510 Cryptography, Second Edition", ISBN 978-1466570269, 1511 November 2014. 1513 [QUIC-HTTP] 1514 Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over 1515 QUIC", draft-ietf-quic-http-17 (work in progress), 1516 December 2018. 1518 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1519 DOI 10.17487/RFC2818, May 2000, 1520 . 1522 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1523 Housley, R., and W. Polk, "Internet X.509 Public Key 1524 Infrastructure Certificate and Certificate Revocation List 1525 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1526 . 1528 11.3. URIs 1530 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 1532 [2] https://github.com/quicwg 1534 [3] https://github.com/quicwg/base-drafts/labels/-tls 1536 Appendix A. Change Log 1538 *RFC Editor's Note:* Please remove this section prior to 1539 publication of a final version of this document. 1541 Issue and pull request numbers are listed with a leading octothorp. 1543 A.1. Since draft-ietf-quic-tls-14 1545 o Update the salt used for Initial secrets (#1970) 1547 o Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019) 1549 o Change header protection 1551 * Sample from a fixed offset (#1575, #2030) 1553 * Cover part of the first byte, including the key phase (#1322, 1554 #2006) 1556 o TLS provides an AEAD and KDF function (#2046) 1558 * Clarify that the TLS KDF is used with TLS (#1997) 1560 * Change the labels for calculation of QUIC keys (#1845, #1971, 1561 #1991) 1563 o Initial keys are discarded once Handshake are avaialble (#1951, 1564 #2045) 1566 A.2. Since draft-ietf-quic-tls-13 1568 o Updated to TLS 1.3 final (#1660) 1570 A.3. Since draft-ietf-quic-tls-12 1572 o Changes to integration of the TLS handshake (#829, #1018, #1094, 1573 #1165, #1190, #1233, #1242, #1252, #1450) 1575 * The cryptographic handshake uses CRYPTO frames, not stream 0 1576 * QUIC packet protection is used in place of TLS record 1577 protection 1579 * Separate QUIC packet number spaces are used for the handshake 1581 * Changed Retry to be independent of the cryptographic handshake 1583 * Limit the use of HelloRetryRequest to address TLS needs (like 1584 key shares) 1586 o Changed codepoint of TLS extension (#1395, #1402) 1588 A.4. Since draft-ietf-quic-tls-11 1590 o Encrypted packet numbers. 1592 A.5. Since draft-ietf-quic-tls-10 1594 o No significant changes. 1596 A.6. Since draft-ietf-quic-tls-09 1598 o Cleaned up key schedule and updated the salt used for handshake 1599 packet protection (#1077) 1601 A.7. Since draft-ietf-quic-tls-08 1603 o Specify value for max_early_data_size to enable 0-RTT (#942) 1605 o Update key derivation function (#1003, #1004) 1607 A.8. Since draft-ietf-quic-tls-07 1609 o Handshake errors can be reported with CONNECTION_CLOSE (#608, 1610 #891) 1612 A.9. Since draft-ietf-quic-tls-05 1614 No significant changes. 1616 A.10. Since draft-ietf-quic-tls-04 1618 o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) 1620 A.11. Since draft-ietf-quic-tls-03 1622 No significant changes. 1624 A.12. Since draft-ietf-quic-tls-02 1626 o Updates to match changes in transport draft 1628 A.13. Since draft-ietf-quic-tls-01 1630 o Use TLS alerts to signal TLS errors (#272, #374) 1632 o Require ClientHello to fit in a single packet (#338) 1634 o The second client handshake flight is now sent in the clear (#262, 1635 #337) 1637 o The QUIC header is included as AEAD Associated Data (#226, #243, 1638 #302) 1640 o Add interface necessary for client address validation (#275) 1642 o Define peer authentication (#140) 1644 o Require at least TLS 1.3 (#138) 1646 o Define transport parameters as a TLS extension (#122) 1648 o Define handling for protected packets before the handshake 1649 completes (#39) 1651 o Decouple QUIC version and ALPN (#12) 1653 A.14. Since draft-ietf-quic-tls-00 1655 o Changed bit used to signal key phase 1657 o Updated key phase markings during the handshake 1659 o Added TLS interface requirements section 1661 o Moved to use of TLS exporters for key derivation 1663 o Moved TLS error code definitions into this document 1665 A.15. Since draft-thomson-quic-tls-01 1667 o Adopted as base for draft-ietf-quic-tls 1669 o Updated authors/editors list 1671 o Added status note 1673 Acknowledgments 1675 This document has benefited from input from Dragana Damjanovic, 1676 Christian Huitema, Jana Iyengar, Adam Langley, Roberto Peon, Eric 1677 Rescorla, Ian Swett, and many others. 1679 Contributors 1681 Ryan Hamilton was originally an author of this specification. 1683 Authors' Addresses 1685 Martin Thomson (editor) 1686 Mozilla 1688 Email: martin.thomson@gmail.com 1690 Sean Turner (editor) 1691 sn3rd 1693 Email: sean@sn3rd.com