idnits 2.17.1 draft-ietf-quic-tls-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 28, 2016) is 2706 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-18 -- Possible downref: Non-RFC (?) normative reference: ref. 'QUIC-RECOVERY' -- Possible downref: Non-RFC (?) normative reference: ref. 'QUIC-TRANSPORT' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 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, Ed. 5 Expires: June 1, 2017 sn3rd 6 November 28, 2016 8 Using Transport Layer Security (TLS) to Secure QUIC 9 draft-ietf-quic-tls-00 11 Abstract 13 This document describes how Transport Layer Security (TLS) can be 14 used to secure QUIC. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on June 1, 2017. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 52 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Handshake Overview . . . . . . . . . . . . . . . . . . . 4 54 3. TLS in Stream 1 . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.1. Handshake and Setup Sequence . . . . . . . . . . . . . . 6 56 4. QUIC Packet Protection . . . . . . . . . . . . . . . . . . . 8 57 4.1. Key Phases . . . . . . . . . . . . . . . . . . . . . . . 8 58 4.1.1. Retransmission of TLS Handshake Messages . . . . . . 10 59 4.1.2. Distinguishing 0-RTT and 1-RTT Packets . . . . . . . 10 60 4.2. QUIC Key Expansion . . . . . . . . . . . . . . . . . . . 10 61 4.2.1. 0-RTT Secret . . . . . . . . . . . . . . . . . . . . 11 62 4.2.2. 1-RTT Secrets . . . . . . . . . . . . . . . . . . . . 11 63 4.2.3. Packet Protection Key and IV . . . . . . . . . . . . 12 64 4.3. QUIC AEAD Usage . . . . . . . . . . . . . . . . . . . . . 13 65 4.4. Key Update . . . . . . . . . . . . . . . . . . . . . . . 14 66 4.5. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 15 67 5. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 16 68 5.1. Unprotected Frames Prior to Handshake Completion . . . . 17 69 5.1.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 17 70 5.1.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 17 71 5.1.3. WINDOW_UPDATE Frames . . . . . . . . . . . . . . . . 17 72 5.1.4. Denial of Service with Unprotected Packets . . . . . 18 73 5.2. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 19 74 5.3. Protected Frames Prior to Handshake Completion . . . . . 19 75 6. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 20 76 6.1. Protocol and Version Negotiation . . . . . . . . . . . . 20 77 6.2. QUIC Extension . . . . . . . . . . . . . . . . . . . . . 21 78 6.3. Source Address Validation . . . . . . . . . . . . . . . . 21 79 6.4. Priming 0-RTT . . . . . . . . . . . . . . . . . . . . . . 21 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 81 7.1. Packet Reflection Attack Mitigation . . . . . . . . . . . 22 82 7.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 23 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 86 9.2. Informative References . . . . . . . . . . . . . . . . . 24 87 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 25 88 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 25 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 91 1. Introduction 93 QUIC [QUIC-TRANSPORT] provides a multiplexed transport. When used 94 for HTTP [RFC7230] semantics [QUIC-HTTP] it provides several key 95 advantages over HTTP/1.1 [RFC7230] or HTTP/2 [RFC7540] over TCP 96 [RFC0793]. 98 This document describes how QUIC can be secured using Transport Layer 99 Security (TLS) version 1.3 [I-D.ietf-tls-tls13]. TLS 1.3 provides 100 critical latency improvements for connection establishment over 101 previous versions. Absent packet loss, most new connections can be 102 established and secured within a single round trip; on subsequent 103 connections between the same client and server, the client can often 104 send application data immediately, that is, zero round trip setup. 106 This document describes how the standardized TLS 1.3 can act a 107 security component of QUIC. The same design could work for TLS 1.2, 108 though few of the benefits QUIC provides would be realized due to the 109 handshake latency in versions of TLS prior to 1.3. 111 1.1. Notational Conventions 113 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 114 document. It's not shouting; when they are capitalized, they have 115 the special meaning defined in [RFC2119]. 117 2. Protocol Overview 119 QUIC [QUIC-TRANSPORT] can be separated into several modules: 121 1. The basic frame envelope describes the common packet layout. 122 This layer includes connection identification, version 123 negotiation, and includes markers that allow the framing and 124 public reset to be identified. 126 2. The public reset is an unprotected packet that allows an 127 intermediary (an entity that is not part of the security context) 128 to request the termination of a QUIC connection. 130 3. Version negotiation frames are used to agree on a common version 131 of QUIC to use. 133 4. Framing comprises most of the QUIC protocol. Framing provides a 134 number of different types of frame, each with a specific purpose. 135 Framing supports frames for both congestion management and stream 136 multiplexing. Framing additionally provides a liveness testing 137 capability (the PING frame). 139 5. Encryption provides confidentiality and integrity protection for 140 frames. All frames are protected based on keying material 141 derived from the TLS connection running on stream 1. Prior to 142 this, data is protected with the 0-RTT keys. 144 6. Multiplexed streams are the primary payload of QUIC. These 145 provide reliable, in-order delivery of data and are used to carry 146 the encryption handshake and transport parameters (stream 1), 147 HTTP header fields (stream 3), and HTTP requests and responses. 148 Frames for managing multiplexing include those for creating and 149 destroying streams as well as flow control and priority frames. 151 7. Congestion management includes packet acknowledgment and other 152 signal required to ensure effective use of available link 153 capacity. 155 8. A complete TLS connection is run on stream 1. This includes the 156 entire TLS record layer. As the TLS connection reaches certain 157 states, keying material is provided to the QUIC encryption layer 158 for protecting the remainder of the QUIC traffic. 160 9. The HTTP mapping [QUIC-HTTP] provides an adaptation to HTTP 161 semantics that is based on HTTP/2. 163 The relative relationship of these components are pictorally 164 represented in Figure 1. 166 +-----+------+ 167 | TLS | HTTP | 168 +-----+------+------------+ 169 | Streams | Congestion | 170 +------------+------------+ 171 | Frames +--------+---------+ 172 + +---------------------+ Public | Version | 173 | | Encryption | Reset | Nego. | 174 +---+---------------------+--------+---------+ 175 | Envelope | 176 +--------------------------------------------+ 177 | UDP | 178 +--------------------------------------------+ 180 Figure 1: QUIC Structure 182 This document defines the cryptographic parts of QUIC. This includes 183 the handshake messages that are exchanged on stream 1, plus the 184 record protection that is used to encrypt and authenticate all other 185 frames. 187 2.1. Handshake Overview 189 TLS 1.3 provides two basic handshake modes of interest to QUIC: 191 o A full handshake in which the client is able to send application 192 data after one round trip and the server immediately after 193 receiving the first message from the client. 195 o A 0-RTT handshake in which the client uses information about the 196 server to send immediately. This data can be replayed by an 197 attacker so it MUST NOT carry a self-contained trigger for any 198 non-idempotent action. 200 A simplified TLS 1.3 handshake with 0-RTT application data is shown 201 in Figure 2, see [I-D.ietf-tls-tls13] for more options and details. 203 Client Server 205 ClientHello 206 (0-RTT Application Data) 207 (end_of_early_data) --------> 208 ServerHello 209 {EncryptedExtensions} 210 {ServerConfiguration} 211 {Certificate} 212 {CertificateVerify} 213 {Finished} 214 <-------- [Application Data] 215 {Finished} --------> 217 [Application Data] <-------> [Application Data] 219 Figure 2: TLS Handshake with 0-RTT 221 Two additional variations on this basic handshake exchange are 222 relevant to this document: 224 o The server can respond to a ClientHello with a HelloRetryRequest, 225 which adds an additional round trip prior to the basic exchange. 226 This is needed if the server wishes to request a different key 227 exchange key from the client. HelloRetryRequest is also used to 228 verify that the client is correctly able to receive packets on the 229 address it claims to have (see Section 6.3). 231 o A pre-shared key mode can be used for subsequent handshakes to 232 avoid public key operations. This is the basis for 0-RTT data, 233 even if the remainder of the connection is protected by a new 234 Diffie-Hellman exchange. 236 3. TLS in Stream 1 238 QUIC completes its cryptographic handshake on stream 1, which means 239 that the negotiation of keying material happens after the QUIC 240 protocol has started. This simplifies the use of TLS since QUIC is 241 able to ensure that the TLS handshake packets are delivered reliably 242 and in order. 244 QUIC Stream 1 carries a complete TLS connection. This includes the 245 TLS record layer in its entirety. QUIC provides for reliable and in- 246 order delivery of the TLS handshake messages on this stream. 248 Prior to the completion of the TLS handshake, QUIC frames can be 249 exchanged. However, these frames are not authenticated or 250 confidentiality protected. Section 5 covers some of the implications 251 of this design and limitations on QUIC operation during this phase. 253 Once the TLS handshake completes, QUIC frames are protected using 254 QUIC record protection, see Section 4. If 0-RTT is possible, QUIC 255 frames sent by the client can be protected with 0-RTT keys; these 256 packets are subject to replay. 258 3.1. Handshake and Setup Sequence 260 The integration of QUIC with a TLS handshake is shown in more detail 261 in Figure 3. QUIC "STREAM" frames on stream 1 carry the TLS 262 handshake. QUIC performs loss recovery [QUIC-RECOVERY] for this 263 stream and ensures that TLS handshake messages are delivered in the 264 correct order. 266 Client Server 268 @A QUIC STREAM Frame(s) <1>: 269 ClientHello 270 + QUIC Setup Parameters 271 --------> 272 0-RTT Key => @B 274 @B QUIC STREAM Frame(s) : 275 Replayable QUIC Frames 276 --------> 278 QUIC STREAM Frame <1>: @A 279 ServerHello 280 {Handshake Messages} 281 <-------- 282 1-RTT Key => @C 284 QUIC Frames @C 285 <-------- 286 @A QUIC STREAM Frame(s) <1>: 287 (end_of_early_data) 288 {Finished} 289 --------> 291 @C QUIC Frames <-------> QUIC Frames @C 293 Figure 3: QUIC over TLS Handshake 295 In Figure 3, symbols mean: 297 o "<" and ">" enclose stream numbers. 299 o "@" indicates the key phase that is currently used for protecting 300 QUIC packets. 302 o "(" and ")" enclose messages that are protected with TLS 0-RTT 303 handshake or application keys. 305 o "{" and "}" enclose messages that are protected by the TLS 306 Handshake keys. 308 If 0-RTT is not possible, then the client does not send frames 309 protected by the 0-RTT key (@B). In that case, the only key 310 transition on the client is from cleartext (@A) to 1-RTT protection 311 (@C). 313 The server sends TLS handshake messages without protection (@A). The 314 server transitions from no protection (@A) to full 1-RTT protection 315 (@C) after it sends the last of its handshake messages. 317 Some TLS handshake messages are protected by the TLS handshake record 318 protection. However, keys derived at this stage are not exported for 319 use in QUIC. QUIC frames from the server are sent in the clear until 320 the final transition to 1-RTT keys. 322 The client transitions from @A to @B when sending 0-RTT data, but it 323 transitions back to @A when sending its second flight of TLS 324 handshake messages. This introduces a potential for confusion 325 between packets with 0-RTT protection (@B) and those with 1-RTT 326 protection (@C) at the server if there is loss or reordering of the 327 handshake packets. See Section 4.1.2 for details on how this is 328 addressed. 330 4. QUIC Packet Protection 332 QUIC provides a packet protection layer that is responsible for 333 authenticated encryption of packets. The packet protection layer 334 uses keys provided by the TLS connection and authenticated encryption 335 to provide confidentiality and integrity protection for the content 336 of packets (see Section 4.3). 338 Different keys are used for QUIC packet protection and TLS record 339 protection. Having separate QUIC and TLS record protection means 340 that TLS records can be protected by two different keys. This 341 redundancy is limited to a only a few TLS records, and is maintained 342 for the sake of simplicity. 344 Keying material for new keys is exported from TLS using TLS 345 exporters. These exported values are used to produce the keying 346 material used to protect packets (see Section 4.2). 348 4.1. Key Phases 350 At several stages during the handshake, new keying material can be 351 exported from TLS and used for QUIC packet protection. At each 352 transition during the handshake a new secret is exported from TLS and 353 keying material is derived from that secret. 355 Every time that a new set of keys is used for protecting outbound 356 packets, the KEY_PHASE bit in the public flags is toggled. The 357 KEY_PHASE bit starts out with a value of 0 and is set to 1 when the 358 first encrypted packets are sent. Once the connection is fully 359 enabled, the KEY_PHASE bit can toggle between 0 and 1 as keys are 360 updated (see Section 4.4). 362 The KEY_PHASE bit on the public flags is the most significant bit 363 (0x80). 365 The KEY_PHASE bit allows a recipient to detect a change in keying 366 material without necessarily needing to receive the first packet that 367 triggered the change. An endpoint that notices a changed KEY_PHASE 368 bit can update keys and decrypt the packet that contains the changed 369 bit. This isn't possible during the handshake, because the entire 370 first flight of TLS handshake messages is used as input to key 371 derivation. 373 The following transitions are possible: 375 o When using 0-RTT, the client transitions to using 0-RTT keys after 376 sending the ClientHello. The KEY_PHASE bit on 0-RTT packets sent 377 by the client is set to 1. 379 o The server sends messages in the clear until the TLS handshake 380 completes. The KEY_PHASE bit on packets sent by the server is set 381 to 0 when the handshake is in progress. Note that TLS handshake 382 messages will still be protected by TLS record protection based on 383 the TLS handshake traffic keys. 385 o The server transitions to using 1-RTT keys after sending its 386 Finished message. This causes the KEY_PHASE bit on packets sent 387 by the server to be set to 1. 389 o The client transitions back to cleartext when sending its second 390 flight of TLS handshake messages. KEY_PHASE on the client's 391 second flight of handshake messages is set back to 0. This 392 includes a TLS end_of_early_data alert, which is protected with 393 TLS (not QUIC) 0-RTT keys. 395 o The client transitions to sending with 1-RTT keys and a KEY_PHASE 396 of 1 after sending its Finished message. 398 o Once the handshake is complete and all TLS handshake messages have 399 been sent and acknowledged, either endpoint can send packets with 400 a new set of keys. This is signaled by toggling the value of the 401 KEY_PHASE bit, see Section 4.4. 403 At each transition point, both keying material (see Section 4.2) and 404 the AEAD function used by TLS is interchanged with the values that 405 are currently in use for protecting outbound packets. Once a change 406 of keys has been made, packets with higher sequence numbers MUST use 407 the new keying material until a newer set of keys (and AEAD) are 408 used. The exception to this is that retransmissions of TLS handshake 409 packets MUST use the keys that they were originally protected with 410 (see Section 4.1.1). 412 4.1.1. Retransmission of TLS Handshake Messages 414 TLS handshake messages need to be retransmitted with the same level 415 of cryptographic protection that was originally used to protect them. 416 Newer keys cannot be used to protect QUIC packets that carry TLS 417 messages. 419 A client would be unable to decrypt retransmissions of a server's 420 handshake messages that are protected using the 1-RTT keys, since the 421 calculation of the 1-RTT keys depends on the contents of the 422 handshake messages. 424 This restriction means the creation of an exception to the 425 requirement to always use new keys for sending once they are 426 available. A server MUST mark the retransmitted handshake messages 427 with the same KEY_PHASE as the original messages to allow a recipient 428 to distinguish retransmitted messages. 430 This rule also prevents a key update from being initiated while there 431 are any outstanding handshake messages, see Section 4.4. 433 4.1.2. Distinguishing 0-RTT and 1-RTT Packets 435 Loss or reordering of the client's second flight of TLS handshake 436 messages can cause 0-RTT packet and 1-RTT packets to become 437 indistinguishable from each other when they arrive at the server. 438 Both 0-RTT packets use a KEY_PHASE of 1. 440 A server does not need to receive the client's second flight of TLS 441 handshake messages in order to derive the secrets needed to decrypt 442 1-RTT messages. Thus, a server is able to decrypt 1-RTT messages 443 that arrive prior to receiving the client's Finished message. Of 444 course, any decision that might be made based on client 445 authentication needs to be delayed until the client's authentication 446 messages have been received and validated. 448 A server can distinguish between 0-RTT and 1-RTT packets by 449 TBDTBDTBD. 451 4.2. QUIC Key Expansion 453 QUIC uses a system of packet protection secrets, keys and IVs that 454 are modelled on the system used in TLS [I-D.ietf-tls-tls13]. The 455 secrets that QUIC uses as the basis of its key schedule are obtained 456 using TLS exporters (see Section 7.3.3 of [I-D.ietf-tls-tls13]). 458 QUIC uses the Pseudo-Random Function (PRF) hash function negotiated 459 by TLS for key derivation. For example, if TLS is using the 460 TLS_AES_128_GCM_SHA256, the SHA-256 hash function is used. 462 4.2.1. 0-RTT Secret 464 0-RTT keys are those keys that are used in resumed connections prior 465 to the completion of the TLS handshake. Data sent using 0-RTT keys 466 might be replayed and so has some restrictions on its use, see 467 Section 5.2. 0-RTT keys are used after sending or receiving a 468 ClientHello. 470 The secret is exported from TLS using the exporter label "EXPORTER- 471 QUIC 0-RTT Secret" and an empty context. The size of the secret MUST 472 be the size of the hash output for the PRF hash function negotiated 473 by TLS. This uses the TLS early_exporter_secret. The QUIC 0-RTT 474 secret is only used for protection of packets sent by the client. 476 client_0rtt_secret 477 = TLS-Exporter("EXPORTER-QUIC 0-RTT Secret" 478 "", Hash.length) 480 4.2.2. 1-RTT Secrets 482 1-RTT keys are used by both client and server after the TLS handshake 483 completes. There are two secrets used at any time: one is used to 484 derive packet protection keys for packets sent by the client, the 485 other for protecting packets sent by the server. 487 The initial client packet protection secret is exported from TLS 488 using the exporter label "EXPORTER-QUIC client 1-RTT Secret"; the 489 initial server packet protection secret uses the exporter label 490 "EXPORTER-QUIC server 1-RTT Secret". Both exporters use an empty 491 context. The size of the secret MUST be the size of the hash output 492 for the PRF hash function negotiated by TLS. 494 client_pp_secret_0 495 = TLS-Exporter("EXPORTER-QUIC client 1-RTT Secret" 496 "", Hash.length) 497 server_pp_secret_0 498 = TLS-Exporter("EXPORTER-QUIC server 1-RTT Secret" 499 "", Hash.length) 501 After a key update (see Section 4.4), these secrets are updated using 502 the HKDF-Expand-Label function defined in Section 7.1 of 503 [I-D.ietf-tls-tls13], using the PRF hash function negotiated by TLS. 504 The replacement secret is derived using the existing Secret, a Label 505 of "QUIC client 1-RTT Secret" for the client and "QUIC server 1-RTT 506 Secret", an empty HashValue, and the same output Length as the hash 507 function selected by TLS for its PRF. 509 client_pp_secret_ 510 = HKDF-Expand-Label(client_pp_secret_, 511 "QUIC client 1-RTT Secret", 512 "", Hash.length) 513 server_pp_secret_ 514 = HKDF-Expand-Label(server_pp_secret_, 515 "QUIC server 1-RTT Secret", 516 "", Hash.length) 518 For example, the client secret is updated using HKDF-Expand [RFC5869] 519 with an info parameter that includes the PRF hash length encoded on 520 two octets, the string "TLS 1.3, QUIC client 1-RTT secret" and a zero 521 octet. This equates to a single use of HMAC [RFC2104] with the 522 negotiated PRF hash function: 524 info = Hash.length / 256 || Hash.length % 256 || 525 "TLS 1.3, QUIC client 1-RTT secret" || 0x00 526 client_pp_secret_ 527 = HMAC-Hash(client_pp_secret_, info || 0x01) 529 4.2.3. Packet Protection Key and IV 531 The complete key expansion uses an identical process for key 532 expansion as defined in Section 7.3 of [I-D.ietf-tls-tls13], using 533 different values for the input secret. QUIC uses the AEAD function 534 negotiated by TLS. 536 The key and IV used to protect the 0-RTT packets sent by a client use 537 the QUIC 0-RTT secret. This uses the HKDF-Expand-Label with the PRF 538 hash function negotiated by TLS. The length of the output is 539 determined by the requirements of the AEAD function selected by TLS. 541 client_0rtt_key = HKDF-Expand-Label(client_0rtt_secret, 542 "key", "", key_length) 543 client_0rtt_iv = HKDF-Expand-Label(client_0rtt_secret, 544 "iv", "", iv_length) 546 Similarly, the key and IV used to protect 1-RTT packets sent by both 547 client and server use the current packet protection secret. 549 client_pp_key_ = HKDF-Expand-Label(client_pp_secret_, 550 "key", "", key_length) 551 client_pp_iv_ = HKDF-Expand-Label(client_pp_secret_, 552 "iv", "", iv_length) 553 server_pp_key_ = HKDF-Expand-Label(server_pp_secret_, 554 "key", "", key_length) 555 server_pp_iv_ = HKDF-Expand-Label(server_pp_secret_, 556 "iv", "", iv_length) 558 The QUIC record protection initially starts without keying material. 559 When the TLS state machine reports that the ClientHello has been 560 sent, the 0-RTT keys can be generated and installed for writing. 561 When the TLS state machine reports completion of the handshake, the 562 1-RTT keys can be generated and installed for writing. 564 4.3. QUIC AEAD Usage 566 The Authentication Encryption with Associated Data (AEAD) [RFC5116] 567 function used for QUIC packet protection is AEAD that is negotiated 568 for use with the TLS connection. For example, if TLS is using the 569 TLS_AES_128_GCM_SHA256, the AEAD_AES_128_GCM function is used. 571 Regular QUIC packets are protected by an AEAD [RFC5116]. Version 572 negotiation and public reset packets are not protected. 574 Once TLS has provided a key, the contents of regular QUIC packets 575 immediately after any TLS messages have been sent are protected by 576 the AEAD selected by TLS. 578 The key, K, for the AEAD is either the Client Write Key or the Server 579 Write Key, derived as defined in Section 4.2. 581 The nonce, N, for the AEAD is formed by combining either the Client 582 Write IV or Server Write IV with packet numbers. The 64 bits of the 583 reconstructed QUIC packet number in network byte order is left-padded 584 with zeros to the N_MAX parameter of the AEAD (see Section 4 of 585 [RFC5116]). The exclusive OR of the padded packet number and the IV 586 forms the AEAD nonce. 588 The associated data, A, for the AEAD is an empty sequence. 590 The input plaintext, P, for the AEAD is the contents of the QUIC 591 frame following the packet number, as described in [QUIC-TRANSPORT]. 593 The output ciphertext, C, of the AEAD is transmitted in place of P. 595 Prior to TLS providing keys, no record protection is performed and 596 the plaintext, P, is transmitted unmodified. 598 4.4. Key Update 600 Once the TLS handshake is complete, the KEY_PHASE bit allows for 601 refreshes of keying material by either peer. Endpoints start using 602 updated keys immediately without additional signaling; the change in 603 the KEY_PHASE bit indicates that a new key is in use. 605 An endpoint MUST NOT initiate more than one key update at a time. A 606 new key cannot be used until the endpoint has received and 607 successfully decrypted a packet with a matching KEY_PHASE. 609 A receiving endpoint detects an update when the KEY_PHASE bit doesn't 610 match what it is expecting. It creates a new secret (see 611 Section 4.2) and the corresponding read key and IV. If the packet 612 can be decrypted and authenticated using these values, then a write 613 keys and IV are generated and the active keys are replaced. The next 614 packet sent by the endpoint will then use the new keys. 616 An endpoint doesn't need to send packets immediately when it detects 617 that its peer has updated keys. The next packets that it sends will 618 simply use the new keys. If an endpoint detects a second update 619 before it has sent any packets with updated keys it indicates that 620 its peer has updated keys twice without awaiting a reciprocal update. 621 An endpoint MUST treat consecutive key updates as a fatal error and 622 abort the connection. 624 An endpoint SHOULD retain old keys for a short period to allow it to 625 decrypt packets with smaller packet numbers than the packet that 626 triggered the key update. This allows an endpoint to consume packets 627 that are reordered around the transition between keys. Packets with 628 higher packet numbers always use the updated keys and MUST NOT be 629 decrypted with old keys. 631 Keys and their corresponding secrets SHOULD be discarded when an 632 endpoints has received all packets with sequence numbers lower than 633 the lowest sequence number used for the new key, or when it 634 determines that the length of the delay to affected packets is 635 excessive. 637 This ensures that once the handshake is complete, there are at most 638 two keys to distinguish between at any one time, for which the 639 KEY_PHASE bit is sufficient. 641 Initiating Peer Responding Peer 643 @M QUIC Frames 644 New Keys -> @N 645 @N QUIC Frames 646 --------> 647 QUIC Frames @M 648 New Keys -> @N 649 QUIC Frames @N 650 <-------- 652 Figure 4: Key Update 654 As shown in Figure 3 and Figure 4, there is never a situation where 655 there are more than two different sets of keying material that might 656 be received by a peer. Once both sending and receiving keys have 657 been updated, 659 A server cannot initiate a key update until it has received the 660 client's Finished message. Otherwise, packets protected by the 661 updated keys could be confused for retransmissions of handshake 662 messages. A client cannot initiate a key update until all of its 663 handshake messages have been acknowledged by the server. 665 4.5. Packet Numbers 667 QUIC has a single, contiguous packet number space. In comparison, 668 TLS restarts its sequence number each time that record protection 669 keys are changed. The sequence number restart in TLS ensures that a 670 compromise of the current traffic keys does not allow an attacker to 671 truncate the data that is sent after a key update by sending 672 additional packets under the old key (causing new packets to be 673 discarded). 675 QUIC does not assume a reliable transport and is therefore required 676 to handle attacks where packets are dropped in other ways. 678 The packet number is not reset and it is not permitted to go higher 679 than its maximum value of 2^64-1. This establishes a hard limit on 680 the number of packets that can be sent. Before this limit is 681 reached, some AEAD functions have limits for how many packets can be 682 encrypted under the same key and IV (see for example [AEBounds]). An 683 endpoint MUST initiate a key update (Section 4.4) prior to exceeding 684 any limit set for the AEAD that is in use. 686 TLS maintains a separate sequence number that is used for record 687 protection on the connection that is hosted on stream 1. This 688 sequence number is reset according to the rules in the TLS protocol. 690 5. Pre-handshake QUIC Messages 692 Implementations MUST NOT exchange data on any stream other than 693 stream 1 prior to the completion of the TLS handshake. However, QUIC 694 requires the use of several types of frame for managing loss 695 detection and recovery. In addition, it might be useful to use the 696 data acquired during the exchange of unauthenticated messages for 697 congestion management. 699 This section generally only applies to TLS handshake messages from 700 both peers and acknowledgments of the packets carrying those 701 messages. In many cases, the need for servers to provide 702 acknowledgments is minimal, since the messages that clients send are 703 small and implicitly acknowledged by the server's responses. 705 The actions that a peer takes as a result of receiving an 706 unauthenticated packet needs to be limited. In particular, state 707 established by these packets cannot be retained once record 708 protection commences. 710 There are several approaches possible for dealing with 711 unauthenticated packets prior to handshake completion: 713 o discard and ignore them 715 o use them, but reset any state that is established once the 716 handshake completes 718 o use them and authenticate them afterwards; failing the handshake 719 if they can't be authenticated 721 o save them and use them when they can be properly authenticated 723 o treat them as a fatal error 725 Different strategies are appropriate for different types of data. 726 This document proposes that all strategies are possible depending on 727 the type of message. 729 o Transport parameters and options are made usable and authenticated 730 as part of the TLS handshake (see Section 6.2). 732 o Most unprotected messages are treated as fatal errors when 733 received except for the small number necessary to permit the 734 handshake to complete (see Section 5.1). 736 o Protected packets can either be discarded or saved and later used 737 (see Section 5.3). 739 5.1. Unprotected Frames Prior to Handshake Completion 741 This section describes the handling of messages that are sent and 742 received prior to the completion of the TLS handshake. 744 Sending and receiving unprotected messages is hazardous. Unless 745 expressly permitted, receipt of an unprotected message of any kind 746 MUST be treated as a fatal error. 748 5.1.1. STREAM Frames 750 "STREAM" frames for stream 1 are permitted. These carry the TLS 751 handshake messages. 753 Receiving unprotected "STREAM" frames for other streams MUST be 754 treated as a fatal error. 756 5.1.2. ACK Frames 758 "ACK" frames are permitted prior to the handshake being complete. 759 Information learned from "ACK" frames cannot be entirely relied upon, 760 since an attacker is able to inject these packets. Timing and packet 761 retransmission information from "ACK" frames is critical to the 762 functioning of the protocol, but these frames might be spoofed or 763 altered. 765 Endpoints MUST NOT use an unprotected "ACK" frame to acknowledge data 766 that was protected by 0-RTT or 1-RTT keys. An endpoint MUST ignore 767 an unprotected "ACK" frame if it claims to acknowledge data that was 768 protected data. Such an acknowledgement can only serve as a denial 769 of service, since an endpoint that can read protected data is always 770 permitted to send protected data. 772 An endpoint SHOULD use data from unprotected or 0-RTT-protected "ACK" 773 frames only during the initial handshake and while they have 774 insufficient information from 1-RTT-protected "ACK" frames. Once 775 sufficient information has been obtained from protected messages, 776 information obtained from less reliable sources can be discarded. 778 5.1.3. WINDOW_UPDATE Frames 780 "WINDOW_UPDATE" frames MUST NOT be sent unprotected. 782 Though data is exchanged on stream 1, the initial flow control window 783 is is sufficiently large to allow the TLS handshake to complete. 784 This limits the maximum size of the TLS handshake and would prevent a 785 server or client from using an abnormally large certificate chain. 787 Stream 1 is exempt from the connection-level flow control window. 789 5.1.4. Denial of Service with Unprotected Packets 791 Accepting unprotected - specifically unauthenticated - packets 792 presents a denial of service risk to endpoints. An attacker that is 793 able to inject unprotected packets can cause a recipient to drop even 794 protected packets with a matching sequence number. The spurious 795 packet shadows the genuine packet, causing the genuine packet to be 796 ignored as redundant. 798 Once the TLS handshake is complete, both peers MUST ignore 799 unprotected packets. The handshake is complete when the server 800 receives a client's Finished message and when a client receives an 801 acknowledgement that their Finished message was received. From that 802 point onward, unprotected messages can be safely dropped. Note that 803 the client could retransmit its Finished message to the server, so 804 the server cannot reject such a message. 806 Since only TLS handshake packets and acknowledgments are sent in the 807 clear, an attacker is able to force implementations to rely on 808 retransmission for packets that are lost or shadowed. Thus, an 809 attacker that intends to deny service to an endpoint has to drop or 810 shadow protected packets in order to ensure that their victim 811 continues to accept unprotected packets. The ability to shadow 812 packets means that an attacker does not need to be on path. 814 ISSUE: This would not be an issue if QUIC had a randomized starting 815 sequence number. If we choose to randomize, we fix this problem 816 and reduce the denial of service exposure to on-path attackers. 817 The only possible problem is in authenticating the initial value, 818 so that peers can be sure that they haven't missed an initial 819 message. 821 In addition to denying endpoints messages, an attacker to generate 822 packets that cause no state change in a recipient. See Section 7.2 823 for a discussion of these risks. 825 To avoid receiving TLS packets that contain no useful data, a TLS 826 implementation MUST reject empty TLS handshake records and any record 827 that is not permitted by the TLS state machine. Any TLS application 828 data or alerts - other than a single end_of_early_data at the 829 appropriate time - that is received prior to the end of the handshake 830 MUST be treated as a fatal error. 832 5.2. Use of 0-RTT Keys 834 If 0-RTT keys are available, the lack of replay protection means that 835 restrictions on their use are necessary to avoid replay attacks on 836 the protocol. 838 A client MUST only use 0-RTT keys to protect data that is idempotent. 839 A client MAY wish to apply additional restrictions on what data it 840 sends prior to the completion of the TLS handshake. A client 841 otherwise treats 0-RTT keys as equivalent to 1-RTT keys. 843 A client that receives an indication that its 0-RTT data has been 844 accepted by a server can send 0-RTT data until it receives all of the 845 server's handshake messages. A client SHOULD stop sending 0-RTT data 846 if it receives an indication that 0-RTT data has been rejected. In 847 addition to a ServerHello without an early_data extension, an 848 unprotected handshake message with a KEY_PHASE bit set to 0 indicates 849 that 0-RTT data has been rejected. 851 A client SHOULD send its end_of_early_data alert only after it has 852 received all of the server's handshake messages. Alternatively 853 phrased, a client is encouraged to use 0-RTT keys until 1-RTT keys 854 become available. This prevents stalling of the connection and 855 allows the client to send continuously. 857 A server MUST NOT use 0-RTT keys to protect anything other than TLS 858 handshake messages. Servers therefore treat packets protected with 859 0-RTT keys as equivalent to unprotected packets in determining what 860 is permissible to send. A server protects handshake messages using 861 the 0-RTT key if it decides to accept a 0-RTT key. A server MUST 862 still include the early_data extension in its ServerHello message. 864 This restriction prevents a server from responding to a request using 865 frames protected by the 0-RTT keys. This ensures that all 866 application data from the server are always protected with keys that 867 have forward secrecy. However, this results in head-of-line blocking 868 at the client because server responses cannot be decrypted until all 869 the server's handshake messages are received by the client. 871 5.3. Protected Frames Prior to Handshake Completion 873 Due to reordering and loss, protected packets might be received by an 874 endpoint before the final handshake messages are received. If these 875 can be decrypted successfully, such packets MAY be stored and used 876 once the handshake is complete. 878 Unless expressly permitted below, encrypted packets MUST NOT be used 879 prior to completing the TLS handshake, in particular the receipt of a 880 valid Finished message and any authentication of the peer. If 881 packets are processed prior to completion of the handshake, an 882 attacker might use the willingness of an implementation to use these 883 packets to mount attacks. 885 TLS handshake messages are covered by record protection during the 886 handshake, once key agreement has completed. This means that 887 protected messages need to be decrypted to determine if they are TLS 888 handshake messages or not. Similarly, "ACK" and "WINDOW_UPDATE" 889 frames might be needed to successfully complete the TLS handshake. 891 Any timestamps present in "ACK" frames MUST be ignored rather than 892 causing a fatal error. Timestamps on protected frames MAY be saved 893 and used once the TLS handshake completes successfully. 895 An endpoint MAY save the last protected "WINDOW_UPDATE" frame it 896 receives for each stream and apply the values once the TLS handshake 897 completes. Failing to do this might result in temporary stalling of 898 affected streams. 900 6. QUIC-Specific Additions to the TLS Handshake 902 QUIC uses the TLS handshake for more than just negotiation of 903 cryptographic parameters. The TLS handshake validates protocol 904 version selection, provides preliminary values for QUIC transport 905 parameters, and allows a server to perform return routeability checks 906 on clients. 908 6.1. Protocol and Version Negotiation 910 The QUIC version negotiation mechanism is used to negotiate the 911 version of QUIC that is used prior to the completion of the 912 handshake. However, this packet is not authenticated, enabling an 913 active attacker to force a version downgrade. 915 To ensure that a QUIC version downgrade is not forced by an attacker, 916 version information is copied into the TLS handshake, which provides 917 integrity protection for the QUIC negotiation. This does not prevent 918 version downgrade during the handshake, though it means that such a 919 downgrade causes a handshake failure. 921 Protocols that use the QUIC transport MUST use Application Layer 922 Protocol Negotiation (ALPN) [RFC7301]. The ALPN identifier for the 923 protocol MUST be specific to the QUIC version that it operates over. 924 When constructing a ClientHello, clients MUST include a list of all 925 the ALPN identifiers that they support, regardless of whether the 926 QUIC version that they have currently selected supports that 927 protocol. 929 Servers SHOULD select an application protocol based solely on the 930 information in the ClientHello, not using the QUIC version that the 931 client has selected. If the protocol that is selected is not 932 supported with the QUIC version that is in use, the server MAY send a 933 QUIC version negotiation packet to select a compatible version. 935 If the server cannot select a combination of ALPN identifier and QUIC 936 version it MUST abort the connection. A client MUST abort a 937 connection if the server picks an incompatible version of QUIC 938 version and ALPN. 940 6.2. QUIC Extension 942 QUIC defines an extension for use with TLS. That extension defines 943 transport-related parameters. This provides integrity protection for 944 these values. Including these in the TLS handshake also make the 945 values that a client sets available to a server one-round trip 946 earlier than parameters that are carried in QUIC frames. This 947 document does not define that extension. 949 6.3. Source Address Validation 951 QUIC implementations describe a source address token. This is an 952 opaque blob that a server might provide to clients when they first 953 use a given source address. The client returns this token in 954 subsequent messages as a return routeability check. That is, the 955 client returns this token to prove that it is able to receive packets 956 at the source address that it claims. This prevents the server from 957 being used in packet reflection attacks (see Section 7.1). 959 A source address token is opaque and consumed only by the server. 960 Therefore it can be included in the TLS 1.3 pre-shared key identifier 961 for 0-RTT handshakes. Servers that use 0-RTT are advised to provide 962 new pre-shared key identifiers after every handshake to avoid 963 linkability of connections by passive observers. Clients MUST use a 964 new pre-shared key identifier for every connection that they 965 initiate; if no pre-shared key identifier is available, then 966 resumption is not possible. 968 A server that is under load might include a source address token in 969 the cookie extension of a HelloRetryRequest. 971 6.4. Priming 0-RTT 973 QUIC uses TLS without modification. Therefore, it is possible to use 974 a pre-shared key that was obtained in a TLS connection over TCP to 975 enable 0-RTT in QUIC. Similarly, QUIC can provide a pre-shared key 976 that can be used to enable 0-RTT in TCP. 978 All the restrictions on the use of 0-RTT apply, with the exception of 979 the ALPN label, which MUST only change to a label that is explicitly 980 designated as being compatible. The client indicates which ALPN 981 label it has chosen by placing that ALPN label first in the ALPN 982 extension. 984 The certificate that the server uses MUST be considered valid for 985 both connections, which will use different protocol stacks and could 986 use different port numbers. For instance, HTTP/1.1 and HTTP/2 987 operate over TLS and TCP, whereas QUIC operates over UDP. 989 Source address validation is not completely portable between 990 different protocol stacks. Even if the source IP address remains 991 constant, the port number is likely to be different. Packet 992 reflection attacks are still possible in this situation, though the 993 set of hosts that can initiate these attacks is greatly reduced. A 994 server might choose to avoid source address validation for such a 995 connection, or allow an increase to the amount of data that it sends 996 toward the client without source validation. 998 7. Security Considerations 1000 There are likely to be some real clangers here eventually, but the 1001 current set of issues is well captured in the relevant sections of 1002 the main text. 1004 Never assume that because it isn't in the security considerations 1005 section it doesn't affect security. Most of this document does. 1007 7.1. Packet Reflection Attack Mitigation 1009 A small ClientHello that results in a large block of handshake 1010 messages from a server can be used in packet reflection attacks to 1011 amplify the traffic generated by an attacker. 1013 Certificate caching [RFC7924] can reduce the size of the server's 1014 handshake messages significantly. 1016 A client SHOULD also pad [RFC7685] its ClientHello to at least 1024 1017 octets. A server is less likely to generate a packet reflection 1018 attack if the data it sends is a small multiple of the data it 1019 receives. A server SHOULD use a HelloRetryRequest if the size of the 1020 handshake messages it sends is likely to exceed the size of the 1021 ClientHello. 1023 7.2. Peer Denial of Service 1025 QUIC, TLS and HTTP/2 all contain a messages that have legitimate uses 1026 in some contexts, but that can be abused to cause a peer to expend 1027 processing resources without having any observable impact on the 1028 state of the connection. If processing is disproportionately large 1029 in comparison to the observable effects on bandwidth or state, then 1030 this could allow a malicious peer to exhaust processing capacity 1031 without consequence. 1033 QUIC prohibits the sending of empty "STREAM" frames unless they are 1034 marked with the FIN bit. This prevents "STREAM" frames from being 1035 sent that only waste effort. 1037 TLS records SHOULD always contain at least one octet of a handshake 1038 messages or alert. Records containing only padding are permitted 1039 during the handshake, but an excessive number might be used to 1040 generate unnecessary work. Once the TLS handshake is complete, 1041 endpoints SHOULD NOT send TLS application data records unless it is 1042 to hide the length of QUIC records. QUIC packet protection does not 1043 include any allowance for padding; padded TLS application data 1044 records can be used to mask the length of QUIC frames. 1046 While there are legitimate uses for some redundant packets, 1047 implementations SHOULD track redundant packets and treat excessive 1048 volumes of any non-productive packets as indicative of an attack. 1050 8. IANA Considerations 1052 This document has no IANA actions. Yet. 1054 9. References 1056 9.1. Normative References 1058 [I-D.ietf-tls-tls13] 1059 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1060 Version 1.3", draft-ietf-tls-tls13-18 (work in progress), 1061 October 2016. 1063 [QUIC-RECOVERY] 1064 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 1065 and Congestion Control", November 2016. 1067 [QUIC-TRANSPORT] 1068 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1069 Multiplexed and Secure Transport", November 2016. 1071 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1072 Hashing for Message Authentication", RFC 2104, 1073 DOI 10.17487/RFC2104, February 1997, 1074 . 1076 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1077 Requirement Levels", BCP 14, RFC 2119, 1078 DOI 10.17487/RFC2119, March 1997, 1079 . 1081 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1082 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1083 . 1085 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1086 Key Derivation Function (HKDF)", RFC 5869, 1087 DOI 10.17487/RFC5869, May 2010, 1088 . 1090 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1091 Protocol (HTTP/1.1): Message Syntax and Routing", 1092 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1093 . 1095 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1096 "Transport Layer Security (TLS) Application-Layer Protocol 1097 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1098 July 2014, . 1100 [RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello 1101 Padding Extension", RFC 7685, DOI 10.17487/RFC7685, 1102 October 2015, . 1104 9.2. Informative References 1106 [AEBounds] 1107 Luykx, A. and K. Paterson, "Limits on Authenticated 1108 Encryption Use in TLS", March 2016, 1109 . 1111 [QUIC-HTTP] 1112 Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over 1113 QUIC", November 2016. 1115 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1116 RFC 793, DOI 10.17487/RFC0793, September 1981, 1117 . 1119 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1120 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1121 DOI 10.17487/RFC7540, May 2015, 1122 . 1124 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 1125 (TLS) Cached Information Extension", RFC 7924, 1126 DOI 10.17487/RFC7924, July 2016, 1127 . 1129 Appendix A. Contributors 1131 Ryan Hamilton was originally an author of this specification. 1133 Appendix B. Acknowledgments 1135 This document has benefited from input from Christian Huitema, Jana 1136 Iyengar, Adam Langley, Roberto Peon, Eric Rescorla, Ian Swett, and 1137 many others. 1139 Authors' Addresses 1141 Martin Thomson (editor) 1142 Mozilla 1144 Email: martin.thomson@gmail.com 1146 Sean Turner (editor) 1147 sn3rd