idnits 2.17.1 draft-thomson-quic-tls-01.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 (October 25, 2016) is 2737 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) == Unused Reference: 'RFC7258' is defined on line 974, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-hamilton-quic-transport-protocol-00 ** Downref: Normative reference to an Experimental draft: draft-hamilton-quic-transport-protocol (ref. 'I-D.hamilton-quic-transport-protocol') == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-17 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track R. Hamilton 5 Expires: April 28, 2017 Google 6 October 25, 2016 8 Using Transport Layer Security (TLS) to Secure QUIC 9 draft-thomson-quic-tls-01 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 April 28, 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 . . . . . . . . . . . . . . . . . . . . . . . 5 55 3.1. Handshake and Setup Sequence . . . . . . . . . . . . . . 6 56 4. QUIC Record Protection . . . . . . . . . . . . . . . . . . . 8 57 4.1. Key Phases . . . . . . . . . . . . . . . . . . . . . . . 8 58 4.1.1. Retransmission of TLS Handshake Messages . . . . . . 9 59 4.1.2. Key Update . . . . . . . . . . . . . . . . . . . . . 10 60 4.2. QUIC Key Expansion . . . . . . . . . . . . . . . . . . . 11 61 4.3. QUIC AEAD application . . . . . . . . . . . . . . . . . . 12 62 4.4. Sequence Number Reconstruction . . . . . . . . . . . . . 12 63 5. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 13 64 5.1. Unprotected Frames Prior to Handshake Completion . . . . 14 65 5.1.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 14 66 5.1.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 15 67 5.1.3. WINDOW_UPDATE Frames . . . . . . . . . . . . . . . . 15 68 5.1.4. Denial of Service with Unprotected Packets . . . . . 15 69 5.2. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 16 70 5.3. Protected Frames Prior to Handshake Completion . . . . . 17 71 6. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 18 72 6.1. Protocol and Version Negotiation . . . . . . . . . . . . 18 73 6.2. QUIC Extension . . . . . . . . . . . . . . . . . . . . . 18 74 6.3. Source Address Validation . . . . . . . . . . . . . . . . 19 75 6.4. Priming 0-RTT . . . . . . . . . . . . . . . . . . . . . . 19 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 77 7.1. Packet Reflection Attack Mitigation . . . . . . . . . . . 20 78 7.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 20 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 82 9.2. Informative References . . . . . . . . . . . . . . . . . 21 83 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 86 1. Introduction 88 QUIC [I-D.hamilton-quic-transport-protocol] provides a multiplexed 89 transport for HTTP [RFC7230] semantics that provides several key 90 advantages over HTTP/1.1 [RFC7230] or HTTP/2 [RFC7540] over TCP 91 [RFC0793]. 93 This document describes how QUIC can be secured using Transport Layer 94 Security (TLS) version 1.3 [I-D.ietf-tls-tls13]. TLS 1.3 provides 95 critical latency improvements for connection establishment over 96 previous versions. Absent packet loss, most new connections can be 97 established and secured within a single round trip; on subsequent 98 connections between the same client and server, the client can often 99 send application data immediately, that is, zero round trip setup. 101 This document describes how the standardized TLS 1.3 can act a 102 security component of QUIC. The same design could work for TLS 1.2, 103 though few of the benefits QUIC provides would be realized due to the 104 handshake latency in versions of TLS prior to 1.3. 106 1.1. Notational Conventions 108 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 109 document. It's not shouting; when they are capitalized, they have 110 the special meaning defined in [RFC2119]. 112 2. Protocol Overview 114 QUIC [I-D.hamilton-quic-transport-protocol] can be separated into 115 several modules: 117 1. The basic frame envelope describes the common packet layout. 118 This layer includes connection identification, version 119 negotiation, and includes markers that allow the framing and 120 public reset to be identified. 122 2. The public reset is an unprotected packet that allows an 123 intermediary (an entity that is not part of the security context) 124 to request the termination of a QUIC connection. 126 3. Version negotiation frames are used to agree on a common version 127 of QUIC to use. 129 4. Framing comprises most of the QUIC protocol. Framing provides a 130 number of different types of frame, each with a specific purpose. 131 Framing supports frames for both congestion management and stream 132 multiplexing. Framing additionally provides a liveness testing 133 capability (the PING frame). 135 5. Encryption provides confidentiality and integrity protection for 136 frames. All frames are protected based on keying material 137 derived from the TLS connection running on stream 1. Prior to 138 this, data is protected with the 0-RTT keys. 140 6. Multiplexed streams are the primary payload of QUIC. These 141 provide reliable, in-order delivery of data and are used to carry 142 the encryption handshake and transport parameters (stream 1), 143 HTTP header fields (stream 3), and HTTP requests and responses. 145 Frames for managing multiplexing include those for creating and 146 destroying streams as well as flow control and priority frames. 148 7. Congestion management includes packet acknowledgment and other 149 signal required to ensure effective use of available link 150 capacity. 152 8. A complete TLS connection is run on stream 1. This includes the 153 entire TLS record layer. As the TLS connection reaches certain 154 states, keying material is provided to the QUIC encryption layer 155 for protecting the remainder of the QUIC traffic. 157 9. HTTP mapping provides an adaptation to HTTP that is based on 158 HTTP/2. 160 The relative relationship of these components are pictorally 161 represented in Figure 1. 163 +-----+------+ 164 | TLS | HTTP | 165 +-----+------+------------+ 166 | Streams | Congestion | 167 +------------+------------+ 168 | Frames +--------+---------+ 169 + +---------------------+ Public | Version | 170 | | Encryption | Reset | Nego. | 171 +---+---------------------+--------+---------+ 172 | Envelope | 173 +--------------------------------------------+ 174 | UDP | 175 +--------------------------------------------+ 177 Figure 1: QUIC Structure 179 This document defines the cryptographic parts of QUIC. This includes 180 the handshake messages that are exchanged on stream 1, plus the 181 record protection that is used to encrypt and authenticate all other 182 frames. 184 2.1. Handshake Overview 186 TLS 1.3 provides two basic handshake modes of interest to QUIC: 188 o A full handshake in which the client is able to send application 189 data after one round trip and the server immediately after 190 receiving the first message from the client. 192 o A 0-RTT handshake in which the client uses information about the 193 server to send immediately. This data can be replayed by an 194 attacker so it MUST NOT carry a self-contained trigger for any 195 non-idempotent action. 197 A simplified TLS 1.3 handshake with 0-RTT application data is shown 198 in Figure 2, see [I-D.ietf-tls-tls13] for more options and details. 200 Client Server 202 ClientHello 203 (Finished) 204 (0-RTT Application Data) 205 (end_of_early_data) --------> 206 ServerHello 207 {EncryptedExtensions} 208 {ServerConfiguration} 209 {Certificate} 210 {CertificateVerify} 211 {Finished} 212 <-------- [Application Data] 213 {Finished} --------> 215 [Application Data] <-------> [Application Data] 217 Figure 2: TLS Handshake with 0-RTT 219 Two additional variations on this basic handshake exchange are 220 relevant to this document: 222 o The server can respond to a ClientHello with a HelloRetryRequest, 223 which adds an additional round trip prior to the basic exchange. 224 This is needed if the server wishes to request a different key 225 exchange key from the client. HelloRetryRequest is also used to 226 verify that the client is correctly able to receive packets on the 227 address it claims to have (see Section 6.3). 229 o A pre-shared key mode can be used for subsequent handshakes to 230 avoid public key operations. This is the basis for 0-RTT data, 231 even if the remainder of the connection is protected by a new 232 Diffie-Hellman exchange. 234 3. TLS in Stream 1 236 QUIC completes its cryptographic handshake on stream 1, which means 237 that the negotiation of keying material happens after the QUIC 238 protocol has started. This simplifies the use of TLS since QUIC is 239 able to ensure that the TLS handshake packets are delivered reliably 240 and in order. 242 QUIC Stream 1 carries a complete TLS connection. This includes the 243 TLS record layer in its entirety. QUIC provides for reliable and in- 244 order delivery of the TLS handshake messages on this stream. 246 Prior to the completion of the TLS handshake, QUIC frames can be 247 exchanged. However, these frames are not authenticated or 248 confidentiality protected. Section 5 covers some of the implications 249 of this design and limitations on QUIC operation during this phase. 251 Once complete, QUIC frames are protected using QUIC record 252 protection, see Section 4. 254 3.1. Handshake and Setup Sequence 256 The integration of QUIC with a TLS handshake is shown in more detail 257 in Figure 3. QUIC "STREAM" frames on stream 1 carry the TLS 258 handshake. QUIC is responsible for ensuring that the handshake 259 packets are re-sent in case of loss and that they can be ordered 260 correctly. 262 Client Server 264 @A QUIC STREAM Frame(s) <1>: 265 ClientHello 266 + QUIC Setup Parameters 267 --------> 268 0-RTT Key -> @B 270 @B QUIC STREAM Frame(s) <1>: 271 (Finished) 272 Replayable QUIC Frames 273 --------> 275 QUIC STREAM Frame <1>: @B/A 276 ServerHello 277 {Handshake Messages} 278 <-------- 279 1-RTT Key -> @C 281 QUIC Frames @C 282 <-------- 283 @B QUIC STREAM Frame(s) <1>: 284 (end_of_early_data <1>) 285 {Finished} 286 --------> 288 @C QUIC Frames <-------> QUIC Frames @C 290 Figure 3: QUIC over TLS Handshake 292 In Figure 3, symbols mean: 294 o "<" and ">" enclose stream numbers. 296 o "@" indicates the key phase that is currently used for protecting 297 QUIC packets. 299 o "(" and ")" enclose messages that are protected with TLS 0-RTT 300 handshake or application keys. 302 o "{" and "}" enclose messages that are protected by the TLS 303 Handshake keys. 305 If 0-RTT is not possible, then the client does not send frames 306 protected by the 0-RTT key (@B). The only key transition on the 307 client is from cleartext (@A) to 1-RTT protection (@C). 309 If 0-RTT data is not accepted by the server, then the server sends 310 its handshake messages without protection (@A). The client still 311 transitions from @A to @B, but it can stop sending 0-RTT data and 312 progress immediately to 1-RTT data when it receives a cleartext 313 ServerHello. 315 4. QUIC Record Protection 317 QUIC provides a record protection layer that is responsible for 318 authenticated encryption of packets. The record protection layer 319 uses keys provided by the TLS connection and authenticated encryption 320 to provide confidentiality and integrity protection for the content 321 of packets. 323 Different keys are used for QUIC and TLS record protection. Having 324 separate QUIC and TLS record protection means that TLS records can be 325 protected by two different keys. This redundancy is maintained for 326 the sake of simplicity. 328 4.1. Key Phases 330 The transition to use of a new QUIC key occurs immediately after 331 sending the TLS handshake messages that produced the key transition. 332 Every time that a new set of keys is used for protecting outbound 333 messages, the KEY_PHASE bit in the public flags is toggled. The 334 KEY_PHASE bit on unencrypted messages is 0. 336 The KEY_PHASE bit on the public flags is the most significant bit 337 (0x80). 339 The KEY_PHASE bit allows a recipient to detect a change in keying 340 material without needing to receive the message that triggers the 341 change. This avoids head-of-line blocking around transitions between 342 keys without relying on trial decryption. 344 The following transitions are defined: 346 o The client transitions to using 0-RTT keys after sending the 347 ClientHello. This causes the KEY_PHASE bit on packets sent by the 348 client to be set to 1. 350 o The server transitions to using 0-RTT keys before sending the 351 ServerHello, but only if the early data from the client is 352 accepted. This transition causes the KEY_PHASE bit on packets 353 sent by the server to be set to 1. If the server rejects 0-RTT 354 data, the server's handshake messages are sent without QUIC-level 355 record protection with a KEY_PHASE of 0. TLS handshake messages 356 will still be protected by TLS record protection based on the TLS 357 handshake traffic keys. 359 o The server transitions to using 1-RTT keys after sending its 360 Finished message. This causes the KEY_PHASE bit to be set to 0 if 361 early data was accepted, and 1 if the server rejected early data. 363 o The client transitions to 1-RTT keys after sending its Finished 364 message. Subsequent messages from the client will then have a 365 KEY_PHASE of 0 if 0-RTT data was sent, and 1 otherwise. 367 o Both peers start sending messages protected by a new key 368 immediately after sending a TLS KeyUpdate message. The value of 369 the KEY_PHASE bit is changed each time. 371 At each point, both keying material (see Section 4.2) and the AEAD 372 function used by TLS is interchanged with the values that are 373 currently in use for protecting outbound packets. Once a change of 374 keys has been made, packets with higher sequence numbers MUST use the 375 new keying material until a newer set of keys (and AEAD) are used. 376 The exception to this is that retransmissions of TLS handshake 377 packets MUST use the keys that they were originally protected with. 379 Once a packet protected by a new key has been received, a recipient 380 SHOULD retain the previous keys for a short period. Retaining old 381 keys allows the recipient to decode reordered packets around a change 382 in keys. Keys SHOULD be discarded when an endpoints has received all 383 packets with sequence numbers lower than the lowest sequence number 384 used for the new key, or when it determines that reordering of those 385 packets is unlikely. 0-RTT keys SHOULD be retained until the 386 handshake is complete. 388 The KEY_PHASE bit does not directly indicate which keys are in use. 389 Depending on whether 0-RTT data was sent and accepted, packets 390 protected with keys derived from the same secret might be marked with 391 different KEY_PHASE values. 393 4.1.1. Retransmission of TLS Handshake Messages 395 TLS handshake messages need to be retransmitted with the same level 396 of cryptographic protection that was originally used to protect them. 397 Newer keys cannot be used to protect QUIC packets that carry TLS 398 messages. 400 A client would be unable to decrypt retransmissions of a server's 401 handshake messages that are protected using the 1-RTT keys, since the 402 calculation of the application data keys depends on the contents of 403 the handshake messages. 405 This restriction means the creation of an exception to the 406 requirement to always use new keys for sending once they are 407 available. A server MUST mark the retransmitted handshake messages 408 with the same KEY_PHASE as the original messages to allow a recipient 409 to distinguish the messages. 411 4.1.2. Key Update 413 Once the TLS handshake is complete, the KEY_PHASE bit allows for the 414 processing of messages without having to receive the TLS KeyUpdate 415 message that triggers the key update. This allows endpoints to start 416 using updated keys immediately without the concern that a lost 417 KeyUpdate will cause their messages to be indecipherable to their 418 peer.. 420 An endpoint MUST NOT initiate more than one key update at a time. A 421 new key update cannot be sent until the endpoint has received a 422 matching KeyUpdate message from its peer; or, if the endpoint did not 423 initiate the original key update, it has received an acknowledgment 424 of its own KeyUpdate. 426 This ensures that there are at most two keys to distinguish between 427 at any one time, for which the KEY_PHASE bit is sufficient. 429 Initiating Peer Responding Peer 431 @M KeyUpdate 432 New Keys -> @N 433 @N QUIC Frames 434 --------> 435 KeyUpdate @N 436 <-------- 437 -- Initiating Peer can initiate another KeyUpdate -- 438 @N Acknowledgment 439 --------> 440 -- Responding Peer can initiate another KeyUpdate -- 442 Figure 4: Key Update 444 As shown in Figure 3 and Figure 4, there is never a situation where 445 there are more than two different sets of keying material that might 446 be received by a peer. 448 A server cannot initiate a key update until it has received the 449 client's Finished message. Otherwise, packets protected by the 450 updated keys could be confused for retransmissions of handshake 451 messages. A client cannot initiate a key update until it has 452 received an acknowledgment that its Finished message has been 453 received. 455 Note: This models the key changes in the handshake as a key update 456 initiated by the server, with the Finished message in the place of 457 KeyUpdate. 459 4.2. QUIC Key Expansion 461 The following table shows QUIC keys, when they are generated and the 462 TLS secret from which they are derived: 464 +-------+----------------------+----------------------------+ 465 | Key | TLS Secret | Phase | 466 +-------+----------------------+----------------------------+ 467 | 0-RTT | early_traffic_secret | "QUIC 0-RTT key expansion" | 468 | | | | 469 | 1-RTT | traffic_secret_N | "QUIC 1-RTT key expansion" | 470 +-------+----------------------+----------------------------+ 472 0-RTT keys are those keys that are used in resumed connections prior 473 to the completion of the TLS handshake. Data sent using 0-RTT keys 474 might be replayed and so has some restrictions on its use, see 475 Section 5.2. 0-RTT keys are used after sending or receiving a 476 ClientHello. 478 1-RTT keys are used after the TLS handshake completes. There are 479 potentially multiple sets of 1-RTT keys; new 1-RTT keys are created 480 by sending a TLS KeyUpdate message. 1-RTT keys are used after 481 sending a Finished or KeyUpdate message. 483 The complete key expansion uses the same process for key expansion as 484 defined in Section 7.3 of [I-D.ietf-tls-tls13]. For example, the 485 Client Write Key for the data sent immediately after sending the TLS 486 Finished message is: 488 label = "QUIC 1-RTT key expansion, client write key" 489 client_write = HKDF-Expand-Label(traffic_secret_0, label, 490 "", key_length) 492 This results in a label input to HKDF that includes a two-octet 493 length field, the string "TLS 1.3, QUIC 1-RTT key expansion, client 494 write key" and a zero octet. 496 The QUIC record protection initially starts without keying material. 497 When the TLS state machine produces the corresponding secret, new 498 keys are generated from the TLS connection and used to protect the 499 QUIC record protection. 501 The Authentication Encryption with Associated Data (AEAD) [RFC5116] 502 function used is the same one that is negotiated for use with the TLS 503 connection. For example, if TLS is using the 504 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, the AEAD_AES_128_GCM 505 function is used. 507 4.3. QUIC AEAD application 509 Regular QUIC packets are protected by an AEAD [RFC5116]. Version 510 negotiation and public reset packets are not protected. 512 Once TLS has provided a key, the contents of regular QUIC packets 513 immediately after any TLS messages have been sent are protected by 514 the AEAD selected by TLS. 516 The key, K, for the AEAD is either the Client Write Key or the Server 517 Write Key, derived as defined in Section 4.2. 519 The nonce, N, for the AEAD is formed by combining either the Client 520 Write IV or Server Write IV with the sequence numbers. The 48 bits 521 of the reconstructed QUIC sequence number (see Section 4.4) in 522 network byte order is left-padded with zeros to the N_MAX parameter 523 of the AEAD (see Section 4 of [RFC5116]). The exclusive OR of the 524 padded sequence number and the IV forms the AEAD nonce. 526 The associated data, A, for the AEAD is an empty sequence. 528 The input plaintext, P, for the AEAD is the contents of the QUIC 529 frame following the packet number, as described in 530 [I-D.hamilton-quic-transport-protocol] 532 The output ciphertext, C, of the AEAD is transmitted in place of P. 534 Prior to TLS providing keys, no record protection is performed and 535 the plaintext, P, is transmitted unmodified. 537 Note: QUIC defined a null-encryption that had an additional, hash- 538 based checksum for cleartext packets. This might be added here, 539 but it is more complex. 541 4.4. Sequence Number Reconstruction 543 Each peer maintains a 48-bit sequence number that is incremented with 544 every packet that is sent, including retransmissions. The least 545 significant 8-, 16-, 32-, or 48-bits of this number is encoded in the 546 QUIC sequence number field in every packet. 548 A receiver maintains the same values, but recovers values based on 549 the packets it receives. This is based on the sequence number of 550 packets that it has received. A simple scheme predicts the receive 551 sequence number of an incoming packet by incrementing the sequence 552 number of the most recent packet to be successfully decrypted by one 553 and expecting the sequence number to be within a range centered on 554 that value. 556 A more sophisticated algorithm can almost double the search space by 557 checking backwards from the most recent sequence for a received (or 558 abandoned) packet. If a packet was received, then the packet 559 contains a sequence number that is greater than the most recent 560 sequence number. If no such packet was found, the number is assumed 561 to be in the smaller window centered on the next sequence number, as 562 in the simpler scheme. 564 Note: QUIC has a single, contiguous sequence number space. In 565 comparison, TLS restarts its sequence number each time that record 566 protection keys are changed. The sequence number restart in TLS 567 ensures that a compromise of the current traffic keys does not 568 allow an attacker to truncate the data that is sent after a key 569 update by sending additional packets under the old key (causing 570 new packets to be discarded). QUIC does not assume a reliable 571 transport and is therefore required to handle attacks where 572 packets are dropped in other ways. TLS maintains a separate 573 sequence number that is used for record protection on the 574 connection that is hosted on stream 1. This sequence number is 575 reset according to the rules in the TLS protocol. 577 5. Pre-handshake QUIC Messages 579 Implementations MUST NOT exchange data on any stream other than 580 stream 1 prior to the completion of the TLS handshake. However, QUIC 581 requires the use of several types of frame for managing loss 582 detection and recovery. In addition, it might be useful to use the 583 data acquired during the exchange of unauthenticated messages for 584 congestion management. 586 This section generally only applies to TLS handshake messages from 587 both peers and acknowledgments of the packets carrying those 588 messages. In many cases, the need for servers to provide 589 acknowledgments is minimal, since the messages that clients send are 590 small and implicitly acknowledged by the server's responses. 592 The actions that a peer takes as a result of receiving an 593 unauthenticated packet needs to be limited. In particular, state 594 established by these packets cannot be retained once record 595 protection commences. 597 There are several approaches possible for dealing with 598 unauthenticated packets prior to handshake completion: 600 o discard and ignore them 602 o use them, but reset any state that is established once the 603 handshake completes 605 o use them and authenticate them afterwards; failing the handshake 606 if they can't be authenticated 608 o save them and use them when they can be properly authenticated 610 o treat them as a fatal error 612 Different strategies are appropriate for different types of data. 613 This document proposes that all strategies are possible depending on 614 the type of message. 616 o Transport parameters and options are made usable and authenticated 617 as part of the TLS handshake (see Section 6.2). 619 o Most unprotected messages are treated as fatal errors when 620 received except for the small number necessary to permit the 621 handshake to complete (see Section 5.1). 623 o Protected packets can either be discarded or saved and later used 624 (see Section 5.3). 626 5.1. Unprotected Frames Prior to Handshake Completion 628 This section describes the handling of messages that are sent and 629 received prior to the completion of the TLS handshake. 631 Sending and receiving unprotected messages is hazardous. Unless 632 expressly permitted, receipt of an unprotected message of any kind 633 MUST be treated as a fatal error. 635 5.1.1. STREAM Frames 637 "STREAM" frames for stream 1 are permitted. These carry the TLS 638 handshake messages. 640 Receiving unprotected "STREAM" frames for other streams MUST be 641 treated as a fatal error. 643 5.1.2. ACK Frames 645 "ACK" frames are permitted prior to the handshake being complete. 646 Information learned from "ACK" frames cannot be entirely relied upon, 647 since an attacker is able to inject these packets. Timing and packet 648 retransmission information from "ACK" frames is critical to the 649 functioning of the protocol, but these frames might be spoofed or 650 altered. 652 Endpoints MUST NOT use an unprotected "ACK" frame to acknowledge data 653 that was protected by 0-RTT or 1-RTT keys. An endpoint MUST ignore 654 an unprotected "ACK" frame if it claims to acknowledge data that was 655 protected data. Such an acknowledgement can only serve as a denial 656 of service, since an endpoint that can read protected data is always 657 permitted to send protected data. 659 An endpoint SHOULD use data from unprotected or 0-RTT-protected "ACK" 660 frames only during the initial handshake and while they have 661 insufficient information from 1-RTT-protected "ACK" frames. Once 662 sufficient information has been obtained from protected messages, 663 information obtained from less reliable sources can be discarded. 665 5.1.3. WINDOW_UPDATE Frames 667 "WINDOW_UPDATE" frames MUST NOT be sent unprotected. 669 Though data is exchanged on stream 1, the initial flow control window 670 is is sufficiently large to allow the TLS handshake to complete. 671 This limits the maximum size of the TLS handshake and would prevent a 672 server or client from using an abnormally large certificate chain. 674 Stream 1 is exempt from the connection-level flow control window. 676 5.1.4. Denial of Service with Unprotected Packets 678 Accepting unprotected - specifically unauthenticated - packets 679 presents a denial of service risk to endpoints. An attacker that is 680 able to inject unprotected packets can cause a recipient to drop even 681 protected packets with a matching sequence number. The spurious 682 packet shadows the genuine packet, causing the genuine packet to be 683 ignored as redundant. 685 Once the TLS handshake is complete, both peers MUST ignore 686 unprotected packets. The handshake is complete when the server 687 receives a client's Finished message and when a client receives an 688 acknowledgement that their Finished message was received. From that 689 point onward, unprotected messages can be safely dropped. Note that 690 the client could retransmit its Finished message to the server, so 691 the server cannot reject such a message. 693 Since only TLS handshake packets and acknowledgments are sent in the 694 clear, an attacker is able to force implementations to rely on 695 retransmission for packets that are lost or shadowed. Thus, an 696 attacker that intends to deny service to an endpoint has to drop or 697 shadow protected packets in order to ensure that their victim 698 continues to accept unprotected packets. The ability to shadow 699 packets means that an attacker does not need to be on path. 701 ISSUE: This would not be an issue if QUIC had a randomized starting 702 sequence number. If we choose to randomize, we fix this problem 703 and reduce the denial of service exposure to on-path attackers. 704 The only possible problem is in authenticating the initial value, 705 so that peers can be sure that they haven't missed an initial 706 message. 708 In addition to denying endpoints messages, an attacker to generate 709 packets that cause no state change in a recipient. See Section 7.2 710 for a discussion of these risks. 712 To avoid receiving TLS packets that contain no useful data, a TLS 713 implementation MUST reject empty TLS handshake records and any record 714 that is not permitted by the TLS state machine. Any TLS application 715 data or alerts - other than a single end_of_early_data at the 716 appropriate time - that is received prior to the end of the handshake 717 MUST be treated as a fatal error. 719 5.2. Use of 0-RTT Keys 721 If 0-RTT keys are available, the lack of replay protection means that 722 restrictions on their use are necessary to avoid replay attacks on 723 the protocol. 725 A client MUST only use 0-RTT keys to protect data that is idempotent. 726 A client MAY wish to apply additional restrictions on what data it 727 sends prior to the completion of the TLS handshake. A client 728 otherwise treats 0-RTT keys as equivalent to 1-RTT keys. 730 A client that receives an indication that its 0-RTT data has been 731 accepted by a server can send 0-RTT data until it receives all of the 732 server's handshake messages. A client SHOULD stop sending 0-RTT data 733 if it receives an indication that 0-RTT data has been rejected. In 734 addition to a ServerHello without an early_data extension, an 735 unprotected handshake message with a KEY_PHASE bit set to 0 indicates 736 that 0-RTT data has been rejected. 738 A client SHOULD send its end_of_early_data alert only after it has 739 received all of the server's handshake messages. Alternatively 740 phrased, a client is encouraged to use 0-RTT keys until 1-RTT keys 741 become available. This prevents stalling of the connection and 742 allows the client to send continuously. 744 A server MUST NOT use 0-RTT keys to protect anything other than TLS 745 handshake messages. Servers therefore treat packets protected with 746 0-RTT keys as equivalent to unprotected packets in determining what 747 is permissible to send. A server protects handshake messages using 748 the 0-RTT key if it decides to accept a 0-RTT key. A server MUST 749 still include the early_data extension in its ServerHello message. 751 This restriction prevents a server from responding to a request using 752 frames protected by the 0-RTT keys. This ensures that all 753 application data from the server are always protected with keys that 754 have forward secrecy. However, this results in head-of-line blocking 755 at the client because server responses cannot be decrypted until all 756 the server's handshake messages are received by the client. 758 5.3. Protected Frames Prior to Handshake Completion 760 Due to reordering and loss, protected packets might be received by an 761 endpoint before the final handshake messages are received. If these 762 can be decrypted successfully, such packets MAY be stored and used 763 once the handshake is complete. 765 Unless expressly permitted below, encrypted packets MUST NOT be used 766 prior to completing the TLS handshake, in particular the receipt of a 767 valid Finished message and any authentication of the peer. If 768 packets are processed prior to completion of the handshake, an 769 attacker might use the willingness of an implementation to use these 770 packets to mount attacks. 772 TLS handshake messages are covered by record protection during the 773 handshake, once key agreement has completed. This means that 774 protected messages need to be decrypted to determine if they are TLS 775 handshake messages or not. Similarly, "ACK" and "WINDOW_UPDATE" 776 frames might be needed to successfully complete the TLS handshake. 778 Any timestamps present in "ACK" frames MUST be ignored rather than 779 causing a fatal error. Timestamps on protected frames MAY be saved 780 and used once the TLS handshake completes successfully. 782 An endpoint MAY save the last protected "WINDOW_UPDATE" frame it 783 receives for each stream and apply the values once the TLS handshake 784 completes. Failing to do this might result in temporary stalling of 785 affected streams. 787 6. QUIC-Specific Additions to the TLS Handshake 789 QUIC uses the TLS handshake for more than just negotiation of 790 cryptographic parameters. The TLS handshake validates protocol 791 version selection, provides preliminary values for QUIC transport 792 parameters, and allows a server to perform return routeability checks 793 on clients. 795 6.1. Protocol and Version Negotiation 797 The QUIC version negotiation mechanism is used to negotiate the 798 version of QUIC that is used prior to the completion of the 799 handshake. However, this packet is not authenticated, enabling an 800 active attacker to force a version downgrade. 802 To ensure that a QUIC version downgrade is not forced by an attacker, 803 version information is copied into the TLS handshake, which provides 804 integrity protection for the QUIC negotiation. This does not prevent 805 version downgrade during the handshake, though it means that such a 806 downgrade causes a handshake failure. 808 Protocols that use the QUIC transport MUST use Application Layer 809 Protocol Negotiation (ALPN) [RFC7301]. The ALPN identifier for the 810 protocol MUST be specific to the QUIC version that it operates over. 811 When constructing a ClientHello, clients MUST include a list of all 812 the ALPN identifiers that they support, regardless of whether the 813 QUIC version that they have currently selected supports that 814 protocol. 816 Servers SHOULD select an application protocol based solely on the 817 information in the ClientHello, not using the QUIC version that the 818 client has selected. If the protocol that is selected is not 819 supported with the QUIC version that is in use, the server MUST 820 either send a QUIC version negotiation packet if this is possible, or 821 fail the connection otherwise. 823 6.2. QUIC Extension 825 QUIC defines an extension for use with TLS. That extension defines 826 transport-related parameters. This provides integrity protection for 827 these values. Including these in the TLS handshake also make the 828 values that a client sets available to a server one-round trip 829 earlier than parameters that are carried in QUIC frames. This 830 document does not define that extension. 832 6.3. Source Address Validation 834 QUIC implementations describe a source address token. This is an 835 opaque blob that a server might provide to clients when they first 836 use a given source address. The client returns this token in 837 subsequent messages as a return routeability check. That is, the 838 client returns this token to prove that it is able to receive packets 839 at the source address that it claims. This prevents the server from 840 being used in packet reflection attacks (see Section 7.1). 842 A source address token is opaque and consumed only by the server. 843 Therefore it can be included in the TLS 1.3 pre-shared key identifier 844 for 0-RTT handshakes. Servers that use 0-RTT are advised to provide 845 new pre-shared key identifiers after every handshake to avoid 846 linkability of connections by passive observers. Clients MUST use a 847 new pre-shared key identifier for every connection that they 848 initiate; if no pre-shared key identifier is available, then 849 resumption is not possible. 851 A server that is under load might include a source address token in 852 the cookie extension of a HelloRetryRequest. (Note: the current 853 version of TLS 1.3 does not include the ability to include a cookie 854 in HelloRetryRequest.) 856 6.4. Priming 0-RTT 858 QUIC uses TLS without modification. Therefore, it is possible to use 859 a pre-shared key that was obtained in a TLS connection over TCP to 860 enable 0-RTT in QUIC. Similarly, QUIC can provide a pre-shared key 861 that can be used to enable 0-RTT in TCP. 863 All the restrictions on the use of 0-RTT apply, and the certificate 864 MUST be considered valid for both connections, which will use 865 different protocol stacks and could use different port numbers. For 866 instance, HTTP/1.1 and HTTP/2 operate over TLS and TCP, whereas QUIC 867 operates over UDP. 869 Source address validation is not completely portable between 870 different protocol stacks. Even if the source IP address remains 871 constant, the port number is likely to be different. Packet 872 reflection attacks are still possible in this situation, though the 873 set of hosts that can initiate these attacks is greatly reduced. A 874 server might choose to avoid source address validation for such a 875 connection, or allow an increase to the amount of data that it sends 876 toward the client without source validation. 878 7. Security Considerations 880 There are likely to be some real clangers here eventually, but the 881 current set of issues is well captured in the relevant sections of 882 the main text. 884 Never assume that because it isn't in the security considerations 885 section it doesn't affect security. Most of this document does. 887 7.1. Packet Reflection Attack Mitigation 889 A small ClientHello that results in a large block of handshake 890 messages from a server can be used in packet reflection attacks to 891 amplify the traffic generated by an attacker. 893 Certificate caching [RFC7924] can reduce the size of the server's 894 handshake messages significantly. 896 A client SHOULD also pad [RFC7685] its ClientHello to at least 1024 897 octets (TODO: tune this value). A server is less likely to generate 898 a packet reflection attack if the data it sends is a small multiple 899 of the data it receives. A server SHOULD use a HelloRetryRequest if 900 the size of the handshake messages it sends is likely to exceed the 901 size of the ClientHello. 903 7.2. Peer Denial of Service 905 QUIC, TLS and HTTP/2 all contain a messages that have legitimate uses 906 in some contexts, but that can be abused to cause a peer to expend 907 processing resources without having any observable impact on the 908 state of the connection. If processing is disproportionately large 909 in comparison to the observable effects on bandwidth or state, then 910 this could allow a malicious peer to exhaust processing capacity 911 without consequence. 913 QUIC prohibits the sending of empty "STREAM" frames unless they are 914 marked with the FIN bit. This prevents "STREAM" frames from being 915 sent that only waste effort. 917 TLS records SHOULD always contain at least one octet of a handshake 918 messages or alert. Records containing only padding are permitted 919 during the handshake, but an excessive number might be used to 920 generate unnecessary work. Once the TLS handshake is complete, 921 endpoints SHOULD NOT send TLS application data records unless it is 922 to hide the length of QUIC records. QUIC packet protection does not 923 include any allowance for padding; padded TLS application data 924 records can be used to mask the length of QUIC frames. 926 While there are legitimate uses for some redundant packets, 927 implementations SHOULD track redundant packets and treat excessive 928 volumes of any non-productive packets as indicative of an attack. 930 8. IANA Considerations 932 This document has no IANA actions. Yet. 934 9. References 936 9.1. Normative References 938 [I-D.hamilton-quic-transport-protocol] 939 Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC: 940 A UDP-Based Multiplexed and Secure Transport", draft- 941 hamilton-quic-transport-protocol-00 (work in progress), 942 July 2016. 944 [I-D.ietf-tls-tls13] 945 Rescorla, E., "The Transport Layer Security (TLS) Protocol 946 Version 1.3", draft-ietf-tls-tls13-17 (work in progress), 947 October 2016. 949 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 950 Requirement Levels", BCP 14, RFC 2119, 951 DOI 10.17487/RFC2119, March 1997, 952 . 954 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 955 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 956 . 958 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 959 "Transport Layer Security (TLS) Application-Layer Protocol 960 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 961 July 2014, . 963 9.2. Informative References 965 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 966 RFC 793, DOI 10.17487/RFC0793, September 1981, 967 . 969 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 970 Protocol (HTTP/1.1): Message Syntax and Routing", 971 RFC 7230, DOI 10.17487/RFC7230, June 2014, 972 . 974 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 975 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 976 2014, . 978 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 979 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 980 DOI 10.17487/RFC7540, May 2015, 981 . 983 [RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello 984 Padding Extension", RFC 7685, DOI 10.17487/RFC7685, 985 October 2015, . 987 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 988 (TLS) Cached Information Extension", RFC 7924, 989 DOI 10.17487/RFC7924, July 2016, 990 . 992 Appendix A. Acknowledgments 994 Christian Huitema's knowledge of QUIC is far better than my own. 995 This would be even more inaccurate and useless if not for his 996 assistance. This document has variously benefited from a long series 997 of discussions with Jana Iyengar, Adam Langley, Roberto Peon, Eric 998 Rescorla, Ian Swett, and likely many others who are merely forgotten 999 by a faulty meat computer. 1001 Authors' Addresses 1003 Martin Thomson 1004 Mozilla 1006 Email: martin.thomson@gmail.com 1008 Ryan Hamilton 1009 Google 1011 Email: rch@google.com