idnits 2.17.1 draft-ietf-quic-tls-02.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 (March 13, 2017) is 2602 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-19 -- Possible downref: Non-RFC (?) normative reference: ref. 'QUIC-TRANSPORT' ** 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 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC M. Thomson, Ed. 3 Internet-Draft Mozilla 4 Intended status: Standards Track S. Turner, Ed. 5 Expires: September 14, 2017 sn3rd 6 March 13, 2017 8 Using Transport Layer Security (TLS) to Secure QUIC 9 draft-ietf-quic-tls-02 11 Abstract 13 This document describes how Transport Layer Security (TLS) can be 14 used to secure QUIC. 16 Note to Readers 18 Discussion of this draft takes place on the QUIC working group 19 mailing list (quic@ietf.org), which is archived at 20 https://mailarchive.ietf.org/arch/search/?email_list=quic . 22 Working Group information can be found at https://github.com/quicwg ; 23 source code and issues list for this draft can be found at 24 https://github.com/quicwg/base-drafts/labels/tls . 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 14, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 62 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. TLS Overview . . . . . . . . . . . . . . . . . . . . . . 5 64 3.2. TLS Handshake . . . . . . . . . . . . . . . . . . . . . . 6 65 4. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. Handshake and Setup Sequence . . . . . . . . . . . . . . 8 67 4.2. Interface to TLS . . . . . . . . . . . . . . . . . . . . 9 68 4.2.1. Handshake Interface . . . . . . . . . . . . . . . . . 9 69 4.2.2. Source Address Validation . . . . . . . . . . . . . . 11 70 4.2.3. Key Ready Events . . . . . . . . . . . . . . . . . . 11 71 4.2.4. Secret Export . . . . . . . . . . . . . . . . . . . . 12 72 4.2.5. TLS Interface Summary . . . . . . . . . . . . . . . . 12 73 4.3. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 13 74 4.4. ClientHello Size . . . . . . . . . . . . . . . . . . . . 13 75 4.5. Peer Authentication . . . . . . . . . . . . . . . . . . . 14 76 4.6. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 14 77 5. QUIC Packet Protection . . . . . . . . . . . . . . . . . . . 14 78 5.1. Installing New Keys . . . . . . . . . . . . . . . . . . . 15 79 5.2. QUIC Key Expansion . . . . . . . . . . . . . . . . . . . 15 80 5.2.1. 0-RTT Secret . . . . . . . . . . . . . . . . . . . . 15 81 5.2.2. 1-RTT Secrets . . . . . . . . . . . . . . . . . . . . 16 82 5.2.3. Packet Protection Key and IV . . . . . . . . . . . . 17 83 5.3. QUIC AEAD Usage . . . . . . . . . . . . . . . . . . . . . 18 84 5.4. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 19 85 5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 19 86 6. Key Phases . . . . . . . . . . . . . . . . . . . . . . . . . 20 87 6.1. Packet Protection for the TLS Handshake . . . . . . . . . 20 88 6.1.1. Initial Key Transitions . . . . . . . . . . . . . . . 21 89 6.1.2. Retransmission and Acknowledgment of Unprotected 90 Packets . . . . . . . . . . . . . . . . . . . . . . . 22 91 6.2. Key Update . . . . . . . . . . . . . . . . . . . . . . . 22 92 7. Client Address Validation . . . . . . . . . . . . . . . . . . 24 93 7.1. HelloRetryRequest Address Validation . . . . . . . . . . 24 94 7.2. NewSessionTicket Address Validation . . . . . . . . . . . 25 95 7.3. Address Validation Token Integrity . . . . . . . . . . . 26 97 8. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 26 98 8.1. Unprotected Packets Prior to Handshake Completion . . . . 27 99 8.1.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 27 100 8.1.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 27 101 8.1.3. WINDOW_UPDATE Frames . . . . . . . . . . . . . . . . 28 102 8.1.4. Denial of Service with Unprotected Packets . . . . . 28 103 8.2. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 29 104 8.3. Receiving Out-of-Order Protected Frames . . . . . . . . . 29 105 9. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 30 106 9.1. Protocol and Version Negotiation . . . . . . . . . . . . 30 107 9.2. QUIC Transport Parameters Extension . . . . . . . . . . . 31 108 9.3. Priming 0-RTT . . . . . . . . . . . . . . . . . . . . . . 31 109 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 110 10.1. Packet Reflection Attack Mitigation . . . . . . . . . . 32 111 10.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 32 112 11. Error codes . . . . . . . . . . . . . . . . . . . . . . . . . 33 113 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 114 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 115 13.1. Normative References . . . . . . . . . . . . . . . . . . 33 116 13.2. Informative References . . . . . . . . . . . . . . . . . 34 117 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 35 118 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 35 119 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35 120 C.1. Since draft-ietf-quic-tls-01: . . . . . . . . . . . . . . 35 121 C.2. Since draft-ietf-quic-tls-00: . . . . . . . . . . . . . . 35 122 C.3. Since draft-thomson-quic-tls-01: . . . . . . . . . . . . 36 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 125 1. Introduction 127 QUIC [QUIC-TRANSPORT] provides a multiplexed transport. When used 128 for HTTP [RFC7230] semantics [QUIC-HTTP] it provides several key 129 advantages over HTTP/1.1 [RFC7230] or HTTP/2 [RFC7540] over TCP 130 [RFC0793]. 132 This document describes how QUIC can be secured using Transport Layer 133 Security (TLS) version 1.3 [I-D.ietf-tls-tls13]. TLS 1.3 provides 134 critical latency improvements for connection establishment over 135 previous versions. Absent packet loss, most new connections can be 136 established and secured within a single round trip; on subsequent 137 connections between the same client and server, the client can often 138 send application data immediately, that is, using a zero round trip 139 setup. 141 This document describes how the standardized TLS 1.3 can act a 142 security component of QUIC. The same design could work for TLS 1.2, 143 though few of the benefits QUIC provides would be realized due to the 144 handshake latency in versions of TLS prior to 1.3. 146 2. Notational Conventions 148 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 149 document. It's not shouting; when they are capitalized, they have 150 the special meaning defined in [RFC2119]. 152 This document uses the terminology established in [QUIC-TRANSPORT]. 154 For brevity, the acronym TLS is used to refer to TLS 1.3. 156 TLS terminology is used when referring to parts of TLS. Though TLS 157 assumes a continuous stream of octets, it divides that stream into 158 _records_. Most relevant to QUIC are the records that contain TLS 159 _handshake messages_, which are discrete messages that are used for 160 key agreement, authentication and parameter negotiation. Ordinarily, 161 TLS records can also contain _application data_, though in the QUIC 162 usage there is no use of TLS application data. 164 3. Protocol Overview 166 QUIC [QUIC-TRANSPORT] assumes responsibility for the confidentiality 167 and integrity protection of packets. For this it uses keys derived 168 from a TLS 1.3 connection [I-D.ietf-tls-tls13]; QUIC also relies on 169 TLS 1.3 for authentication and negotiation of parameters that are 170 critical to security and performance. 172 Rather than a strict layering, these two protocols are co-dependent: 173 QUIC uses the TLS handshake; TLS uses the reliability and ordered 174 delivery provided by QUIC streams. 176 This document defines how QUIC interacts with TLS. This includes a 177 description of how TLS is used, how keying material is derived from 178 TLS, and the application of that keying material to protect QUIC 179 packets. Figure 1 shows the basic interactions between TLS and QUIC, 180 with the QUIC packet protection being called out specially. 182 +------------+ +------------+ 183 | |------ Handshake ------>| | 184 | |<-- Validate Address ---| | 185 | |-- OK/Error/Validate -->| | 186 | |<----- Handshake -------| | 187 | QUIC |------ Validate ------->| TLS | 188 | | | | 189 | |<------ 0-RTT OK -------| | 190 | |<------ 1-RTT OK -------| | 191 | |<--- Handshake Done ----| | 192 +------------+ +------------+ 193 | ^ ^ | 194 | Protect | Protected | | 195 v | Packet | | 196 +------------+ / / 197 | QUIC | / / 198 | Packet |-------- Get Secret -------' / 199 | Protection |<-------- Secret -----------' 200 +------------+ 202 Figure 1: QUIC and TLS Interactions 204 The initial state of a QUIC connection has packets exchanged without 205 any form of protection. In this state, QUIC is limited to using 206 stream 1 and associated packets. Stream 1 is reserved for a TLS 207 connection. This is a complete TLS connection as it would appear 208 when layered over TCP; the only difference is that QUIC provides the 209 reliability and ordering that would otherwise be provided by TCP. 211 At certain points during the TLS handshake, keying material is 212 exported from the TLS connection for use by QUIC. This keying 213 material is used to derive packet protection keys. Details on how 214 and when keys are derived and used are included in Section 5. 216 This arrangement means that some TLS messages receive redundant 217 protection from both the QUIC packet protection and the TLS record 218 protection. These messages are limited in number; the TLS connection 219 is rarely needed once the handshake completes. 221 3.1. TLS Overview 223 TLS provides two endpoints a way to establish a means of 224 communication over an untrusted medium (that is, the Internet) that 225 ensures that messages they exchange cannot be observed, modified, or 226 forged. 228 TLS features can be separated into two basic functions: an 229 authenticated key exchange and record protection. QUIC primarily 230 uses the authenticated key exchange provided by TLS but provides its 231 own packet protection. 233 The TLS authenticated key exchange occurs between two entities: 234 client and server. The client initiates the exchange and the server 235 responds. If the key exchange completes successfully, both client 236 and server will agree on a secret. TLS supports both pre-shared key 237 (PSK) and Diffie-Hellman (DH) key exchanges. PSK is the basis for 238 0-RTT; the latter provides perfect forward secrecy (PFS) when the DH 239 keys are destroyed. 241 After completing the TLS handshake, the client will have learned and 242 authenticated an identity for the server and the server is optionally 243 able to learn and authenticate an identity for the client. TLS 244 supports X.509 certificate-based authentication [RFC5280] for both 245 server and client. 247 The TLS key exchange is resistent to tampering by attackers and it 248 produces shared secrets that cannot be controlled by either 249 participating peer. 251 3.2. TLS Handshake 253 TLS 1.3 provides two basic handshake modes of interest to QUIC: 255 o A full, 1-RTT handshake in which the client is able to send 256 application data after one round trip and the server immediately 257 after receiving the first handshake message from the client. 259 o A 0-RTT handshake in which the client uses information it has 260 previously learned about the server to send immediately. This 261 data can be replayed by an attacker so it MUST NOT carry a self- 262 contained trigger for any non-idempotent action. 264 A simplified TLS 1.3 handshake with 0-RTT application data is shown 265 in Figure 2, see [I-D.ietf-tls-tls13] for more options and details. 267 Client Server 269 ClientHello 270 (0-RTT Application Data) --------> 271 ServerHello 272 {EncryptedExtensions} 273 {Finished} 274 <-------- [Application Data] 275 (EndOfEarlyData) 276 {Finished} --------> 278 [Application Data] <-------> [Application Data] 280 Figure 2: TLS Handshake with 0-RTT 282 This 0-RTT handshake is only possible if the client and server have 283 previously communicated. In the 1-RTT handshake, the client is 284 unable to send protected application data until it has received all 285 of the handshake messages sent by the server. 287 Two additional variations on this basic handshake exchange are 288 relevant to this document: 290 o The server can respond to a ClientHello with a HelloRetryRequest, 291 which adds an additional round trip prior to the basic exchange. 292 This is needed if the server wishes to request a different key 293 exchange key from the client. HelloRetryRequest is also used to 294 verify that the client is correctly able to receive packets on the 295 address it claims to have (see [QUIC-TRANSPORT]). 297 o A pre-shared key mode can be used for subsequent handshakes to 298 avoid public key operations. This is the basis for 0-RTT data, 299 even if the remainder of the connection is protected by a new 300 Diffie-Hellman exchange. 302 4. TLS Usage 304 QUIC reserves stream 1 for a TLS connection. Stream 1 contains a 305 complete TLS connection, which includes the TLS record layer. Other 306 than the definition of a QUIC-specific extension (see Section-TBD), 307 TLS is unmodified for this use. This means that TLS will apply 308 confidentiality and integrity protection to its records. In 309 particular, TLS record protection is what provides confidentiality 310 protection for the TLS handshake messages sent by the server. 312 QUIC permits a client to send frames on streams starting from the 313 first packet. The initial packet from a client contains a stream 314 frame for stream 1 that contains the first TLS handshake messages 315 from the client. This allows the TLS handshake to start with the 316 first packet that a client sends. 318 QUIC packets are protected using a scheme that is specific to QUIC, 319 see Section 5. Keys are exported from the TLS connection when they 320 become available using a TLS exporter (see Section 7.3.3 of 321 [I-D.ietf-tls-tls13] and Section 5.2). After keys are exported from 322 TLS, QUIC manages its own key schedule. 324 4.1. Handshake and Setup Sequence 326 The integration of QUIC with a TLS handshake is shown in more detail 327 in Figure 3. QUIC "STREAM" frames on stream 1 carry the TLS 328 handshake. QUIC performs loss recovery [QUIC-RECOVERY] for this 329 stream and ensures that TLS handshake messages are delivered in the 330 correct order. 332 Client Server 334 @C QUIC STREAM Frame(s) <1>: 335 ClientHello 336 + QUIC Extension 337 --------> 338 0-RTT Key => @0 340 @0 QUIC STREAM Frame(s) : 341 Replayable QUIC Frames 342 --------> 344 QUIC STREAM Frame <1>: @C 345 ServerHello 346 {TLS Handshake Messages} 347 <-------- 348 1-RTT Key => @1 350 QUIC Frames @1 351 <-------- 352 @C QUIC STREAM Frame(s) <1>: 353 (EndOfEarlyData) 354 {Finished} 355 --------> 357 @1 QUIC Frames <-------> QUIC Frames @1 359 Figure 3: QUIC over TLS Handshake 361 In Figure 3, symbols mean: 363 o "<" and ">" enclose stream numbers. 365 o "@" indicates the key phase that is currently used for protecting 366 QUIC packets. 368 o "(" and ")" enclose messages that are protected with TLS 0-RTT 369 handshake or application keys. 371 o "{" and "}" enclose messages that are protected by the TLS 372 Handshake keys. 374 If 0-RTT is not attempted, then the client does not send packets 375 protected by the 0-RTT key (@0). In that case, the only key 376 transition on the client is from unprotected packets (@C) to 1-RTT 377 protection (@1), which happens after it sends its final set of TLS 378 handshake messages. 380 The server sends TLS handshake messages without protection (@C). The 381 server transitions from no protection (@C) to full 1-RTT protection 382 (@1) after it sends the last of its handshake messages. 384 Some TLS handshake messages are protected by the TLS handshake record 385 protection. These keys are not exported from the TLS connection for 386 use in QUIC. QUIC packets from the server are sent in the clear 387 until the final transition to 1-RTT keys. 389 The client transitions from cleartext (@C) to 0-RTT keys (@0) when 390 sending 0-RTT data, and subsequently to to 1-RTT keys (@1) after its 391 second flight of TLS handshake messages. This creates the potential 392 for unprotected packets to be received by a server in close proximity 393 to packets that are protected with 1-RTT keys. 395 More information on key transitions is included in Section 6.1. 397 4.2. Interface to TLS 399 As shown in Figure 1, the interface from QUIC to TLS consists of four 400 primary functions: Handshake, Source Address Validation, Key Ready 401 Events, and Secret Export. 403 Additional functions might be needed to configure TLS. 405 4.2.1. Handshake Interface 407 In order to drive the handshake, TLS depends on being able to send 408 and receive handshake messages on stream 1. There are two basic 409 functions on this interface: one where QUIC requests handshake 410 messages and one where QUIC provides handshake packets. 412 Before starting the handshake QUIC provides TLS with the transport 413 parameters (see Section 9.2) that it wishes to carry. 415 A QUIC client starts TLS by requesting TLS handshake octets from TLS. 416 The client acquires handshake octets before sending its first packet. 418 A QUIC server starts the process by providing TLS with stream 1 419 octets. 421 Each time that an endpoint receives data on stream 1, it delivers the 422 octets to TLS if it is able. Each time that TLS is provided with new 423 data, new handshake octets are requested from TLS. TLS might not 424 provide any octets if the handshake messages it has received are 425 incomplete or it has no data to send. 427 Once the TLS handshake is complete, this is indicated to QUIC along 428 with any final handshake octets that TLS needs to send. TLS also 429 provides QUIC with the transport parameters that the peer advertised 430 during the handshake. 432 Once the handshake is complete, TLS becomes passive. TLS can still 433 receive data from its peer and respond in kind, but it will not need 434 to send more data unless specifically requested - either by an 435 application or QUIC. One reason to send data is that the server 436 might wish to provide additional or updated session tickets to a 437 client. 439 When the handshake is complete, QUIC only needs to provide TLS with 440 any data that arrives on stream 1. In the same way that is done 441 during the handshake, new data is requested from TLS after providing 442 received data. 444 Important: Until the handshake is reported as complete, the 445 connection and key exchange are not properly authenticated at the 446 server. Even though 1-RTT keys are available to a server after 447 receiving the first handshake messages from a client, the server 448 cannot consider the client to be authenticated until it receives 449 and validates the client's Finished message. 451 The requirement for the server to wait for the client Finished 452 message creates a dependency on that message being delivered. A 453 client can avoid the potential for head-of-line blocking that this 454 implies by sending a copy of the STREAM frame that carries the 455 Finished message in multiple packets. This enables immediate 456 server processing for those packets. 458 4.2.2. Source Address Validation 460 During the processing of the TLS ClientHello, TLS requests that the 461 transport make a decision about whether to request source address 462 validation from the client. 464 An initial TLS ClientHello that resumes a session includes an address 465 validation token in the session ticket; this includes all attempts at 466 0-RTT. If the client does not attempt session resumption, no token 467 will be present. While processing the initial ClientHello, TLS 468 provides QUIC with any token that is present. In response, QUIC 469 provides one of three responses: 471 o proceed with the connection, 473 o ask for client address validation, or 475 o abort the connection. 477 If QUIC requests source address validation, it also provides a new 478 address validation token. TLS includes that along with any 479 information it requires in the cookie extension of a TLS 480 HelloRetryRequest message. In the other cases, the connection either 481 proceeds or terminates with a handshake error. 483 The client echoes the cookie extension in a second ClientHello. A 484 ClientHello that contains a valid cookie extension will be always be 485 in response to a HelloRetryRequest. If address validation was 486 requested by QUIC, then this will include an address validation 487 token. TLS makes a second address validation request of QUIC, 488 including the value extracted from the cookie extension. In response 489 to this request, QUIC cannot ask for client address validation, it 490 can only abort or permit the connection attempt to proceed. 492 QUIC can provide a new address validation token for use in session 493 resumption at any time after the handshake is complete. Each time a 494 new token is provided TLS generates a NewSessionTicket message, with 495 the token included in the ticket. 497 See Section 7 for more details on client address validation. 499 4.2.3. Key Ready Events 501 TLS provides QUIC with signals when 0-RTT and 1-RTT keys are ready 502 for use. These events are not asynchronous, they always occur 503 immediately after TLS is provided with new handshake octets, or after 504 TLS produces handshake octets. 506 When TLS completed its handshake, 1-RTT keys can be provided to QUIC. 507 On both client and server, this occurs after sending the TLS Finished 508 message. 510 This ordering means that there could be frames that carry TLS 511 handshake messages ready to send at the same time that application 512 data is available. An implementation MUST ensure that TLS handshake 513 messages are always sent in cleartext packets. Separate packets are 514 required for data that needs protection from 1-RTT keys. 516 If 0-RTT is possible, it is ready after the client sends a TLS 517 ClientHello message or the server receives that message. After 518 providing a QUIC client with the first handshake octets, the TLS 519 stack might signal that 0-RTT keys are ready. On the server, after 520 receiving handshake octets that contain a ClientHello message, a TLS 521 server might signal that 0-RTT keys are available. 523 1-RTT keys are used for packets in both directions. 0-RTT keys are 524 only used to protect packets sent by the client. 526 4.2.4. Secret Export 528 Details how secrets are exported from TLS are included in 529 Section 5.2. 531 4.2.5. TLS Interface Summary 533 Figure 4 summarizes the exchange between QUIC and TLS for both client 534 and server. 536 Client Server 538 Get Handshake 539 0-RTT Key Ready 540 --- send/receive ---> 541 Handshake Received 542 0-RTT Key Ready 543 Get Handshake 544 1-RTT Keys Ready 545 <--- send/receive --- 546 Handshake Received 547 Get Handshake 548 Handshake Complete 549 1-RTT Keys Ready 550 --- send/receive ---> 551 Handshake Received 552 Get Handshake 553 Handshake Complete 554 <--- send/receive --- 555 Handshake Received 556 Get Handshake 558 Figure 4: Interaction Summary between QUIC and TLS 560 4.3. TLS Version 562 This document describes how TLS 1.3 [I-D.ietf-tls-tls13] is used with 563 QUIC. 565 In practice, the TLS handshake will negotiate a version of TLS to 566 use. This could result in a newer version of TLS than 1.3 being 567 negotiated if both endpoints support that version. This is 568 acceptable provided that the features of TLS 1.3 that are used by 569 QUIC are supported by the newer version. 571 A badly configured TLS implementation could negotiate TLS 1.2 or 572 another older version of TLS. An endpoint MUST terminate the 573 connection if a version of TLS older than 1.3 is negotiated. 575 4.4. ClientHello Size 577 QUIC requires that the initial handshake packet from a client fit 578 within a single packet of at least 1280 octets. With framing and 579 packet overheads this value could be reduced. 581 A TLS ClientHello can fit within this limit with ample space 582 remaining. However, there are several variables that could cause 583 this limit to be exceeded. Implementations are reminded that large 584 session tickets or HelloRetryRequest cookies, multiple or large key 585 shares, and long lists of supported ciphers, signature algorithms, 586 versions, QUIC transport parameters, and other negotiable parameters 587 and extensions could cause this message to grow. 589 For servers, the size of the session tickets and HelloRetryRequest 590 cookie extension can have an effect on a client's ability to connect. 591 Choosing a small value increases the probability that these values 592 can be successfully used by a client. 594 A TLS implementation does not need to enforce this size constraint. 595 QUIC padding can be used to reach this size, meaning that a TLS 596 server is unlikely to receive a large ClientHello message. 598 4.5. Peer Authentication 600 The requirements for authentication depend on the application 601 protocol that is in use. TLS provides server authentication and 602 permits the server to request client authentication. 604 A client MUST authenticate the identity of the server. This 605 typically involves verification that the identity of the server is 606 included in a certificate and that the certificate is issued by a 607 trusted entity (see for example [RFC2818]). 609 A server MAY request that the client authenticate during the 610 handshake. A server MAY refuse a connection if the client is unable 611 to authenticate when requested. The requirements for client 612 authentication vary based on application protocol and deployment. 614 A server MUST NOT use post-handshake client authentication (see 615 Section 4.6.2 of [I-D.ietf-tls-tls13]). 617 4.6. TLS Errors 619 Errors in the TLS connection SHOULD be signaled using TLS alerts on 620 stream 1. A failure in the handshake MUST be treated as a QUIC 621 connection error of type TLS_HANDSHAKE_FAILED. Once the handshake is 622 complete, an error in the TLS connection that causes a TLS alert to 623 be sent or received MUST be treated as a QUIC connection error of 624 type TLS_FATAL_ALERT_GENERATED or TLS_FATAL_ALERT_RECEIVED 625 respectively. 627 5. QUIC Packet Protection 629 QUIC packet protection provides authenticated encryption of packets. 630 This provides confidentiality and integrity protection for the 631 content of packets (see Section 5.3). Packet protection uses keys 632 that are exported from the TLS connection (see Section 5.2). 634 Different keys are used for QUIC packet protection and TLS record 635 protection. Having separate QUIC and TLS record protection means 636 that TLS records can be protected by two different keys. This 637 redundancy is limited to only a few TLS records, and is maintained 638 for the sake of simplicity. 640 5.1. Installing New Keys 642 As TLS reports the availability of keying material, the packet 643 protection keys and initialization vectors (IVs) are updated (see 644 Section 5.2). The selection of AEAD function is also updated to 645 match the AEAD negotiated by TLS. 647 For packets other than any unprotected handshake packets (see 648 Section 6.1), once a change of keys has been made, packets with 649 higher packet numbers MUST use the new keying material. The 650 KEY_PHASE bit on these packets is inverted each time new keys are 651 installed to signal the use of the new keys to the recipient (see 652 Section 6 for details). 654 An endpoint retransmits stream data in a new packet. New packets 655 have new packet numbers and use the latest packet protection keys. 656 This simplifies key management when there are key updates (see 657 Section 6.2). 659 5.2. QUIC Key Expansion 661 QUIC uses a system of packet protection secrets, keys and IVs that 662 are modelled on the system used in TLS [I-D.ietf-tls-tls13]. The 663 secrets that QUIC uses as the basis of its key schedule are obtained 664 using TLS exporters (see Section 7.3.3 of [I-D.ietf-tls-tls13]). 666 QUIC uses HKDF with the same hash function negotiated by TLS for key 667 derivation. For example, if TLS is using the TLS_AES_128_GCM_SHA256, 668 the SHA-256 hash function is used. 670 5.2.1. 0-RTT Secret 672 0-RTT keys are those keys that are used in resumed connections prior 673 to the completion of the TLS handshake. Data sent using 0-RTT keys 674 might be replayed and so has some restrictions on its use, see 675 Section 8.2. 0-RTT keys are used after sending or receiving a 676 ClientHello. 678 The secret is exported from TLS using the exporter label "EXPORTER- 679 QUIC 0-RTT Secret" and an empty context. The size of the secret MUST 680 be the size of the hash output for the PRF hash function negotiated 681 by TLS. This uses the TLS early_exporter_secret. The QUIC 0-RTT 682 secret is only used for protection of packets sent by the client. 684 client_0rtt_secret 685 = TLS-Exporter("EXPORTER-QUIC 0-RTT Secret" 686 "", Hash.length) 688 5.2.2. 1-RTT Secrets 690 1-RTT keys are used by both client and server after the TLS handshake 691 completes. There are two secrets used at any time: one is used to 692 derive packet protection keys for packets sent by the client, the 693 other for packet protection keys on packets sent by the server. 695 The initial client packet protection secret is exported from TLS 696 using the exporter label "EXPORTER-QUIC client 1-RTT Secret"; the 697 initial server packet protection secret uses the exporter label 698 "EXPORTER-QUIC server 1-RTT Secret". Both exporters use an empty 699 context. The size of the secret MUST be the size of the hash output 700 for the PRF hash function negotiated by TLS. 702 client_pp_secret_0 703 = TLS-Exporter("EXPORTER-QUIC client 1-RTT Secret" 704 "", Hash.length) 705 server_pp_secret_0 706 = TLS-Exporter("EXPORTER-QUIC server 1-RTT Secret" 707 "", Hash.length) 709 These secrets are used to derive the initial client and server packet 710 protection keys. 712 After a key update (see Section 6.2), these secrets are updated using 713 the HKDF-Expand-Label function defined in Section 7.1 of 714 [I-D.ietf-tls-tls13]. HKDF-Expand-Label uses the PRF hash function 715 negotiated by TLS. The replacement secret is derived using the 716 existing Secret, a Label of "QUIC client 1-RTT Secret" for the client 717 and "QUIC server 1-RTT Secret" for the server, an empty HashValue, 718 and the same output Length as the hash function selected by TLS for 719 its PRF. 721 client_pp_secret_ 722 = HKDF-Expand-Label(client_pp_secret_, 723 "QUIC client 1-RTT Secret", 724 "", Hash.length) 725 server_pp_secret_ 726 = HKDF-Expand-Label(server_pp_secret_, 727 "QUIC server 1-RTT Secret", 728 "", Hash.length) 730 This allows for a succession of new secrets to be created as needed. 732 HKDF-Expand-Label uses HKDF-Expand [RFC5869] with a specially 733 formatted info parameter. The info parameter that includes the 734 output length (in this case, the size of the PRF hash output) encoded 735 on two octets in network byte order, the length of the prefixed Label 736 as a single octet, the value of the Label prefixed with "TLS 1.3, ", 737 and a zero octet to indicate an empty HashValue. For example, the 738 client packet protection secret uses an info parameter of: 740 info = (HashLen / 256) || (HashLen % 256) || 0x21 || 741 "TLS 1.3, QUIC client 1-RTT secret" || 0x00 743 5.2.3. Packet Protection Key and IV 745 The complete key expansion uses an identical process for key 746 expansion as defined in Section 7.3 of [I-D.ietf-tls-tls13], using 747 different values for the input secret. QUIC uses the AEAD function 748 negotiated by TLS. 750 The packet protection key and IV used to protect the 0-RTT packets 751 sent by a client use the QUIC 0-RTT secret. This uses the HKDF- 752 Expand-Label with the PRF hash function negotiated by TLS. 754 The length of the output is determined by the requirements of the 755 AEAD function selected by TLS. The key length is the AEAD key size. 756 As defined in Section 5.3 of [I-D.ietf-tls-tls13], the IV length is 757 the larger of 8 or N_MIN (see Section 4 of [RFC5116]). 759 client_0rtt_key = HKDF-Expand-Label(client_0rtt_secret, 760 "key", "", key_length) 761 client_0rtt_iv = HKDF-Expand-Label(client_0rtt_secret, 762 "iv", "", iv_length) 764 Similarly, the packet protection key and IV used to protect 1-RTT 765 packets sent by both client and server use the current packet 766 protection secret. 768 client_pp_key_ = HKDF-Expand-Label(client_pp_secret_, 769 "key", "", key_length) 770 client_pp_iv_ = HKDF-Expand-Label(client_pp_secret_, 771 "iv", "", iv_length) 772 server_pp_key_ = HKDF-Expand-Label(server_pp_secret_, 773 "key", "", key_length) 774 server_pp_iv_ = HKDF-Expand-Label(server_pp_secret_, 775 "iv", "", iv_length) 777 The client protects (or encrypts) packets with the client packet 778 protection key and IV; the server protects packets with the server 779 packet protection key. 781 The QUIC record protection initially starts without keying material. 782 When the TLS state machine reports that the ClientHello has been 783 sent, the 0-RTT keys can be generated and installed for writing. 784 When the TLS state machine reports completion of the handshake, the 785 1-RTT keys can be generated and installed for writing. 787 5.3. QUIC AEAD Usage 789 The Authentication Encryption with Associated Data (AEAD) [RFC5116] 790 function used for QUIC packet protection is AEAD that is negotiated 791 for use with the TLS connection. For example, if TLS is using the 792 TLS_AES_128_GCM_SHA256, the AEAD_AES_128_GCM function is used. 794 Regular QUIC packets are protected by an AEAD [RFC5116]. Version 795 negotiation and public reset packets are not protected. 797 Once TLS has provided a key, the contents of regular QUIC packets 798 immediately after any TLS messages have been sent are protected by 799 the AEAD selected by TLS. 801 The key, K, for the AEAD is either the client packet protection key 802 (client_pp_key_n) or the server packet protection key 803 (server_pp_key_n), derived as defined in Section 5.2. 805 The nonce, N, for the AEAD is formed by combining either the packet 806 protection IV (either client_pp_iv_n or server_pp_iv_n) with packet 807 numbers. The 64 bits of the reconstructed QUIC packet number in 808 network byte order is left-padded with zeros to the size of the IV. 809 The exclusive OR of the padded packet number and the IV forms the 810 AEAD nonce. 812 The associated data, A, for the AEAD is the contents of the QUIC 813 header, starting from the flags octet in the common header. 815 The input plaintext, P, for the AEAD is the contents of the QUIC 816 frame following the packet number, as described in [QUIC-TRANSPORT]. 818 The output ciphertext, C, of the AEAD is transmitted in place of P. 820 Prior to TLS providing keys, no record protection is performed and 821 the plaintext, P, is transmitted unmodified. 823 5.4. Packet Numbers 825 QUIC has a single, contiguous packet number space. In comparison, 826 TLS restarts its sequence number each time that record protection 827 keys are changed. The sequence number restart in TLS ensures that a 828 compromise of the current traffic keys does not allow an attacker to 829 truncate the data that is sent after a key update by sending 830 additional packets under the old key (causing new packets to be 831 discarded). 833 QUIC does not assume a reliable transport and is required to handle 834 attacks where packets are dropped in other ways. QUIC is therefore 835 not affected by this form of truncation. 837 The QUIC packet number is not reset and it is not permitted to go 838 higher than its maximum value of 2^64-1. This establishes a hard 839 limit on the number of packets that can be sent. 841 Some AEAD functions have limits for how many packets can be encrypted 842 under the same key and IV (see for example [AEBounds]). This might 843 be lower than the packet number limit. An endpoint MUST initiate a 844 key update (Section 6.2) prior to exceeding any limit set for the 845 AEAD that is in use. 847 TLS maintains a separate sequence number that is used for record 848 protection on the connection that is hosted on stream 1. This 849 sequence number is not visible to QUIC. 851 5.5. Receiving Protected Packets 853 Once an endpoint successfully receives a packet with a given packet 854 number, it MUST discard all packets with higher packet numbers if 855 they cannot be successfully unprotected with either the same key, or 856 - if there is a key update - the next packet protection key (see 857 Section 6.2). Similarly, a packet that appears to trigger a key 858 update, but cannot be unprotected successfully MUST be discarded. 860 Failure to unprotect a packet does not necessarily indicate the 861 existence of a protocol error in a peer or an attack. The truncated 862 packet number encoding used in QUIC can cause packet numbers to be 863 decoded incorrectly if they are delayed significantly. 865 6. Key Phases 867 As TLS reports the availability of 0-RTT and 1-RTT keys, new keying 868 material can be exported from TLS and used for QUIC packet 869 protection. At each transition during the handshake a new secret is 870 exported from TLS and packet protection keys are derived from that 871 secret. 873 Every time that a new set of keys is used for protecting outbound 874 packets, the KEY_PHASE bit in the public flags is toggled. The 875 exception is the transition from 0-RTT keys to 1-RTT keys, where the 876 presence of the version field and its associated bit is used (see 877 Section 6.1.1). 879 Once the connection is fully enabled, the KEY_PHASE bit allows a 880 recipient to detect a change in keying material without necessarily 881 needing to receive the first packet that triggered the change. An 882 endpoint that notices a changed KEY_PHASE bit can update keys and 883 decrypt the packet that contains the changed bit, see Section 6.2. 885 The KEY_PHASE bit is the third bit of the public flags (0x04). 887 Transitions between keys during the handshake are complicated by the 888 need to ensure that TLS handshake messages are sent with the correct 889 packet protection. 891 6.1. Packet Protection for the TLS Handshake 893 The initial exchange of packets are sent without protection. These 894 packets are marked with a KEY_PHASE of 0. 896 TLS handshake messages MUST NOT be protected using QUIC packet 897 protection. A KEY_PHASE of 0 is used for all of these packets, even 898 during retransmission. The messages affected are all TLS handshake 899 message up to the TLS Finished that is sent by each endpoint. 901 Any TLS handshake messages that are sent after completing the TLS 902 handshake do not need special packet protection rules. Packets 903 containing these messages use the packet protection keys that are 904 current at the time of sending (or retransmission). 906 Like the client, a server MUST send retransmissions of its 907 unprotected handshake messages or acknowledgments for unprotected 908 handshake messages sent by the client in unprotected packets 909 (KEY_PHASE=0). 911 6.1.1. Initial Key Transitions 913 Once the TLS handshake is complete, keying material is exported from 914 TLS and QUIC packet protection commences. 916 Packets protected with 1-RTT keys have a KEY_PHASE bit set to 1. 917 These packets also have a VERSION bit set to 0. 919 If the client sends 0-RTT data, it marks packets protected with 0-RTT 920 keys with a KEY_PHASE of 1 and a VERSION bit of 1. Setting the 921 version bit means that all packets also include the version field. 922 The client retains the VERSION bit, but reverts the KEY_PHASE bit for 923 the packet that contains the TLS EndOfEarlyData and Finished 924 messages. 926 The client clears the VERSION bit and sets the KEY_PHASE bit to 1 927 when it transitions to using 1-RTT keys. 929 Marking 0-RTT data with the both KEY_PHASE and VERSION bits ensures 930 that the server is able to identify these packets as 0-RTT data in 931 case packets containing TLS handshake message are lost or delayed. 932 Including the version also ensures that the packet format is known to 933 the server in this case. 935 Using both KEY_PHASE and VERSION also ensures that the server is able 936 to distinguish between cleartext handshake packets (KEY_PHASE=0, 937 VERSION=1), 0-RTT protected packets (KEY_PHASE=1, VERSION=1), and 938 1-RTT protected packets (KEY_PHASE=1, VERSION=0). Packets with all 939 of these markings can arrive concurrently, and being able to identify 940 each cleanly ensures that the correct packet protection keys can be 941 selected and applied. 943 A server might choose to retain 0-RTT packets that arrive before a 944 TLS ClientHello. The server can then use those packets once the 945 ClientHello arrives. However, the potential for denial of service 946 from buffering 0-RTT packets is significant. These packets cannot be 947 authenticated and so might be employed by an attacker to exhaust 948 server resources. Limiting the number of packets that are saved 949 might be necessary. 951 The server transitions to using 1-RTT keys after sending its first 952 flight of TLS handshake messages. From this point, the server 953 protects all packets with 1-RTT keys. Future packets are therefore 954 protected with 1-RTT keys and marked with a KEY_PHASE of 1. 956 6.1.2. Retransmission and Acknowledgment of Unprotected Packets 958 TLS handshake messages from both client and server are critical to 959 the key exchange. The contents of these messages determines the keys 960 used to protect later messages. If these handshake messages are 961 included in packets that are protected with these keys, they will be 962 indecipherable to the recipient. 964 Even though newer keys could be available when retranmitting, 965 retransmissions of these handshake messages MUST be sent in 966 unprotected packets (with a KEY_PHASE of 0). An endpoint MUST also 967 generate ACK frames for these messages that are sent in unprotected 968 packets. 970 A HelloRetryRequest handshake message might be used to reject an 971 initial ClientHello. A HelloRetryRequest handshake message and any 972 second ClientHello that is sent in response MUST also be sent without 973 packet protection. This is natural, because no new keying material 974 will be available when these messages need to be sent. Upon receipt 975 of a HelloRetryRequest, a client SHOULD cease any transmission of 976 0-RTT data; 0-RTT data will only be discarded by any server that 977 sends a HelloRetryRequest. 979 The KEY_PHASE and VERSION bits ensure that protected packets are 980 clearly distinguished from unprotected packets. Loss or reordering 981 might cause unprotected packets to arrive once 1-RTT keys are in use, 982 unprotected packets are easily distinguished from 1-RTT packets. 984 Once 1-RTT keys are available to an endpoint, it no longer needs the 985 TLS handshake messages that are carried in unprotected packets. 986 However, a server might need to retransmit its TLS handshake messages 987 in response to receiving an unprotected packet that contains ACK 988 frames. A server MUST process ACK frames in unprotected packets 989 until the TLS handshake is reported as complete, or it receives an 990 ACK frame in a protected packet that acknowledges all of its 991 handshake messages. 993 To limit the number of key phases that could be active, an endpoint 994 MUST NOT initiate a key update while there are any unacknowledged 995 handshake messages, see Section 6.2. 997 6.2. Key Update 999 Once the TLS handshake is complete, the KEY_PHASE bit allows for 1000 refreshes of keying material by either peer. Endpoints start using 1001 updated keys immediately without additional signaling; the change in 1002 the KEY_PHASE bit indicates that a new key is in use. 1004 An endpoint MUST NOT initiate more than one key update at a time. A 1005 new key cannot be used until the endpoint has received and 1006 successfully decrypted a packet with a matching KEY_PHASE. Note that 1007 when 0-RTT is attempted the value of the KEY_PHASE bit will be 1008 different on packets sent by either peer. 1010 A receiving endpoint detects an update when the KEY_PHASE bit doesn't 1011 match what it is expecting. It creates a new secret (see 1012 Section 5.2) and the corresponding read key and IV. If the packet 1013 can be decrypted and authenticated using these values, then the keys 1014 it uses for packet protection are also updated. The next packet sent 1015 by the endpoint will then use the new keys. 1017 An endpoint doesn't need to send packets immediately when it detects 1018 that its peer has updated keys. The next packet that it sends will 1019 simply use the new keys. If an endpoint detects a second update 1020 before it has sent any packets with updated keys it indicates that 1021 its peer has updated keys twice without awaiting a reciprocal update. 1022 An endpoint MUST treat consecutive key updates as a fatal error and 1023 abort the connection. 1025 An endpoint SHOULD retain old keys for a short period to allow it to 1026 decrypt packets with smaller packet numbers than the packet that 1027 triggered the key update. This allows an endpoint to consume packets 1028 that are reordered around the transition between keys. Packets with 1029 higher packet numbers always use the updated keys and MUST NOT be 1030 decrypted with old keys. 1032 Keys and their corresponding secrets SHOULD be discarded when an 1033 endpoint has received all packets with sequence numbers lower than 1034 the lowest sequence number used for the new key. An endpoint might 1035 discard keys if it determines that the length of the delay to 1036 affected packets is excessive. 1038 This ensures that once the handshake is complete, packets with the 1039 same KEY_PHASE will have the same packet protection keys, unless 1040 there are multiple key updates in a short time frame succession and 1041 significant packet reordering. 1043 Initiating Peer Responding Peer 1045 @M QUIC Frames 1046 New Keys -> @N 1047 @N QUIC Frames 1048 --------> 1049 QUIC Frames @M 1050 New Keys -> @N 1051 QUIC Frames @N 1052 <-------- 1054 Figure 5: Key Update 1056 As shown in Figure 3 and Figure 5, there is never a situation where 1057 there are more than two different sets of keying material that might 1058 be received by a peer. Once both sending and receiving keys have 1059 been updated, 1061 A server cannot initiate a key update until it has received the 1062 client's Finished message. Otherwise, packets protected by the 1063 updated keys could be confused for retransmissions of handshake 1064 messages. A client cannot initiate a key update until all of its 1065 handshake messages have been acknowledged by the server. 1067 A packet that triggers a key update could arrive after successfully 1068 processing a packet with a higher packet number. This is only 1069 possible if there is a key compromise and an attack, or if the peer 1070 is incorrectly reverting to use of old keys. Because the latter 1071 cannot be differentiated from an attack, an endpoint MUST immediately 1072 terminate the connection if it detects this condition. 1074 7. Client Address Validation 1076 Two tools are provided by TLS to enable validation of client source 1077 addresses at a server: the cookie in the HelloRetryRequest message, 1078 and the ticket in the NewSessionTicket message. 1080 7.1. HelloRetryRequest Address Validation 1082 The cookie extension in the TLS HelloRetryRequest message allows a 1083 server to perform source address validation during the handshake. 1085 When QUIC requests address validation during the processing of the 1086 first ClientHello, the token it provides is included in the cookie 1087 extension of a HelloRetryRequest. As long as the cookie cannot be 1088 successfully guessed by a client, the server can be assured that the 1089 client received the HelloRetryRequest if it includes the value in a 1090 second ClientHello. 1092 An initial ClientHello never includes a cookie extension. Thus, if a 1093 server constructs a cookie that contains all the information 1094 necessary to reconstruct state, it can discard local state after 1095 sending a HelloRetryRequest. Presence of a valid cookie in a 1096 ClientHello indicates that the ClientHello is a second attempt from 1097 the client. 1099 An address validation token can be extracted from a second 1100 ClientHello and passed to the transport for further validation. If 1101 that validation fails, the server MUST fail the TLS handshake and 1102 send an illegal_parameter alert. 1104 Combining address validation with the other uses of HelloRetryRequest 1105 ensures that there are fewer ways in which an additional round-trip 1106 can be added to the handshake. In particular, this makes it possible 1107 to combine a request for address validation with a request for a 1108 different client key share. 1110 If TLS needs to send a HelloRetryRequest for other reasons, it needs 1111 to ensure that it can correctly identify the reason that the 1112 HelloRetryRequest was generated. During the processing of a second 1113 ClientHello, TLS does not need to consult the transport protocol 1114 regarding address validation if address validation was not requested 1115 originally. In such cases, the cookie extension could either be 1116 absent or it could indicate that an address validation token is not 1117 present. 1119 7.2. NewSessionTicket Address Validation 1121 The ticket in the TLS NewSessionTicket message allows a server to 1122 provide a client with a similar sort of token. When a client resumes 1123 a TLS connection - whether or not 0-RTT is attempted - it includes 1124 the ticket in the handshake message. As with the HelloRetryRequest 1125 cookie, the server includes the address validation token in the 1126 ticket. TLS provides the token it extracts from the session ticket 1127 to the transport when it asks whether source address validation is 1128 needed. 1130 If both a HelloRetryRequest cookie and a session ticket are present 1131 in the ClientHello, only the token from the cookie is passed to the 1132 transport. The presence of a cookie indicates that this is a second 1133 ClientHello - the token from the session ticket will have been 1134 provided to the transport when it appeared in the first ClientHello. 1136 A server can send a NewSessionTicket message at any time. This 1137 allows it to update the state - and the address validation token - 1138 that is included in the ticket. This might be done to refresh the 1139 ticket or token, or it might be generated in response to changes in 1140 the state of the connection. QUIC can request that a 1141 NewSessionTicket be sent by providing a new address validation token. 1143 A server that intends to support 0-RTT SHOULD provide an address 1144 validation token immediately after completing the TLS handshake. 1146 7.3. Address Validation Token Integrity 1148 TLS MUST provide integrity protection for address validation token 1149 unless the transport guarantees integrity protection by other means. 1150 For a NewSessionTicket that includes confidential information - such 1151 as the resumption secret - including the token under authenticated 1152 encryption ensures that the token gains both confidentiality and 1153 integrity protection without duplicating the overheads of that 1154 protection. 1156 8. Pre-handshake QUIC Messages 1158 Implementations MUST NOT exchange data on any stream other than 1159 stream 1 without packet protection. QUIC requires the use of several 1160 types of frame for managing loss detection and recovery during this 1161 phase. In addition, it might be useful to use the data acquired 1162 during the exchange of unauthenticated messages for congestion 1163 control. 1165 This section generally only applies to TLS handshake messages from 1166 both peers and acknowledgments of the packets carrying those 1167 messages. In many cases, the need for servers to provide 1168 acknowledgments is minimal, since the messages that clients send are 1169 small and implicitly acknowledged by the server's responses. 1171 The actions that a peer takes as a result of receiving an 1172 unauthenticated packet needs to be limited. In particular, state 1173 established by these packets cannot be retained once record 1174 protection commences. 1176 There are several approaches possible for dealing with 1177 unauthenticated packets prior to handshake completion: 1179 o discard and ignore them 1181 o use them, but reset any state that is established once the 1182 handshake completes 1184 o use them and authenticate them afterwards; failing the handshake 1185 if they can't be authenticated 1187 o save them and use them when they can be properly authenticated 1188 o treat them as a fatal error 1190 Different strategies are appropriate for different types of data. 1191 This document proposes that all strategies are possible depending on 1192 the type of message. 1194 o Transport parameters are made usable and authenticated as part of 1195 the TLS handshake (see Section 9.2). 1197 o Most unprotected messages are treated as fatal errors when 1198 received except for the small number necessary to permit the 1199 handshake to complete (see Section 8.1). 1201 o Protected packets can either be discarded or saved and later used 1202 (see Section 8.3). 1204 8.1. Unprotected Packets Prior to Handshake Completion 1206 This section describes the handling of messages that are sent and 1207 received prior to the completion of the TLS handshake. 1209 Sending and receiving unprotected messages is hazardous. Unless 1210 expressly permitted, receipt of an unprotected message of any kind 1211 MUST be treated as a fatal error. 1213 8.1.1. STREAM Frames 1215 "STREAM" frames for stream 1 are permitted. These carry the TLS 1216 handshake messages. Once 1-RTT keys are available, unprotected 1217 "STREAM" frames on stream 1 can be ignored. 1219 Receiving unprotected "STREAM" frames for other streams MUST be 1220 treated as a fatal error. 1222 8.1.2. ACK Frames 1224 "ACK" frames are permitted prior to the handshake being complete. 1225 Information learned from "ACK" frames cannot be entirely relied upon, 1226 since an attacker is able to inject these packets. Timing and packet 1227 retransmission information from "ACK" frames is critical to the 1228 functioning of the protocol, but these frames might be spoofed or 1229 altered. 1231 Endpoints MUST NOT use an unprotected "ACK" frame to acknowledge data 1232 that was protected by 0-RTT or 1-RTT keys. An endpoint MUST ignore 1233 an unprotected "ACK" frame if it claims to acknowledge data that was 1234 sent in a protected packet. Such an acknowledgement can only serve 1235 as a denial of service, since an endpoint that can read protected 1236 data is always able to send protected data. 1238 ISSUE: What about 0-RTT data? Should we allow acknowledgment of 1239 0-RTT with unprotected frames? If we don't, then 0-RTT data will 1240 be unacknowledged until the handshake completes. This isn't a 1241 problem if the handshake completes without loss, but it could mean 1242 that 0-RTT stalls when a handshake packet disappears for any 1243 reason. 1245 An endpoint SHOULD use data from unprotected or 0-RTT-protected "ACK" 1246 frames only during the initial handshake and while they have 1247 insufficient information from 1-RTT-protected "ACK" frames. Once 1248 sufficient information has been obtained from protected messages, 1249 information obtained from less reliable sources can be discarded. 1251 8.1.3. WINDOW_UPDATE Frames 1253 "WINDOW_UPDATE" frames MUST NOT be sent unprotected. 1255 Though data is exchanged on stream 1, the initial flow control window 1256 is sufficiently large to allow the TLS handshake to complete. This 1257 limits the maximum size of the TLS handshake and would prevent a 1258 server or client from using an abnormally large certificate chain. 1260 Stream 1 is exempt from the connection-level flow control window. 1262 8.1.4. Denial of Service with Unprotected Packets 1264 Accepting unprotected - specifically unauthenticated - packets 1265 presents a denial of service risk to endpoints. An attacker that is 1266 able to inject unprotected packets can cause a recipient to drop even 1267 protected packets with a matching sequence number. The spurious 1268 packet shadows the genuine packet, causing the genuine packet to be 1269 ignored as redundant. 1271 Once the TLS handshake is complete, both peers MUST ignore 1272 unprotected packets. From that point onward, unprotected messages 1273 can be safely dropped. 1275 Since only TLS handshake packets and acknowledgments are sent in the 1276 clear, an attacker is able to force implementations to rely on 1277 retransmission for packets that are lost or shadowed. Thus, an 1278 attacker that intends to deny service to an endpoint has to drop or 1279 shadow protected packets in order to ensure that their victim 1280 continues to accept unprotected packets. The ability to shadow 1281 packets means that an attacker does not need to be on path. 1283 ISSUE: This would not be an issue if QUIC had a randomized starting 1284 sequence number. If we choose to randomize, we fix this problem 1285 and reduce the denial of service exposure to on-path attackers. 1286 The only possible problem is in authenticating the initial value, 1287 so that peers can be sure that they haven't missed an initial 1288 message. 1290 In addition to causing valid packets to be dropped, an attacker can 1291 generate packets with an intent of causing the recipient to expend 1292 processing resources. See Section 10.2 for a discussion of these 1293 risks. 1295 To avoid receiving TLS packets that contain no useful data, a TLS 1296 implementation MUST reject empty TLS handshake records and any record 1297 that is not permitted by the TLS state machine. Any TLS application 1298 data or alerts that is received prior to the end of the handshake 1299 MUST be treated as a fatal error. 1301 8.2. Use of 0-RTT Keys 1303 If 0-RTT keys are available, the lack of replay protection means that 1304 restrictions on their use are necessary to avoid replay attacks on 1305 the protocol. 1307 A client MUST only use 0-RTT keys to protect data that is idempotent. 1308 A client MAY wish to apply additional restrictions on what data it 1309 sends prior to the completion of the TLS handshake. A client 1310 otherwise treats 0-RTT keys as equivalent to 1-RTT keys. 1312 A client that receives an indication that its 0-RTT data has been 1313 accepted by a server can send 0-RTT data until it receives all of the 1314 server's handshake messages. A client SHOULD stop sending 0-RTT data 1315 if it receives an indication that 0-RTT data has been rejected. 1317 A server MUST NOT use 0-RTT keys to protect packets. 1319 8.3. Receiving Out-of-Order Protected Frames 1321 Due to reordering and loss, protected packets might be received by an 1322 endpoint before the final TLS handshake messages are received. A 1323 client will be unable to decrypt 1-RTT packets from the server, 1324 whereas a server will be able to decrypt 1-RTT packets from the 1325 client. 1327 Packets protected with 1-RTT keys MAY be stored and later decrypted 1328 and used once the handshake is complete. A server MUST NOT use 1-RTT 1329 protected packets before verifying either the client Finished message 1330 or - in the case that the server has chosen to use a pre-shared key - 1331 the pre-shared key binder (see Section 4.2.8 of 1332 [I-D.ietf-tls-tls13]). Verifying these values provides the server 1333 with an assurance that the ClientHello has not been modified. 1335 A server could receive packets protected with 0-RTT keys prior to 1336 receiving a TLS ClientHello. The server MAY retain these packets for 1337 later decryption in anticipation of receiving a ClientHello. 1339 Receiving and verifying the TLS Finished message is critical in 1340 ensuring the integrity of the TLS handshake. A server MUST NOT use 1341 protected packets from the client prior to verifying the client 1342 Finished message if its response depends on client authentication. 1344 9. QUIC-Specific Additions to the TLS Handshake 1346 QUIC uses the TLS handshake for more than just negotiation of 1347 cryptographic parameters. The TLS handshake validates protocol 1348 version selection, provides preliminary values for QUIC transport 1349 parameters, and allows a server to perform return routeability checks 1350 on clients. 1352 9.1. Protocol and Version Negotiation 1354 The QUIC version negotiation mechanism is used to negotiate the 1355 version of QUIC that is used prior to the completion of the 1356 handshake. However, this packet is not authenticated, enabling an 1357 active attacker to force a version downgrade. 1359 To ensure that a QUIC version downgrade is not forced by an attacker, 1360 version information is copied into the TLS handshake, which provides 1361 integrity protection for the QUIC negotiation. This does not prevent 1362 version downgrade during the handshake, though it means that such a 1363 downgrade causes a handshake failure. 1365 TLS uses Application Layer Protocol Negotiation (ALPN) [RFC7301] to 1366 select an application protocol. The application-layer protocol MAY 1367 restrict the QUIC versions that it can operate over. Servers MUST 1368 select an application protocol compatible with the QUIC version that 1369 the client has selected. 1371 If the server cannot select a compatible combination of application 1372 protocol and QUIC version, it MUST abort the connection. A client 1373 MUST abort a connection if the server picks an incompatible 1374 combination of QUIC version and ALPN identifier. 1376 9.2. QUIC Transport Parameters Extension 1378 QUIC transport parameters are carried in a TLS extension. Different 1379 versions of QUIC might define a different format for this struct. 1381 Including transport parameters in the TLS handshake provides 1382 integrity protection for these values. 1384 enum { 1385 quic_transport_parameters(26), (65535) 1386 } ExtensionType; 1388 The "extension_data" field of the quic_transport_parameters extension 1389 contains a value that is defined by the version of QUIC that is in 1390 use. The quic_transport_parameters extension carries a 1391 TransportParameters when the version of QUIC defined in 1392 [QUIC-TRANSPORT] is used. 1394 9.3. Priming 0-RTT 1396 QUIC uses TLS without modification. Therefore, it is possible to use 1397 a pre-shared key that was obtained in a TLS connection over TCP to 1398 enable 0-RTT in QUIC. Similarly, QUIC can provide a pre-shared key 1399 that can be used to enable 0-RTT in TCP. 1401 All the restrictions on the use of 0-RTT apply, with the exception of 1402 the ALPN label, which MUST only change to a label that is explicitly 1403 designated as being compatible. The client indicates which ALPN 1404 label it has chosen by placing that ALPN label first in the ALPN 1405 extension. 1407 The certificate that the server uses MUST be considered valid for 1408 both connections, which will use different protocol stacks and could 1409 use different port numbers. For instance, HTTP/1.1 and HTTP/2 1410 operate over TLS and TCP, whereas QUIC operates over UDP. 1412 Source address validation is not completely portable between 1413 different protocol stacks. Even if the source IP address remains 1414 constant, the port number is likely to be different. Packet 1415 reflection attacks are still possible in this situation, though the 1416 set of hosts that can initiate these attacks is greatly reduced. A 1417 server might choose to avoid source address validation for such a 1418 connection, or allow an increase to the amount of data that it sends 1419 toward the client without source validation. 1421 10. Security Considerations 1423 There are likely to be some real clangers here eventually, but the 1424 current set of issues is well captured in the relevant sections of 1425 the main text. 1427 Never assume that because it isn't in the security considerations 1428 section it doesn't affect security. Most of this document does. 1430 10.1. Packet Reflection Attack Mitigation 1432 A small ClientHello that results in a large block of handshake 1433 messages from a server can be used in packet reflection attacks to 1434 amplify the traffic generated by an attacker. 1436 Certificate caching [RFC7924] can reduce the size of the server's 1437 handshake messages significantly. 1439 QUIC requires that the packet containing a ClientHello be padded to 1440 the size of the maximum transmission unit (MTU). A server is less 1441 likely to generate a packet reflection attack if the data it sends is 1442 a small multiple of this size. A server SHOULD use a 1443 HelloRetryRequest if the size of the handshake messages it sends is 1444 likely to significantly exceed the size of the packet containing the 1445 ClientHello. 1447 10.2. Peer Denial of Service 1449 QUIC, TLS and HTTP/2 all contain a messages that have legitimate uses 1450 in some contexts, but that can be abused to cause a peer to expend 1451 processing resources without having any observable impact on the 1452 state of the connection. If processing is disproportionately large 1453 in comparison to the observable effects on bandwidth or state, then 1454 this could allow a malicious peer to exhaust processing capacity 1455 without consequence. 1457 QUIC prohibits the sending of empty "STREAM" frames unless they are 1458 marked with the FIN bit. This prevents "STREAM" frames from being 1459 sent that only waste effort. 1461 TLS records SHOULD always contain at least one octet of a handshake 1462 messages or alert. Records containing only padding are permitted 1463 during the handshake, but an excessive number might be used to 1464 generate unnecessary work. Once the TLS handshake is complete, 1465 endpoints SHOULD NOT send TLS application data records unless it is 1466 to hide the length of QUIC records. QUIC packet protection does not 1467 include any allowance for padding; padded TLS application data 1468 records can be used to mask the length of QUIC frames. 1470 While there are legitimate uses for some redundant packets, 1471 implementations SHOULD track redundant packets and treat excessive 1472 volumes of any non-productive packets as indicative of an attack. 1474 11. Error codes 1476 The portion of the QUIC error code space allocated for the crypto 1477 handshake is 0xC0000000-0xFFFFFFFF. The following error codes are 1478 defined when TLS is used for the crypto handshake: 1480 TLS_HANDSHAKE_FAILED (0xC000001C): The TLS handshake failed. 1482 TLS_FATAL_ALERT_GENERATED (0xC000001D): A TLS fatal alert was sent, 1483 causing the TLS connection to end prematurely. 1485 TLS_FATAL_ALERT_RECEIVED (0xC000001E): A TLS fatal alert was 1486 received, causing the TLS connection to end prematurely. 1488 12. IANA Considerations 1490 This document has no IANA actions. Yet. 1492 13. References 1494 13.1. Normative References 1496 [I-D.ietf-tls-tls13] 1497 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1498 Version 1.3", draft-ietf-tls-tls13-19 (work in progress), 1499 March 2017. 1501 [QUIC-TRANSPORT] 1502 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1503 Multiplexed and Secure Transport". 1505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1506 Requirement Levels", BCP 14, RFC 2119, 1507 DOI 10.17487/RFC2119, March 1997, 1508 . 1510 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1511 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1512 . 1514 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1515 Key Derivation Function (HKDF)", RFC 5869, 1516 DOI 10.17487/RFC5869, May 2010, 1517 . 1519 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1520 Protocol (HTTP/1.1): Message Syntax and Routing", 1521 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1522 . 1524 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1525 "Transport Layer Security (TLS) Application-Layer Protocol 1526 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1527 July 2014, . 1529 13.2. Informative References 1531 [AEBounds] 1532 Luykx, A. and K. Paterson, "Limits on Authenticated 1533 Encryption Use in TLS", March 2016, 1534 . 1536 [QUIC-HTTP] 1537 Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over 1538 QUIC". 1540 [QUIC-RECOVERY] 1541 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 1542 and Congestion Control". 1544 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1545 RFC 793, DOI 10.17487/RFC0793, September 1981, 1546 . 1548 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1549 DOI 10.17487/RFC2818, May 2000, 1550 . 1552 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1553 Housley, R., and W. Polk, "Internet X.509 Public Key 1554 Infrastructure Certificate and Certificate Revocation List 1555 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1556 . 1558 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1559 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1560 DOI 10.17487/RFC7540, May 2015, 1561 . 1563 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 1564 (TLS) Cached Information Extension", RFC 7924, 1565 DOI 10.17487/RFC7924, July 2016, 1566 . 1568 Appendix A. Contributors 1570 Ryan Hamilton was originally an author of this specification. 1572 Appendix B. Acknowledgments 1574 This document has benefited from input from Dragana Damjanovic, 1575 Christian Huitema, Jana Iyengar, Adam Langley, Roberto Peon, Eric 1576 Rescorla, Ian Swett, and many others. 1578 Appendix C. Change Log 1580 *RFC Editor's Note:* Please remove this section prior to 1581 publication of a final version of this document. 1583 Issue and pull request numbers are listed with a leading octothorp. 1585 C.1. Since draft-ietf-quic-tls-01: 1587 o Use TLS alerts to signal TLS errors (#272, #374) 1589 o Require ClientHello to fit in a single packet (#338) 1591 o The second client handshake flight is now sent in the clear (#262, 1592 #337) 1594 o The QUIC header is included as AEAD Associated Data (#226, #243, 1595 #302) 1597 o Add interface necessary for client address validation (#275) 1599 o Define peer authentication (#140) 1601 o Require at least TLS 1.3 (#138) 1603 o Define transport parameters as a TLS extension (#122) 1605 o Define handling for protected packets before the handshake 1606 completes (#39) 1608 o Decouple QUIC version and ALPN (#12) 1610 C.2. Since draft-ietf-quic-tls-00: 1612 o Changed bit used to signal key phase. 1614 o Updated key phase markings during the handshake. 1616 o Added TLS interface requirements section. 1618 o Moved to use of TLS exporters for key derivation. 1620 o Moved TLS error code definitions into this document. 1622 C.3. Since draft-thomson-quic-tls-01: 1624 o Adopted as base for draft-ietf-quic-tls. 1626 o Updated authors/editors list. 1628 o Added status note. 1630 Authors' Addresses 1632 Martin Thomson (editor) 1633 Mozilla 1635 Email: martin.thomson@gmail.com 1637 Sean Turner (editor) 1638 sn3rd