idnits 2.17.1 draft-ietf-quic-tls-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 28, 2018) is 2280 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1694 -- Looks like a reference, but probably isn't: '2' on line 1696 -- Looks like a reference, but probably isn't: '3' on line 1698 == Unused Reference: 'QUIC-HTTP' is defined on line 1667, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180' == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-09 ** Downref: Normative reference to an Informational RFC: RFC 5869 == Outdated reference: A later version (-05) exists of draft-ietf-tls-iana-registry-updates-03 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-23 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-09 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-09 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 7 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: August 1, 2018 sn3rd 6 January 28, 2018 8 Using Transport Layer Security (TLS) to Secure QUIC 9 draft-ietf-quic-tls-09 11 Abstract 13 This document describes how Transport Layer Security (TLS) is used to 14 secure QUIC. 16 Note to Readers 18 Discussion of this draft takes place on the QUIC working group 19 mailing list (quic@ietf.org), which is archived at 20 https://mailarchive.ietf.org/arch/search/?email_list=quic [1]. 22 Working Group information can be found at https://github.com/quicwg 23 [2]; source code and issues list for this draft can be found at 24 https://github.com/quicwg/base-drafts/labels/-tls [3]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 1, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 7 67 4.2. Interface to TLS . . . . . . . . . . . . . . . . . . . . 9 68 4.2.1. Handshake Interface . . . . . . . . . . . . . . . . . 9 69 4.2.2. Source Address Validation . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . 13 76 4.6. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 14 77 5. QUIC Packet Protection . . . . . . . . . . . . . . . . . . . 14 78 5.1. Installing New Keys . . . . . . . . . . . . . . . . . . . 14 79 5.2. QUIC Key Expansion . . . . . . . . . . . . . . . . . . . 15 80 5.2.1. Handshake Secrets . . . . . . . . . . . . . . . . . . 15 81 5.2.2. 0-RTT Secret . . . . . . . . . . . . . . . . . . . . 15 82 5.2.3. 1-RTT Secrets . . . . . . . . . . . . . . . . . . . . 16 83 5.2.4. Packet Protection Key and IV . . . . . . . . . . . . 17 84 5.3. QUIC AEAD Usage . . . . . . . . . . . . . . . . . . . . . 18 85 5.4. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 18 86 5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 19 87 5.6. Packet Number Gaps . . . . . . . . . . . . . . . . . . . 19 88 6. Key Phases . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 6.1. Packet Protection for the TLS Handshake . . . . . . . . . 20 90 6.1.1. Initial Key Transitions . . . . . . . . . . . . . . . 20 91 6.1.2. Retransmission and Acknowledgment of Unprotected 92 Packets . . . . . . . . . . . . . . . . . . . . . . . 21 93 6.2. Key Update . . . . . . . . . . . . . . . . . . . . . . . 22 94 7. Client Address Validation . . . . . . . . . . . . . . . . . . 24 95 7.1. HelloRetryRequest Address Validation . . . . . . . . . . 24 96 7.1.1. Stateless Address Validation . . . . . . . . . . . . 25 97 7.1.2. Sending HelloRetryRequest . . . . . . . . . . . . . . 25 98 7.2. NewSessionTicket Address Validation . . . . . . . . . . . 25 99 7.3. Address Validation Token Integrity . . . . . . . . . . . 26 100 8. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 26 101 8.1. Unprotected Packets Prior to Handshake Completion . . . . 27 102 8.1.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 27 103 8.1.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 28 104 8.1.3. Updates to Data and Stream Limits . . . . . . . . . . 28 105 8.1.4. Handshake Failures . . . . . . . . . . . . . . . . . 29 106 8.1.5. Denial of Service with Unprotected Packets . . . . . 29 107 8.2. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 30 108 8.3. Receiving Out-of-Order Protected Frames . . . . . . . . . 30 109 9. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 30 110 9.1. Protocol and Version Negotiation . . . . . . . . . . . . 31 111 9.2. QUIC Transport Parameters Extension . . . . . . . . . . . 31 112 9.3. Priming 0-RTT . . . . . . . . . . . . . . . . . . . . . . 32 113 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 114 10.1. Packet Reflection Attack Mitigation . . . . . . . . . . 32 115 10.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 33 116 11. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 33 117 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 118 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 119 13.1. Normative References . . . . . . . . . . . . . . . . . . 35 120 13.2. Informative References . . . . . . . . . . . . . . . . . 36 121 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36 122 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 36 123 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 37 124 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 37 125 C.1. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 37 126 C.2. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 37 127 C.3. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 37 128 C.4. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 37 129 C.5. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 37 130 C.6. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 37 131 C.7. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 37 132 C.8. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 38 133 C.9. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 38 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 136 1. Introduction 138 This document describes how QUIC [QUIC-TRANSPORT] is secured using 139 Transport Layer Security (TLS) version 1.3 [TLS13]. TLS 1.3 provides 140 critical latency improvements for connection establishment over 141 previous versions. Absent packet loss, most new connections can be 142 established and secured within a single round trip; on subsequent 143 connections between the same client and server, the client can often 144 send application data immediately, that is, using a zero round trip 145 setup. 147 This document describes how the standardized TLS 1.3 acts a security 148 component of QUIC. The same design could work for TLS 1.2, though 149 few of the benefits QUIC provides would be realized due to the 150 handshake latency in versions of TLS prior to 1.3. 152 2. Notational Conventions 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14 [RFC2119] [RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 This document uses the terminology established in [QUIC-TRANSPORT]. 162 For brevity, the acronym TLS is used to refer to TLS 1.3. 164 TLS terminology is used when referring to parts of TLS. Though TLS 165 assumes a continuous stream of octets, it divides that stream into 166 _records_. Most relevant to QUIC are the records that contain TLS 167 _handshake messages_, which are discrete messages that are used for 168 key agreement, authentication and parameter negotiation. Ordinarily, 169 TLS records can also contain _application data_, though in the QUIC 170 usage there is no use of TLS application data. 172 3. Protocol Overview 174 QUIC [QUIC-TRANSPORT] assumes responsibility for the confidentiality 175 and integrity protection of packets. For this it uses keys derived 176 from a TLS 1.3 connection [TLS13]; QUIC also relies on TLS 1.3 for 177 authentication and negotiation of parameters that are critical to 178 security and performance. 180 Rather than a strict layering, these two protocols are co-dependent: 181 QUIC uses the TLS handshake; TLS uses the reliability and ordered 182 delivery provided by QUIC streams. 184 This document defines how QUIC interacts with TLS. This includes a 185 description of how TLS is used, how keying material is derived from 186 TLS, and the application of that keying material to protect QUIC 187 packets. Figure 1 shows the basic interactions between TLS and QUIC, 188 with the QUIC packet protection being called out specially. 190 +------------+ +------------+ 191 | |------ Handshake ------>| | 192 | |<-- Validate Address ---| | 193 | |-- OK/Error/Validate -->| | 194 | |<----- Handshake -------| | 195 | QUIC |------ Validate ------->| TLS | 196 | | | | 197 | |<------ 0-RTT OK -------| | 198 | |<------ 1-RTT OK -------| | 199 | |<--- Handshake Done ----| | 200 +------------+ +------------+ 201 | ^ ^ | 202 | Protect | Protected | | 203 v | Packet | | 204 +------------+ / / 205 | QUIC | / / 206 | Packet |-------- Get Secret -------' / 207 | Protection |<-------- Secret -----------' 208 +------------+ 210 Figure 1: QUIC and TLS Interactions 212 The initial state of a QUIC connection has packets exchanged without 213 any form of protection. In this state, QUIC is limited to using 214 stream 0 and associated packets. Stream 0 is reserved for a TLS 215 connection. This is a complete TLS connection as it would appear 216 when layered over TCP; the only difference is that QUIC provides the 217 reliability and ordering that would otherwise be provided by TCP. 219 At certain points during the TLS handshake, keying material is 220 exported from the TLS connection for use by QUIC. This keying 221 material is used to derive packet protection keys. Details on how 222 and when keys are derived and used are included in Section 5. 224 3.1. TLS Overview 226 TLS provides two endpoints with a way to establish a means of 227 communication over an untrusted medium (that is, the Internet) that 228 ensures that messages they exchange cannot be observed, modified, or 229 forged. 231 TLS features can be separated into two basic functions: an 232 authenticated key exchange and record protection. QUIC primarily 233 uses the authenticated key exchange provided by TLS but provides its 234 own packet protection. 236 The TLS authenticated key exchange occurs between two entities: 237 client and server. The client initiates the exchange and the server 238 responds. If the key exchange completes successfully, both client 239 and server will agree on a secret. TLS supports both pre-shared key 240 (PSK) and Diffie-Hellman (DH) key exchanges. PSK is the basis for 241 0-RTT; the latter provides perfect forward secrecy (PFS) when the DH 242 keys are destroyed. 244 After completing the TLS handshake, the client will have learned and 245 authenticated an identity for the server and the server is optionally 246 able to learn and authenticate an identity for the client. TLS 247 supports X.509 [RFC5280] certificate-based authentication for both 248 server and client. 250 The TLS key exchange is resistent to tampering by attackers and it 251 produces shared secrets that cannot be controlled by either 252 participating peer. 254 3.2. TLS Handshake 256 TLS 1.3 provides two basic handshake modes of interest to QUIC: 258 o A full 1-RTT handshake in which the client is able to send 259 application data after one round trip and the server immediately 260 responds after receiving the first handshake message from the 261 client. 263 o A 0-RTT handshake in which the client uses information it has 264 previously learned about the server to send application data 265 immediately. This application data can be replayed by an attacker 266 so it MUST NOT carry a self-contained trigger for any non- 267 idempotent action. 269 A simplified TLS 1.3 handshake with 0-RTT application data is shown 270 in Figure 2, see [TLS13] for more options and details. 272 Client Server 274 ClientHello 275 (0-RTT Application Data) --------> 276 ServerHello 277 {EncryptedExtensions} 278 {Finished} 279 <-------- [Application Data] 280 (EndOfEarlyData) 281 {Finished} --------> 283 [Application Data] <-------> [Application Data] 285 Figure 2: TLS Handshake with 0-RTT 287 This 0-RTT handshake is only possible if the client and server have 288 previously communicated. In the 1-RTT handshake, the client is 289 unable to send protected application data until it has received all 290 of the handshake messages sent by the server. 292 Two additional variations on this basic handshake exchange are 293 relevant to this document: 295 o The server can respond to a ClientHello with a HelloRetryRequest, 296 which adds an additional round trip prior to the basic exchange. 297 This is needed if the server wishes to request a different key 298 exchange key from the client. HelloRetryRequest is also used to 299 verify that the client is correctly able to receive packets on the 300 address it claims to have (see [QUIC-TRANSPORT]). 302 o A pre-shared key mode can be used for subsequent handshakes to 303 reduce the number of public key operations. This is the basis for 304 0-RTT data, even if the remainder of the connection is protected 305 by a new Diffie-Hellman exchange. 307 4. TLS Usage 309 QUIC reserves stream 0 for a TLS connection. Stream 0 contains a 310 complete TLS connection, which includes the TLS record layer. Other 311 than the definition of a QUIC-specific extension (see Section 9.2), 312 TLS is unmodified for this use. This means that TLS will apply 313 confidentiality and integrity protection to its records. In 314 particular, TLS record protection is what provides confidentiality 315 protection for the TLS handshake messages sent by the server. 317 QUIC permits a client to send frames on streams starting from the 318 first packet. The initial packet from a client contains a stream 319 frame for stream 0 that contains the first TLS handshake messages 320 from the client. This allows the TLS handshake to start with the 321 first packet that a client sends. 323 QUIC packets are protected using a scheme that is specific to QUIC, 324 see Section 5. Keys are exported from the TLS connection when they 325 become available using a TLS exporter (see Section 7.5 of [TLS13] and 326 Section 5.2). After keys are exported from TLS, QUIC manages its own 327 key schedule. 329 4.1. Handshake and Setup Sequence 331 The integration of QUIC with a TLS handshake is shown in more detail 332 in Figure 3. QUIC "STREAM" frames on stream 0 carry the TLS 333 handshake. QUIC performs loss recovery [QUIC-RECOVERY] for this 334 stream and ensures that TLS handshake messages are delivered in the 335 correct order. 337 Client Server 339 @H QUIC STREAM Frame(s) <0>: 340 ClientHello 341 + QUIC Extension 342 --------> 343 0-RTT Key => @0 345 @0 QUIC STREAM Frame(s) : 346 Replayable QUIC Frames 347 --------> 349 QUIC STREAM Frame <0>: @H 350 ServerHello 351 {TLS Handshake Messages} 352 <-------- 353 1-RTT Key => @1 355 QUIC Frames @1 356 <-------- 357 @H QUIC STREAM Frame(s) <0>: 358 (EndOfEarlyData) 359 {Finished} 360 --------> 362 @1 QUIC Frames <-------> QUIC Frames @1 364 Figure 3: QUIC over TLS Handshake 366 In Figure 3, symbols mean: 368 o "<" and ">" enclose stream numbers. 370 o "@" indicates the keys that are used for protecting the QUIC 371 packet (H = handshake, using keys from the well-known cleartext 372 packet secret; 0 = 0-RTT keys; 1 = 1-RTT keys). 374 o "(" and ")" enclose messages that are protected with TLS 0-RTT 375 handshake or application keys. 377 o "{" and "}" enclose messages that are protected by the TLS 378 Handshake keys. 380 If 0-RTT is not attempted, then the client does not send packets 381 protected by the 0-RTT key (@0). In that case, the only key 382 transition on the client is from handshake packets (@H) to 1-RTT 383 protection (@1), which happens after it sends its final set of TLS 384 handshake messages. 386 Note: two different types of packet are used during the handshake by 387 both client and server. The Initial packet carries a TLS ClientHello 388 message; the remainder of the TLS handshake is carried in Handshake 389 packets. The Retry packet carries a TLS HelloRetryRequest, if it is 390 needed, and Handshake packets carry the remainder of the server 391 handshake. 393 The server sends TLS handshake messages without protection (@H). The 394 server transitions from no protection (@H) to full 1-RTT protection 395 (@1) after it sends the last of its handshake messages. 397 Some TLS handshake messages are protected by the TLS handshake record 398 protection. These keys are not exported from the TLS connection for 399 use in QUIC. QUIC packets from the server are sent in the clear 400 until the final transition to 1-RTT keys. 402 The client transitions from handshake (@H) to 0-RTT keys (@0) when 403 sending 0-RTT data, and subsequently to to 1-RTT keys (@1) after its 404 second flight of TLS handshake messages. This creates the potential 405 for unprotected packets to be received by a server in close proximity 406 to packets that are protected with 1-RTT keys. 408 More information on key transitions is included in Section 6.1. 410 4.2. Interface to TLS 412 As shown in Figure 1, the interface from QUIC to TLS consists of four 413 primary functions: Handshake, Source Address Validation, Key Ready 414 Events, and Secret Export. 416 Additional functions might be needed to configure TLS. 418 4.2.1. Handshake Interface 420 In order to drive the handshake, TLS depends on being able to send 421 and receive handshake messages on stream 0. There are two basic 422 functions on this interface: one where QUIC requests handshake 423 messages and one where QUIC provides handshake packets. 425 Before starting the handshake QUIC provides TLS with the transport 426 parameters (see Section 9.2) that it wishes to carry. 428 A QUIC client starts TLS by requesting TLS handshake octets from TLS. 429 The client acquires handshake octets before sending its first packet. 431 A QUIC server starts the process by providing TLS with stream 0 432 octets. 434 Each time that an endpoint receives data on stream 0, it delivers the 435 octets to TLS if it is able. Each time that TLS is provided with new 436 data, new handshake octets are requested from TLS. TLS might not 437 provide any octets if the handshake messages it has received are 438 incomplete or it has no data to send. 440 Once the TLS handshake is complete, this is indicated to QUIC along 441 with any final handshake octets that TLS needs to send. TLS also 442 provides QUIC with the transport parameters that the peer advertised 443 during the handshake. 445 Once the handshake is complete, TLS becomes passive. TLS can still 446 receive data from its peer and respond in kind, but it will not need 447 to send more data unless specifically requested - either by an 448 application or QUIC. One reason to send data is that the server 449 might wish to provide additional or updated session tickets to a 450 client. 452 When the handshake is complete, QUIC only needs to provide TLS with 453 any data that arrives on stream 0. In the same way that is done 454 during the handshake, new data is requested from TLS after providing 455 received data. 457 Important: Until the handshake is reported as complete, the 458 connection and key exchange are not properly authenticated at the 459 server. Even though 1-RTT keys are available to a server after 460 receiving the first handshake messages from a client, the server 461 cannot consider the client to be authenticated until it receives 462 and validates the client's Finished message. 464 The requirement for the server to wait for the client Finished 465 message creates a dependency on that message being delivered. A 466 client can avoid the potential for head-of-line blocking that this 467 implies by sending a copy of the STREAM frame that carries the 468 Finished message in multiple packets. This enables immediate 469 server processing for those packets. 471 4.2.2. Source Address Validation 473 During the processing of the TLS ClientHello, TLS requests that the 474 transport make a decision about whether to request source address 475 validation from the client. 477 An initial TLS ClientHello that resumes a session includes an address 478 validation token in the session ticket; this includes all attempts at 479 0-RTT. If the client does not attempt session resumption, no token 480 will be present. While processing the initial ClientHello, TLS 481 provides QUIC with any token that is present. In response, QUIC 482 provides one of three responses: 484 o proceed with the connection, 486 o ask for client address validation, or 488 o abort the connection. 490 If QUIC requests source address validation, it also provides a new 491 address validation token. TLS includes that along with any 492 information it requires in the cookie extension of a TLS 493 HelloRetryRequest message. In the other cases, the connection either 494 proceeds or terminates with a handshake error. 496 The client echoes the cookie extension in a second ClientHello. A 497 ClientHello that contains a valid cookie extension will always be in 498 response to a HelloRetryRequest. If address validation was requested 499 by QUIC, then this will include an address validation token. TLS 500 makes a second address validation request of QUIC, including the 501 value extracted from the cookie extension. In response to this 502 request, QUIC cannot ask for client address validation, it can only 503 abort or permit the connection attempt to proceed. 505 QUIC can provide a new address validation token for use in session 506 resumption at any time after the handshake is complete. Each time a 507 new token is provided TLS generates a NewSessionTicket message, with 508 the token included in the ticket. 510 See Section 7 for more details on client address validation. 512 4.2.3. Key Ready Events 514 TLS provides QUIC with signals when 0-RTT and 1-RTT keys are ready 515 for use. These events are not asynchronous, they always occur 516 immediately after TLS is provided with new handshake octets, or after 517 TLS produces handshake octets. 519 When TLS completed its handshake, 1-RTT keys can be provided to QUIC. 520 On both client and server, this occurs after sending the TLS Finished 521 message. 523 This ordering means that there could be frames that carry TLS 524 handshake messages ready to send at the same time that application 525 data is available. An implementation MUST ensure that TLS handshake 526 messages are always sent in packets protected with handshake keys 527 (see Section 5.2.1). Separate packets are required for data that 528 needs protection from 1-RTT keys. 530 If 0-RTT is possible, it is ready after the client sends a TLS 531 ClientHello message or the server receives that message. After 532 providing a QUIC client with the first handshake octets, the TLS 533 stack might signal that 0-RTT keys are ready. On the server, after 534 receiving handshake octets that contain a ClientHello message, a TLS 535 server might signal that 0-RTT keys are available. 537 1-RTT keys are used for packets in both directions. 0-RTT keys are 538 only used to protect packets sent by the client. 540 4.2.4. Secret Export 542 Details how secrets are exported from TLS are included in 543 Section 5.2. 545 4.2.5. TLS Interface Summary 547 Figure 4 summarizes the exchange between QUIC and TLS for both client 548 and server. 550 Client Server 552 Get Handshake 553 0-RTT Key Ready 554 --- send/receive ---> 555 Handshake Received 556 0-RTT Key Ready 557 Get Handshake 558 1-RTT Keys Ready 559 <--- send/receive --- 560 Handshake Received 561 Get Handshake 562 Handshake Complete 563 1-RTT Keys Ready 564 --- send/receive ---> 565 Handshake Received 566 Get Handshake 567 Handshake Complete 568 <--- send/receive --- 569 Handshake Received 570 Get Handshake 572 Figure 4: Interaction Summary between QUIC and TLS 574 4.3. TLS Version 576 This document describes how TLS 1.3 [TLS13] is used with QUIC. 578 In practice, the TLS handshake will negotiate a version of TLS to 579 use. This could result in a newer version of TLS than 1.3 being 580 negotiated if both endpoints support that version. This is 581 acceptable provided that the features of TLS 1.3 that are used by 582 QUIC are supported by the newer version. 584 A badly configured TLS implementation could negotiate TLS 1.2 or 585 another older version of TLS. An endpoint MUST terminate the 586 connection if a version of TLS older than 1.3 is negotiated. 588 4.4. ClientHello Size 590 QUIC requires that the initial handshake packet from a client fit 591 within the payload of a single packet. The size limits on QUIC 592 packets mean that a record containing a ClientHello needs to fit 593 within 1171 octets. 595 A TLS ClientHello can fit within this limit with ample space 596 remaining. However, there are several variables that could cause 597 this limit to be exceeded. Implementations are reminded that large 598 session tickets or HelloRetryRequest cookies, multiple or large key 599 shares, and long lists of supported ciphers, signature algorithms, 600 versions, QUIC transport parameters, and other negotiable parameters 601 and extensions could cause this message to grow. 603 For servers, the size of the session tickets and HelloRetryRequest 604 cookie extension can have an effect on a client's ability to connect. 605 Choosing a small value increases the probability that these values 606 can be successfully used by a client. 608 The TLS implementation does not need to ensure that the ClientHello 609 is sufficiently large. QUIC PADDING frames are added to increase the 610 size of the packet as necessary. 612 4.5. Peer Authentication 614 The requirements for authentication depend on the application 615 protocol that is in use. TLS provides server authentication and 616 permits the server to request client authentication. 618 A client MUST authenticate the identity of the server. This 619 typically involves verification that the identity of the server is 620 included in a certificate and that the certificate is issued by a 621 trusted entity (see for example [RFC2818]). 623 A server MAY request that the client authenticate during the 624 handshake. A server MAY refuse a connection if the client is unable 625 to authenticate when requested. The requirements for client 626 authentication vary based on application protocol and deployment. 628 A server MUST NOT use post-handshake client authentication (see 629 Section 4.6.2 of [TLS13]). 631 4.6. TLS Errors 633 Errors in the TLS connection SHOULD be signaled using TLS alerts on 634 stream 0. A failure in the handshake MUST be treated as a QUIC 635 connection error of type TLS_HANDSHAKE_FAILED. Once the handshake is 636 complete, an error in the TLS connection that causes a TLS alert to 637 be sent or received MUST be treated as a QUIC connection error of 638 type TLS_FATAL_ALERT_GENERATED or TLS_FATAL_ALERT_RECEIVED 639 respectively. 641 5. QUIC Packet Protection 643 QUIC packet protection provides authenticated encryption of packets. 644 This provides confidentiality and integrity protection for the 645 content of packets (see Section 5.3). Packet protection uses keys 646 that are exported from the TLS connection (see Section 5.2). 648 Different keys are used for QUIC packet protection and TLS record 649 protection. TLS handshake messages are protected solely with TLS 650 record protection, but post-handshake messages are redundantly 651 proteted with both both the QUIC packet protection and the TLS record 652 protection. These messages are limited in number, and so the 653 additional overhead is small. 655 5.1. Installing New Keys 657 As TLS reports the availability of keying material, the packet 658 protection keys and initialization vectors (IVs) are updated (see 659 Section 5.2). The selection of AEAD function is also updated to 660 match the AEAD negotiated by TLS. 662 For packets other than any handshake packets (see Section 6.1), once 663 a change of keys has been made, packets with higher packet numbers 664 MUST be sent with the new keying material. The KEY_PHASE bit on 665 these packets is inverted each time new keys are installed to signal 666 the use of the new keys to the recipient (see Section 6 for details). 668 An endpoint retransmits stream data in a new packet. New packets 669 have new packet numbers and use the latest packet protection keys. 671 This simplifies key management when there are key updates (see 672 Section 6.2). 674 5.2. QUIC Key Expansion 676 QUIC uses a system of packet protection secrets, keys and IVs that 677 are modelled on the system used in TLS [TLS13]. The secrets that 678 QUIC uses as the basis of its key schedule are obtained using TLS 679 exporters (see Section 7.5 of [TLS13]). 681 QUIC uses HKDF with the same hash function negotiated by TLS for key 682 derivation. For example, if TLS is using the TLS_AES_128_GCM_SHA256, 683 the SHA-256 hash function is used. 685 5.2.1. Handshake Secrets 687 Packets that carry the TLS handshake (Initial, Retry, and Handshake) 688 are protected with secrets derived from the connection ID used in the 689 client's Initial packet. Specifically: 691 quic_version_1_salt = afc824ec5fc77eca1e9d36f37fb2d46518c36639 693 handshake_secret = HKDF-Extract(quic_version_1_salt, 694 client_connection_id) 696 client_handshake_secret = 697 QHKDF-Expand(handshake_secret, "client hs", Hash.length) 698 server_handshake_secret = 699 QHKDF-Expand(handshake_secret, "server hs", Hash.length) 701 The HKDF for the handshake secrets and keys derived from them uses 702 the SHA-256 hash function [FIPS180]. 704 The salt value is a 20 octet sequence shown in the figure in 705 hexadecimal notation. Future versions of QUIC SHOULD generate a new 706 salt value, thus ensuring that the keys are different for each 707 version of QUIC. This prevents a middlebox that only recognizes one 708 version of QUIC from seeing or modifying the contents of handshake 709 packets from future versions. 711 5.2.2. 0-RTT Secret 713 0-RTT keys are those keys that are used in resumed connections prior 714 to the completion of the TLS handshake. Data sent using 0-RTT keys 715 might be replayed and so has some restrictions on its use, see 716 Section 8.2. 0-RTT keys are used after sending or receiving a 717 ClientHello. 719 The secret is exported from TLS using the exporter label "EXPORTER- 720 QUIC 0rtt" and an empty context. The size of the secret MUST be the 721 size of the hash output for the PRF hash function negotiated by TLS. 722 This uses the TLS early_exporter_secret. The QUIC 0-RTT secret is 723 only used for protection of packets sent by the client. 725 client_0rtt_secret 726 = TLS-Exporter("EXPORTER-QUIC 0rtt", "", Hash.length) 728 5.2.3. 1-RTT Secrets 730 1-RTT keys are used by both client and server after the TLS handshake 731 completes. There are two secrets used at any time: one is used to 732 derive packet protection keys for packets sent by the client, the 733 other for packet protection keys on packets sent by the server. 735 The initial client packet protection secret is exported from TLS 736 using the exporter label "EXPORTER-QUIC client 1rtt"; the initial 737 server packet protection secret uses the exporter label "EXPORTER- 738 QUIC server 1rtt". Both exporters use an empty context. The size of 739 the secret MUST be the size of the hash output for the PRF hash 740 function negotiated by TLS. 742 client_pp_secret_0 = 743 TLS-Exporter("EXPORTER-QUIC client 1rtt", "", Hash.length) 744 server_pp_secret_0 = 745 TLS-Exporter("EXPORTER-QUIC server 1rtt", "", Hash.length) 747 These secrets are used to derive the initial client and server packet 748 protection keys. 750 After a key update (see Section 6.2), these secrets are updated using 751 the QHKDF-Expand function. The QHKDF-Expand function is similar in 752 definition to HKDF-Expand-Label defined in Section 7.1 of [TLS13], 753 but it has a different base label and omits the hash argument. 754 QHKDF-Expand uses the PRF hash function negotiated by TLS. The 755 replacement secret is derived using the existing Secret, a Label of 756 "client 1rtt" for the client and "server 1rtt" for the server, and 757 the same output Length as the PRF hash function selected by TLS. 759 client_pp_secret_ = 760 QHKDF-Expand(client_pp_secret_, "client 1rtt", Hash.length) 761 server_pp_secret_ = 762 QHKDF-Expand(server_pp_secret_, "server 1rtt", Hash.length) 764 This allows for a succession of new secrets to be created as needed. 766 HKDF-Expand-Label uses HKDF-Expand [RFC5869] as shown: 768 QHKDF-Expand(Secret, Label, Length) = 769 HKDF-Expand(Secret, QuicHkdfLabel, Length) 771 Where the info parameter, QuicHkdfLabel, is specified as: 773 struct { 774 uint16 length = Length; 775 opaque label<6..255> = "QUIC " + Label; 776 uint8 hashLength = 0; 777 } QuicHkdfLabel; 779 For example, the client packet protection secret uses an info 780 parameter of: 782 info = (HashLen / 256) || (HashLen % 256) || 0x1f || 783 "QUIC client 1rtt" || 0x00 785 5.2.4. Packet Protection Key and IV 787 The complete key expansion uses an identical process for key 788 expansion as defined in Section 7.3 of [TLS13], using different 789 values for the input secret and labels. QUIC uses the AEAD function 790 negotiated by TLS. 792 The packet protection key and IV used to protect the 0-RTT packets 793 sent by a client are derived from the QUIC 0-RTT secret. The packet 794 protection keys and IVs for 1-RTT packets sent by the client and 795 server are derived from the current generation of client and server 796 1-RTT secrets (client_pp_secret_ and server_pp_secret_) 797 respectively. The length of the output is determined by the 798 requirements of the AEAD function selected by TLS. All ciphersuites 799 currently used for QUIC have a 16-byte authentication tag and produce 800 an ouput 16 bytes larger than their input. The key length is the 801 AEAD key size. As defined in Section 5.3 of [TLS13], the IV length 802 is the larger of 8 or N_MIN (see Section 4 of [AEAD]; all 803 ciphersuites defined in [TLS13] have N_MIN set to 12). For any 804 secret S, the corresponding key and IV are derived as shown below: 806 key = QHKDF-Expand(S, "key", key_length) 807 iv = QHKDF-Expand(S, "iv", iv_length) 809 The QUIC record protection initially starts without keying material. 810 When the TLS state machine reports that the ClientHello has been 811 sent, the 0-RTT keys can be generated and installed for writing. 812 When the TLS state machine reports completion of the handshake, the 813 1-RTT keys can be generated and installed for writing. 815 5.3. QUIC AEAD Usage 817 The Authentication Encryption with Associated Data (AEAD) [AEAD] 818 function used for QUIC packet protection is AEAD that is negotiated 819 for use with the TLS connection. For example, if TLS is using the 820 TLS_AES_128_GCM_SHA256, the AEAD_AES_128_GCM function is used. 822 All QUIC packets other than Version Negotiation and Stateless Reset 823 packets are protected with an AEAD algorithm [AEAD]. Prior to 824 establishing a shared secret, packets are protected with 825 AEAD_AES_128_GCM and a key derived from the client's connection ID 826 (see Section 5.2.1). This provides protection against off-path 827 attackers and robustness against QUIC version unaware middleboxes, 828 but not against on-path attackers. 830 Once TLS has provided a key, the contents of regular QUIC packets 831 immediately after any TLS messages have been sent are protected by 832 the AEAD selected by TLS. 834 The key, K, is either the client packet protection key 835 (client_pp_key_) or the server packet protection key 836 (server_pp_key_), derived as defined in Section 5.2. 838 The nonce, N, is formed by combining the packet protection IV (either 839 client_pp_iv_ or server_pp_iv_) with the packet number. The 64 840 bits of the reconstructed QUIC packet number in network byte order is 841 left-padded with zeros to the size of the IV. The exclusive OR of 842 the padded packet number and the IV forms the AEAD nonce. 844 The associated data, A, for the AEAD is the contents of the QUIC 845 header, starting from the flags octet in either the short or long 846 header. 848 The input plaintext, P, for the AEAD is the content of the QUIC frame 849 following the header, as described in [QUIC-TRANSPORT]. 851 The output ciphertext, C, of the AEAD is transmitted in place of P. 853 5.4. Packet Numbers 855 QUIC has a single, contiguous packet number space. In comparison, 856 TLS restarts its sequence number each time that record protection 857 keys are changed. The sequence number restart in TLS ensures that a 858 compromise of the current traffic keys does not allow an attacker to 859 truncate the data that is sent after a key update by sending 860 additional packets under the old key (causing new packets to be 861 discarded). 863 QUIC does not assume a reliable transport and is required to handle 864 attacks where packets are dropped in other ways. QUIC is therefore 865 not affected by this form of truncation. 867 The QUIC packet number is not reset and it is not permitted to go 868 higher than its maximum value of 2^64-1. This establishes a hard 869 limit on the number of packets that can be sent. 871 Some AEAD functions have limits for how many packets can be encrypted 872 under the same key and IV (see for example [AEBounds]). This might 873 be lower than the packet number limit. An endpoint MUST initiate a 874 key update (Section 6.2) prior to exceeding any limit set for the 875 AEAD that is in use. 877 TLS maintains a separate sequence number that is used for record 878 protection on the connection that is hosted on stream 0. This 879 sequence number is not visible to QUIC. 881 5.5. Receiving Protected Packets 883 Once an endpoint successfully receives a packet with a given packet 884 number, it MUST discard all packets with higher packet numbers if 885 they cannot be successfully unprotected with either the same key, or 886 - if there is a key update - the next packet protection key (see 887 Section 6.2). Similarly, a packet that appears to trigger a key 888 update, but cannot be unprotected successfully MUST be discarded. 890 Failure to unprotect a packet does not necessarily indicate the 891 existence of a protocol error in a peer or an attack. The truncated 892 packet number encoding used in QUIC can cause packet numbers to be 893 decoded incorrectly if they are delayed significantly. 895 5.6. Packet Number Gaps 897 Section 7.7.1.1 of [QUIC-TRANSPORT] also requires a secret to compute 898 packet number gaps on connection ID transitions. That secret is 899 computed as: 901 packet_number_secret = 902 TLS-Exporter("EXPORTER-QUIC packet number", "", Hash.length) 904 6. Key Phases 906 As TLS reports the availability of 0-RTT and 1-RTT keys, new keying 907 material can be exported from TLS and used for QUIC packet 908 protection. At each transition during the handshake a new secret is 909 exported from TLS and packet protection keys are derived from that 910 secret. 912 Every time that a new set of keys is used for protecting outbound 913 packets, the KEY_PHASE bit in the public flags is toggled. 0-RTT 914 protected packets use the QUIC long header, they do not use the 915 KEY_PHASE bit to select the correct keys (see Section 6.1.1). 917 Once the connection is fully enabled, the KEY_PHASE bit allows a 918 recipient to detect a change in keying material without necessarily 919 needing to receive the first packet that triggered the change. An 920 endpoint that notices a changed KEY_PHASE bit can update keys and 921 decrypt the packet that contains the changed bit, see Section 6.2. 923 The KEY_PHASE bit is included as the 0x20 bit of the QUIC short 924 header. 926 Transitions between keys during the handshake are complicated by the 927 need to ensure that TLS handshake messages are sent with the correct 928 packet protection. 930 6.1. Packet Protection for the TLS Handshake 932 The initial exchange of packets that carry the TLS handshake are 933 AEAD-protected using the handshake secrets generated as described in 934 Section 5.2.1. All TLS handshake messages up to the TLS Finished 935 message sent by either endpoint use packets protected with handshake 936 keys. 938 Any TLS handshake messages that are sent after completing the TLS 939 handshake do not need special packet protection rules. Packets 940 containing these messages use the packet protection keys that are 941 current at the time of sending (or retransmission). 943 Like the client, a server MUST send retransmissions of its 944 unprotected handshake messages or acknowledgments for unprotected 945 handshake messages sent by the client in packets protected with 946 handshake keys. 948 6.1.1. Initial Key Transitions 950 Once the TLS handshake is complete, keying material is exported from 951 TLS and used to protect QUIC packets. 953 Packets protected with 1-RTT keys initially have a KEY_PHASE bit set 954 to 0. This bit inverts with each subsequent key update (see 955 Section 6.2). 957 If the client sends 0-RTT data, it uses the 0-RTT packet type. The 958 packet that contains the TLS EndOfEarlyData and Finished messages are 959 sent in packets protected with handshake keys. 961 Using distinct packet types during the handshake for handshake 962 messages, 0-RTT data, and 1-RTT data ensures that the server is able 963 to distinguish between the different keys used to remove packet 964 protection. All of these packets can arrive concurrently at a 965 server. 967 A server might choose to retain 0-RTT packets that arrive before a 968 TLS ClientHello. The server can then use those packets once the 969 ClientHello arrives. However, the potential for denial of service 970 from buffering 0-RTT packets is significant. These packets cannot be 971 authenticated and so might be employed by an attacker to exhaust 972 server resources. Limiting the number of packets that are saved 973 might be necessary. 975 The server transitions to using 1-RTT keys after sending its first 976 flight of TLS handshake messages, ending in the Finished. From this 977 point, the server protects all packets with 1-RTT keys. Future 978 packets are therefore protected with 1-RTT keys. Initially, these 979 are marked with a KEY_PHASE of 0. 981 6.1.2. Retransmission and Acknowledgment of Unprotected Packets 983 TLS handshake messages from both client and server are critical to 984 the key exchange. The contents of these messages determines the keys 985 used to protect later messages. If these handshake messages are 986 included in packets that are protected with these keys, they will be 987 indecipherable to the recipient. 989 Even though newer keys could be available when retransmitting, 990 retransmissions of these handshake messages MUST be sent in packets 991 protected with handshake keys. An endpoint MUST generate ACK frames 992 for these messages and send them in packets protected with handshake 993 keys. 995 A HelloRetryRequest handshake message might be used to reject an 996 initial ClientHello. A HelloRetryRequest handshake message is sent 997 in a Retry packet; any second ClientHello that is sent in response 998 uses a Initial packet type. These packets are only protected with a 999 predictable key (see Section 5.2.1). This is natural, because no 1000 shared secret will be available when these messages need to be sent. 1001 Upon receipt of a HelloRetryRequest, a client SHOULD cease any 1002 transmission of 0-RTT data; 0-RTT data will only be discarded by any 1003 server that sends a HelloRetryRequest. 1005 The packet type ensures that protected packets are clearly 1006 distinguished from unprotected packets. Loss or reordering might 1007 cause unprotected packets to arrive once 1-RTT keys are in use, 1008 unprotected packets are easily distinguished from 1-RTT packets using 1009 the packet type. 1011 Once 1-RTT keys are available to an endpoint, it no longer needs the 1012 TLS handshake messages that are carried in unprotected packets. 1013 However, a server might need to retransmit its TLS handshake messages 1014 in response to receiving an unprotected packet that contains ACK 1015 frames. A server MUST process ACK frames in unprotected packets 1016 until the TLS handshake is reported as complete, or it receives an 1017 ACK frame in a protected packet that acknowledges all of its 1018 handshake messages. 1020 To limit the number of key phases that could be active, an endpoint 1021 MUST NOT initiate a key update while there are any unacknowledged 1022 handshake messages, see Section 6.2. 1024 6.2. Key Update 1026 Once the TLS handshake is complete, the KEY_PHASE bit allows for 1027 refreshes of keying material by either peer. Endpoints start using 1028 updated keys immediately without additional signaling; the change in 1029 the KEY_PHASE bit indicates that a new key is in use. 1031 An endpoint MUST NOT initiate more than one key update at a time. A 1032 new key cannot be used until the endpoint has received and 1033 successfully decrypted a packet with a matching KEY_PHASE. Note that 1034 when 0-RTT is attempted the value of the KEY_PHASE bit will be 1035 different on packets sent by either peer. 1037 A receiving endpoint detects an update when the KEY_PHASE bit doesn't 1038 match what it is expecting. It creates a new secret (see 1039 Section 5.2) and the corresponding read key and IV. If the packet 1040 can be decrypted and authenticated using these values, then the keys 1041 it uses for packet protection are also updated. The next packet sent 1042 by the endpoint will then use the new keys. 1044 An endpoint doesn't need to send packets immediately when it detects 1045 that its peer has updated keys. The next packet that it sends will 1046 simply use the new keys. If an endpoint detects a second update 1047 before it has sent any packets with updated keys it indicates that 1048 its peer has updated keys twice without awaiting a reciprocal update. 1049 An endpoint MUST treat consecutive key updates as a fatal error and 1050 abort the connection. 1052 An endpoint SHOULD retain old keys for a short period to allow it to 1053 decrypt packets with smaller packet numbers than the packet that 1054 triggered the key update. This allows an endpoint to consume packets 1055 that are reordered around the transition between keys. Packets with 1056 higher packet numbers always use the updated keys and MUST NOT be 1057 decrypted with old keys. 1059 Keys and their corresponding secrets SHOULD be discarded when an 1060 endpoint has received all packets with sequence numbers lower than 1061 the lowest sequence number used for the new key. An endpoint might 1062 discard keys if it determines that the length of the delay to 1063 affected packets is excessive. 1065 This ensures that once the handshake is complete, packets with the 1066 same KEY_PHASE will have the same packet protection keys, unless 1067 there are multiple key updates in a short time frame succession and 1068 significant packet reordering. 1070 Initiating Peer Responding Peer 1072 @M QUIC Frames 1073 New Keys -> @N 1074 @N QUIC Frames 1075 --------> 1076 QUIC Frames @M 1077 New Keys -> @N 1078 QUIC Frames @N 1079 <-------- 1081 Figure 5: Key Update 1083 As shown in Figure 3 and Figure 5, there is never a situation where 1084 there are more than two different sets of keying material that might 1085 be received by a peer. Once both sending and receiving keys have 1086 been updated, 1088 A server cannot initiate a key update until it has received the 1089 client's Finished message. Otherwise, packets protected by the 1090 updated keys could be confused for retransmissions of handshake 1091 messages. A client cannot initiate a key update until all of its 1092 handshake messages have been acknowledged by the server. 1094 A packet that triggers a key update could arrive after successfully 1095 processing a packet with a higher packet number. This is only 1096 possible if there is a key compromise and an attack, or if the peer 1097 is incorrectly reverting to use of old keys. Because the latter 1098 cannot be differentiated from an attack, an endpoint MUST immediately 1099 terminate the connection if it detects this condition. 1101 7. Client Address Validation 1103 Two tools are provided by TLS to enable validation of client source 1104 addresses at a server: the cookie in the HelloRetryRequest message, 1105 and the ticket in the NewSessionTicket message. 1107 7.1. HelloRetryRequest Address Validation 1109 The cookie extension in the TLS HelloRetryRequest message allows a 1110 server to perform source address validation during the handshake. 1112 When QUIC requests address validation during the processing of the 1113 first ClientHello, the token it provides is included in the cookie 1114 extension of a HelloRetryRequest. As long as the cookie cannot be 1115 successfully guessed by a client, the server can be assured that the 1116 client received the HelloRetryRequest if it includes the value in a 1117 second ClientHello. 1119 An initial ClientHello never includes a cookie extension. Thus, if a 1120 server constructs a cookie that contains all the information 1121 necessary to reconstruct state, it can discard local state after 1122 sending a HelloRetryRequest. Presence of a valid cookie in a 1123 ClientHello indicates that the ClientHello is a second attempt from 1124 the client. 1126 An address validation token can be extracted from a second 1127 ClientHello and passed to the transport for further validation. If 1128 that validation fails, the server MUST fail the TLS handshake and 1129 send an illegal_parameter alert. 1131 Combining address validation with the other uses of HelloRetryRequest 1132 ensures that there are fewer ways in which an additional round-trip 1133 can be added to the handshake. In particular, this makes it possible 1134 to combine a request for address validation with a request for a 1135 different client key share. 1137 If TLS needs to send a HelloRetryRequest for other reasons, it needs 1138 to ensure that it can correctly identify the reason that the 1139 HelloRetryRequest was generated. During the processing of a second 1140 ClientHello, TLS does not need to consult the transport protocol 1141 regarding address validation if address validation was not requested 1142 originally. In such cases, the cookie extension could either be 1143 absent or it could indicate that an address validation token is not 1144 present. 1146 7.1.1. Stateless Address Validation 1148 A server can use the cookie extension to store all state necessary to 1149 continue the connection. This allows a server to avoid committing 1150 state for clients that have unvalidated source addresses. 1152 For instance, a server could use a statically-configured key to 1153 encrypt the information that it requires and include that information 1154 in the cookie. In addition to address validation information, a 1155 server that uses encryption also needs to be able recover the hash of 1156 the ClientHello and its length, plus any information it needs in 1157 order to reconstruct the HelloRetryRequest. 1159 7.1.2. Sending HelloRetryRequest 1161 A server does not need to maintain state for the connection when 1162 sending a HelloRetryRequest message. This might be necessary to 1163 avoid creating a denial of service exposure for the server. However, 1164 this means that information about the transport will be lost at the 1165 server. This includes the stream offset of stream 0, the packet 1166 number that the server selects, and any opportunity to measure round 1167 trip time. 1169 A server MUST send a TLS HelloRetryRequest in a Retry packet. Using 1170 a Retry packet causes the client to reset stream offsets. It also 1171 avoids the need for the server select an initial packet number, which 1172 would need to be remembered so that subsequent packets could be 1173 correctly numbered. 1175 A HelloRetryRequest message MUST NOT be split between multiple Retry 1176 packets. This means that HelloRetryRequest is subject to the same 1177 size constraints as a ClientHello (see Section 4.4). 1179 A client might send multiple Initial packets in response to loss. If 1180 a server sends a Retry packet in response to an Initial packet, it 1181 does not have to generate the same Retry packet each time. 1182 Variations in Retry packet, if used by a client, could lead to 1183 multiple connections derived from the same ClientHello. Reuse of the 1184 client nonce is not supported by TLS and could lead to security 1185 vulnerabilities. Clients that receive multiple Retry packets MUST 1186 use only one and discard the remainder. 1188 7.2. NewSessionTicket Address Validation 1190 The ticket in the TLS NewSessionTicket message allows a server to 1191 provide a client with a similar sort of token. When a client resumes 1192 a TLS connection - whether or not 0-RTT is attempted - it includes 1193 the ticket in the handshake message. As with the HelloRetryRequest 1194 cookie, the server includes the address validation token in the 1195 ticket. TLS provides the token it extracts from the session ticket 1196 to the transport when it asks whether source address validation is 1197 needed. 1199 If both a HelloRetryRequest cookie and a session ticket are present 1200 in the ClientHello, only the token from the cookie is passed to the 1201 transport. The presence of a cookie indicates that this is a second 1202 ClientHello - the token from the session ticket will have been 1203 provided to the transport when it appeared in the first ClientHello. 1205 A server can send a NewSessionTicket message at any time. This 1206 allows it to update the state - and the address validation token - 1207 that is included in the ticket. This might be done to refresh the 1208 ticket or token, or it might be generated in response to changes in 1209 the state of the connection. QUIC can request that a 1210 NewSessionTicket be sent by providing a new address validation token. 1212 A server that intends to support 0-RTT SHOULD provide an address 1213 validation token immediately after completing the TLS handshake. 1215 7.3. Address Validation Token Integrity 1217 TLS MUST provide integrity protection for address validation token 1218 unless the transport guarantees integrity protection by other means. 1219 For a NewSessionTicket that includes confidential information - such 1220 as the resumption secret - including the token under authenticated 1221 encryption ensures that the token gains both confidentiality and 1222 integrity protection without duplicating the overheads of that 1223 protection. 1225 8. Pre-handshake QUIC Messages 1227 Implementations MUST NOT exchange data on any stream other than 1228 stream 0 without packet protection. QUIC requires the use of several 1229 types of frame for managing loss detection and recovery during this 1230 phase. In addition, it might be useful to use the data acquired 1231 during the exchange of unauthenticated messages for congestion 1232 control. 1234 This section generally only applies to TLS handshake messages from 1235 both peers and acknowledgments of the packets carrying those 1236 messages. In many cases, the need for servers to provide 1237 acknowledgments is minimal, since the messages that clients send are 1238 small and implicitly acknowledged by the server's responses. 1240 The actions that a peer takes as a result of receiving an 1241 unauthenticated packet needs to be limited. In particular, state 1242 established by these packets cannot be retained once record 1243 protection commences. 1245 There are several approaches possible for dealing with 1246 unauthenticated packets prior to handshake completion: 1248 o discard and ignore them 1250 o use them, but reset any state that is established once the 1251 handshake completes 1253 o use them and authenticate them afterwards; failing the handshake 1254 if they can't be authenticated 1256 o save them and use them when they can be properly authenticated 1258 o treat them as a fatal error 1260 Different strategies are appropriate for different types of data. 1261 This document proposes that all strategies are possible depending on 1262 the type of message. 1264 o Transport parameters are made usable and authenticated as part of 1265 the TLS handshake (see Section 9.2). 1267 o Most unprotected messages are treated as fatal errors when 1268 received except for the small number necessary to permit the 1269 handshake to complete (see Section 8.1). 1271 o Protected packets can either be discarded or saved and later used 1272 (see Section 8.3). 1274 8.1. Unprotected Packets Prior to Handshake Completion 1276 This section describes the handling of messages that are sent and 1277 received prior to the completion of the TLS handshake. 1279 Sending and receiving unprotected messages is hazardous. Unless 1280 expressly permitted, receipt of an unprotected message of any kind 1281 MUST be treated as a fatal error. 1283 8.1.1. STREAM Frames 1285 "STREAM" frames for stream 0 are permitted. These carry the TLS 1286 handshake messages. Once 1-RTT keys are available, unprotected 1287 "STREAM" frames on stream 0 can be ignored. 1289 Receiving unprotected "STREAM" frames for other streams MUST be 1290 treated as a fatal error. 1292 8.1.2. ACK Frames 1294 "ACK" frames are permitted prior to the handshake being complete. 1295 Information learned from "ACK" frames cannot be entirely relied upon, 1296 since an attacker is able to inject these packets. Timing and packet 1297 retransmission information from "ACK" frames is critical to the 1298 functioning of the protocol, but these frames might be spoofed or 1299 altered. 1301 Endpoints MUST NOT use an "ACK" frame in an unprotected packet to 1302 acknowledge packets that were protected by 0-RTT or 1-RTT keys. An 1303 endpoint MUST treat receipt of an "ACK" frame in an unprotected 1304 packet that claims to acknowledge protected packets as a connection 1305 error of type OPTIMISTIC_ACK. An endpoint that can read protected 1306 data is always able to send protected data. 1308 Note: 0-RTT data can be acknowledged by the server as it receives 1309 it, but any packets containing acknowledgments of 0-RTT data 1310 cannot have packet protection removed by the client until the TLS 1311 handshake is complete. The 1-RTT keys necessary to remove packet 1312 protection cannot be derived until the client receives all server 1313 handshake messages. 1315 An endpoint SHOULD use data from "ACK" frames carried in unprotected 1316 packets or packets protected with 0-RTT keys only during the initial 1317 handshake. All "ACK" frames contained in unprotected packets that 1318 are received after successful receipt of a packet protected with 1319 1-RTT keys MUST be discarded. An endpoint SHOULD therefore include 1320 acknowledgments for unprotected and any packets protected with 0-RTT 1321 keys until it sees an acknowledgment for a packet that is both 1322 protected with 1-RTT keys and contains an "ACK" frame. 1324 8.1.3. Updates to Data and Stream Limits 1326 "MAX_DATA", "MAX_STREAM_DATA", "BLOCKED", "STREAM_BLOCKED", and 1327 "MAX_STREAM_ID" frames MUST NOT be sent unprotected. 1329 Though data is exchanged on stream 0, the initial flow control window 1330 on that stream is sufficiently large to allow the TLS handshake to 1331 complete. This limits the maximum size of the TLS handshake and 1332 would prevent a server or client from using an abnormally large 1333 certificate chain. 1335 Stream 0 is exempt from the connection-level flow control window. 1337 Consequently, there is no need to signal being blocked on flow 1338 control. 1340 Similarly, there is no need to increase the number of allowed streams 1341 until the handshake completes. 1343 8.1.4. Handshake Failures 1345 The "CONNECTION_CLOSE" frame MAY be sent by either endpoint in a 1346 Handshake packet. This allows an endpoint to signal a fatal error 1347 with connection establishment. A "STREAM" frame carrying a TLS alert 1348 MAY be included in the same packet. 1350 8.1.5. Denial of Service with Unprotected Packets 1352 Accepting unprotected - specifically unauthenticated - packets 1353 presents a denial of service risk to endpoints. An attacker that is 1354 able to inject unprotected packets can cause a recipient to drop even 1355 protected packets with a matching sequence number. The spurious 1356 packet shadows the genuine packet, causing the genuine packet to be 1357 ignored as redundant. 1359 Once the TLS handshake is complete, both peers MUST ignore 1360 unprotected packets. From that point onward, unprotected messages 1361 can be safely dropped. 1363 Since only TLS handshake packets and acknowledgments are sent in the 1364 clear, an attacker is able to force implementations to rely on 1365 retransmission for packets that are lost or shadowed. Thus, an 1366 attacker that intends to deny service to an endpoint has to drop or 1367 shadow protected packets in order to ensure that their victim 1368 continues to accept unprotected packets. The ability to shadow 1369 packets means that an attacker does not need to be on path. 1371 In addition to causing valid packets to be dropped, an attacker can 1372 generate packets with an intent of causing the recipient to expend 1373 processing resources. See Section 10.2 for a discussion of these 1374 risks. 1376 To avoid receiving TLS packets that contain no useful data, a TLS 1377 implementation MUST reject empty TLS handshake records and any record 1378 that is not permitted by the TLS state machine. Any TLS application 1379 data or alerts that is received prior to the end of the handshake 1380 MUST be treated as a fatal error. 1382 8.2. Use of 0-RTT Keys 1384 If 0-RTT keys are available, the lack of replay protection means that 1385 restrictions on their use are necessary to avoid replay attacks on 1386 the protocol. 1388 A client MUST only use 0-RTT keys to protect data that is idempotent. 1389 A client MAY wish to apply additional restrictions on what data it 1390 sends prior to the completion of the TLS handshake. A client 1391 otherwise treats 0-RTT keys as equivalent to 1-RTT keys. 1393 A client that receives an indication that its 0-RTT data has been 1394 accepted by a server can send 0-RTT data until it receives all of the 1395 server's handshake messages. A client SHOULD stop sending 0-RTT data 1396 if it receives an indication that 0-RTT data has been rejected. 1398 A server MUST NOT use 0-RTT keys to protect packets. 1400 8.3. Receiving Out-of-Order Protected Frames 1402 Due to reordering and loss, protected packets might be received by an 1403 endpoint before the final TLS handshake messages are received. A 1404 client will be unable to decrypt 1-RTT packets from the server, 1405 whereas a server will be able to decrypt 1-RTT packets from the 1406 client. 1408 Packets protected with 1-RTT keys MAY be stored and later decrypted 1409 and used once the handshake is complete. A server MUST NOT use 1-RTT 1410 protected packets before verifying either the client Finished message 1411 or - in the case that the server has chosen to use a pre-shared key - 1412 the pre-shared key binder (see Section 4.2.8 of [TLS13]). Verifying 1413 these values provides the server with an assurance that the 1414 ClientHello has not been modified. 1416 A server could receive packets protected with 0-RTT keys prior to 1417 receiving a TLS ClientHello. The server MAY retain these packets for 1418 later decryption in anticipation of receiving a ClientHello. 1420 Receiving and verifying the TLS Finished message is critical in 1421 ensuring the integrity of the TLS handshake. A server MUST NOT use 1422 protected packets from the client prior to verifying the client 1423 Finished message if its response depends on client authentication. 1425 9. QUIC-Specific Additions to the TLS Handshake 1427 QUIC uses the TLS handshake for more than just negotiation of 1428 cryptographic parameters. The TLS handshake validates protocol 1429 version selection, provides preliminary values for QUIC transport 1430 parameters, and allows a server to perform return routeability checks 1431 on clients. 1433 9.1. Protocol and Version Negotiation 1435 The QUIC version negotiation mechanism is used to negotiate the 1436 version of QUIC that is used prior to the completion of the 1437 handshake. However, this packet is not authenticated, enabling an 1438 active attacker to force a version downgrade. 1440 To ensure that a QUIC version downgrade is not forced by an attacker, 1441 version information is copied into the TLS handshake, which provides 1442 integrity protection for the QUIC negotiation. This does not prevent 1443 version downgrade prior to the completion of the handshake, though it 1444 means that a downgrade causes a handshake failure. 1446 TLS uses Application Layer Protocol Negotiation (ALPN) [RFC7301] to 1447 select an application protocol. The application-layer protocol MAY 1448 restrict the QUIC versions that it can operate over. Servers MUST 1449 select an application protocol compatible with the QUIC version that 1450 the client has selected. 1452 If the server cannot select a compatible combination of application 1453 protocol and QUIC version, it MUST abort the connection. A client 1454 MUST abort a connection if the server picks an incompatible 1455 combination of QUIC version and ALPN identifier. 1457 9.2. QUIC Transport Parameters Extension 1459 QUIC transport parameters are carried in a TLS extension. Different 1460 versions of QUIC might define a different format for this struct. 1462 Including transport parameters in the TLS handshake provides 1463 integrity protection for these values. 1465 enum { 1466 quic_transport_parameters(26), (65535) 1467 } ExtensionType; 1469 The "extension_data" field of the quic_transport_parameters extension 1470 contains a value that is defined by the version of QUIC that is in 1471 use. The quic_transport_parameters extension carries a 1472 TransportParameters when the version of QUIC defined in 1473 [QUIC-TRANSPORT] is used. 1475 The quic_transport_parameters extension is carried in the ClientHello 1476 and the EncryptedExtensions messages during the handshake. 1478 9.3. Priming 0-RTT 1480 QUIC uses TLS without modification. Therefore, it is possible to use 1481 a pre-shared key that was established in a TLS handshake over TCP to 1482 enable 0-RTT in QUIC. Similarly, QUIC can provide a pre-shared key 1483 that can be used to enable 0-RTT in TCP. 1485 All the restrictions on the use of 0-RTT apply, with the exception of 1486 the ALPN label, which MUST only change to a label that is explicitly 1487 designated as being compatible. The client indicates which ALPN 1488 label it has chosen by placing that ALPN label first in the ALPN 1489 extension. In order to be usable for 0-RTT, the NewSessionTicket 1490 MUST contain the "max_early_data" extension with the value 1491 0xffffffff; the amount of data which the client can send in 0-RTT is 1492 controlled by the "initial_max_data" transport parameter supplied by 1493 the server. A client MUST treat receipt of a NewSessionTicket that 1494 contains a "max_early_data" extension with any other value as a 1495 connection error of type PROTOCOL_VIOLATION. 1497 The certificate that the server uses MUST be considered valid for 1498 both connections, which will use different protocol stacks and could 1499 use different port numbers. For instance, HTTP/1.1 and HTTP/2 1500 operate over TLS and TCP, whereas QUIC operates over UDP. 1502 Source address validation is not completely portable between 1503 different protocol stacks. Even if the source IP address remains 1504 constant, the port number is likely to be different. Packet 1505 reflection attacks are still possible in this situation, though the 1506 set of hosts that can initiate these attacks is greatly reduced. A 1507 server might choose to avoid source address validation for such a 1508 connection, or allow an increase to the amount of data that it sends 1509 toward the client without source validation. 1511 10. Security Considerations 1513 There are likely to be some real clangers here eventually, but the 1514 current set of issues is well captured in the relevant sections of 1515 the main text. 1517 Never assume that because it isn't in the security considerations 1518 section it doesn't affect security. Most of this document does. 1520 10.1. Packet Reflection Attack Mitigation 1522 A small ClientHello that results in a large block of handshake 1523 messages from a server can be used in packet reflection attacks to 1524 amplify the traffic generated by an attacker. 1526 Certificate caching [RFC7924] can reduce the size of the server's 1527 handshake messages significantly. 1529 QUIC requires that the packet containing a ClientHello be padded to a 1530 minimum size. A server is less likely to generate a packet 1531 reflection attack if the data it sends is a small multiple of this 1532 size. A server SHOULD use a HelloRetryRequest if the size of the 1533 handshake messages it sends is likely to significantly exceed the 1534 size of the packet containing the ClientHello. 1536 10.2. Peer Denial of Service 1538 QUIC, TLS and HTTP/2 all contain a messages that have legitimate uses 1539 in some contexts, but that can be abused to cause a peer to expend 1540 processing resources without having any observable impact on the 1541 state of the connection. If processing is disproportionately large 1542 in comparison to the observable effects on bandwidth or state, then 1543 this could allow a malicious peer to exhaust processing capacity 1544 without consequence. 1546 QUIC prohibits the sending of empty "STREAM" frames unless they are 1547 marked with the FIN bit. This prevents "STREAM" frames from being 1548 sent that only waste effort. 1550 TLS records SHOULD always contain at least one octet of a handshake 1551 messages or alert. Records containing only padding are permitted 1552 during the handshake, but an excessive number might be used to 1553 generate unnecessary work. Once the TLS handshake is complete, 1554 endpoints SHOULD NOT send TLS application data records unless it is 1555 to hide the length of QUIC records. QUIC packet protection does not 1556 include any allowance for padding; padded TLS application data 1557 records can be used to mask the length of QUIC frames. 1559 While there are legitimate uses for some redundant packets, 1560 implementations SHOULD track redundant packets and treat excessive 1561 volumes of any non-productive packets as indicative of an attack. 1563 11. Error Codes 1565 This section defines error codes from the error code space used in 1566 [QUIC-TRANSPORT]. 1568 The following error codes are defined when TLS is used for the crypto 1569 handshake: 1571 TLS_HANDSHAKE_FAILED (0x201): The TLS handshake failed. 1573 TLS_FATAL_ALERT_GENERATED (0x202): A TLS fatal alert was sent, 1574 causing the TLS connection to end prematurely. 1576 TLS_FATAL_ALERT_RECEIVED (0x203): A TLS fatal alert was received, 1577 causing the TLS connection to end prematurely. 1579 12. IANA Considerations 1581 This document does not create any new IANA registries, but it 1582 registers the values in the following registries: 1584 o QUIC Transport Error Codes Registry [QUIC-TRANSPORT] - IANA is to 1585 register the three error codes found in Section 11, these are 1586 summarized in Table 1. 1588 o TLS ExtensionsType Registry [TLS-REGISTRIES] - IANA is to register 1589 the quic_transport_parameters extension found in Section 9.2. 1590 Assigning 26 to the extension would be greatly appreciated. The 1591 Recommended column is to be marked Yes. 1593 o TLS Exporter Label Registry [TLS-REGISTRIES] - IANA is requested 1594 to register "EXPORTER-QUIC 0-RTT Secret" from Section 5.2.2; 1595 "EXPORTER-QUIC client 1-RTT Secret" and "EXPORTER-QUIC server 1596 1-RTT Secret" from Section 5.2.3; "EXPORTER-QUIC Packet Number 1597 Secret" Section 5.6. The DTLS column is to be marked No. The 1598 Recommended column is to be marked Yes. 1600 +-------+---------------------------+---------------+---------------+ 1601 | Value | Error | Description | Specification | 1602 +-------+---------------------------+---------------+---------------+ 1603 | 0x201 | TLS_HANDSHAKE_FAILED | TLS handshake | Section 11 | 1604 | | | failure | | 1605 | | | | | 1606 | 0x202 | TLS_FATAL_ALERT_GENERATED | Sent TLS | Section 11 | 1607 | | | alert | | 1608 | | | | | 1609 | 0x203 | TLS_FATAL_ALERT_RECEIVED | Receives TLS | Section 11 | 1610 | | | alert | | 1611 +-------+---------------------------+---------------+---------------+ 1613 Table 1: QUIC Transport Error Codes for TLS 1615 13. References 1616 13.1. Normative References 1618 [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated 1619 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1620 . 1622 [FIPS180] Department of Commerce, National., "NIST FIPS 180-4, 1623 Secure Hash Standard", March 2012, 1624 . 1627 [QUIC-TRANSPORT] 1628 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1629 Multiplexed and Secure Transport", draft-ietf-quic- 1630 transport-09 (work in progress), January 2018. 1632 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1633 Requirement Levels", BCP 14, RFC 2119, 1634 DOI 10.17487/RFC2119, March 1997, 1635 . 1637 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1638 Key Derivation Function (HKDF)", RFC 5869, 1639 DOI 10.17487/RFC5869, May 2010, 1640 . 1642 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1643 "Transport Layer Security (TLS) Application-Layer Protocol 1644 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1645 July 2014, . 1647 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1648 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1649 May 2017, . 1651 [TLS-REGISTRIES] 1652 Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1653 and DTLS", draft-ietf-tls-iana-registry-updates-03 (work 1654 in progress), January 2018. 1656 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1657 Version 1.3", draft-ietf-tls-tls13-23 (work in progress), 1658 January 2018. 1660 13.2. Informative References 1662 [AEBounds] 1663 Luykx, A. and K. Paterson, "Limits on Authenticated 1664 Encryption Use in TLS", March 2016, 1665 . 1667 [QUIC-HTTP] 1668 Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over 1669 QUIC", draft-ietf-quic-http-09 (work in progress), January 1670 2018. 1672 [QUIC-RECOVERY] 1673 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 1674 and Congestion Control", draft-ietf-quic-recovery-09 (work 1675 in progress), January 2018. 1677 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1678 DOI 10.17487/RFC2818, May 2000, 1679 . 1681 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1682 Housley, R., and W. Polk, "Internet X.509 Public Key 1683 Infrastructure Certificate and Certificate Revocation List 1684 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1685 . 1687 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 1688 (TLS) Cached Information Extension", RFC 7924, 1689 DOI 10.17487/RFC7924, July 2016, 1690 . 1692 13.3. URIs 1694 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 1696 [2] https://github.com/quicwg 1698 [3] https://github.com/quicwg/base-drafts/labels/-tls 1700 Appendix A. Contributors 1702 Ryan Hamilton was originally an author of this specification. 1704 Appendix B. Acknowledgments 1706 This document has benefited from input from Dragana Damjanovic, 1707 Christian Huitema, Jana Iyengar, Adam Langley, Roberto Peon, Eric 1708 Rescorla, Ian Swett, and many others. 1710 Appendix C. Change Log 1712 *RFC Editor's Note:* Please remove this section prior to 1713 publication of a final version of this document. 1715 Issue and pull request numbers are listed with a leading octothorp. 1717 C.1. Since draft-ietf-quic-tls-08 1719 o Specify value for max_early_data_size to enable 0-RTT (#942) 1721 o Update key derivation function (#1003, #1004) 1723 C.2. Since draft-ietf-quic-tls-07 1725 o Handshake errors can be reported with CONNECTION_CLOSE (#608, 1726 #891) 1728 C.3. Since draft-ietf-quic-tls-05 1730 No significant changes. 1732 C.4. Since draft-ietf-quic-tls-04 1734 o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) 1736 C.5. Since draft-ietf-quic-tls-03 1738 No significant changes. 1740 C.6. Since draft-ietf-quic-tls-02 1742 o Updates to match changes in transport draft 1744 C.7. Since draft-ietf-quic-tls-01 1746 o Use TLS alerts to signal TLS errors (#272, #374) 1748 o Require ClientHello to fit in a single packet (#338) 1750 o The second client handshake flight is now sent in the clear (#262, 1751 #337) 1753 o The QUIC header is included as AEAD Associated Data (#226, #243, 1754 #302) 1756 o Add interface necessary for client address validation (#275) 1758 o Define peer authentication (#140) 1760 o Require at least TLS 1.3 (#138) 1762 o Define transport parameters as a TLS extension (#122) 1764 o Define handling for protected packets before the handshake 1765 completes (#39) 1767 o Decouple QUIC version and ALPN (#12) 1769 C.8. Since draft-ietf-quic-tls-00 1771 o Changed bit used to signal key phase 1773 o Updated key phase markings during the handshake 1775 o Added TLS interface requirements section 1777 o Moved to use of TLS exporters for key derivation 1779 o Moved TLS error code definitions into this document 1781 C.9. Since draft-thomson-quic-tls-01 1783 o Adopted as base for draft-ietf-quic-tls 1785 o Updated authors/editors list 1787 o Added status note 1789 Authors' Addresses 1791 Martin Thomson (editor) 1792 Mozilla 1794 Email: martin.thomson@gmail.com 1796 Sean Turner (editor) 1797 sn3rd 1799 Email: sean@sn3rd.com