idnits 2.17.1 draft-ietf-quic-version-negotiation-07.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 date (6 April 2022) is 751 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC D. Schinazi 3 Internet-Draft Google LLC 4 Intended status: Standards Track E. Rescorla 5 Expires: 8 October 2022 Mozilla 6 6 April 2022 8 Compatible Version Negotiation for QUIC 9 draft-ietf-quic-version-negotiation-07 11 Abstract 13 QUIC does not provide a complete version negotiation mechanism but 14 instead only provides a way for the server to indicate that the 15 version the client chose is unacceptable. This document describes a 16 version negotiation mechanism that allows a client and server to 17 select a mutually supported version. Optionally, if the client's 18 chosen version and the negotiated version share a compatible first 19 flight format, the negotiation can take place without incurring an 20 extra round trip. 22 About This Document 24 This note is to be removed before publishing as an RFC. 26 The latest revision of this draft can be found at 27 https://quicwg.github.io/version-negotiation/draft-ietf-quic-version- 28 negotiation.html. Status information for this document may be found 29 at https://datatracker.ietf.org/doc/draft-ietf-quic-version- 30 negotiation/. 32 Discussion of this document takes place on the QUIC Working Group 33 mailing list (mailto:quic@ietf.org), which is archived at 34 https://mailarchive.ietf.org/arch/browse/quic/. 36 Source for this draft and an issue tracker can be found at 37 https://github.com/quicwg/version-negotiation. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on 8 October 2022. 56 Copyright Notice 58 Copyright (c) 2022 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. Code Components 66 extracted from this document must include Revised BSD License text as 67 described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Revised BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 74 2. Version Negotiation Mechanism . . . . . . . . . . . . . . . . 3 75 2.1. Incompatible Version Negotiation . . . . . . . . . . . . 4 76 2.2. Compatible Versions . . . . . . . . . . . . . . . . . . . 5 77 2.3. Compatible Version Negotiation . . . . . . . . . . . . . 6 78 2.4. Connections and Version Negotiation . . . . . . . . . . . 7 79 2.5. Client Choice of Original Version . . . . . . . . . . . . 8 80 3. Version Information . . . . . . . . . . . . . . . . . . . . . 8 81 4. Version Downgrade Prevention . . . . . . . . . . . . . . . . 9 82 5. Server Deployments of QUIC . . . . . . . . . . . . . . . . . 10 83 6. Application Layer Protocol Considerations . . . . . . . . . . 12 84 7. Considerations for Future Versions . . . . . . . . . . . . . 12 85 7.1. Interaction with Retry . . . . . . . . . . . . . . . . . 13 86 7.2. Interaction with TLS resumption . . . . . . . . . . . . . 13 87 7.3. Interaction with 0-RTT . . . . . . . . . . . . . . . . . 13 88 8. Special Handling for QUIC Version 1 . . . . . . . . . . . . . 14 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 91 10.1. QUIC Transport Parameter . . . . . . . . . . . . . . . . 14 92 10.2. QUIC Transport Error Code . . . . . . . . . . . . . . . 15 93 11. Normative References . . . . . . . . . . . . . . . . . . . . 15 94 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 97 1. Introduction 99 The version-invariant properties of QUIC [INV] define a Version 100 Negotiation packet but do not specify how an endpoint reacts when it 101 receives one. QUIC version 1 [QUIC] allows the server to use a 102 Version Negotiation packet to indicate that the version the client 103 chose is unacceptable, but doesn't allow the client to safely make 104 use of that information to create a new connection with a mutually 105 supported version. 107 With proper safety mechanisms in place, the Version Negotiation 108 packet can be part of a mechanism to allow two QUIC implementations 109 to negotiate between two totally disjoint versions of QUIC. This 110 document specifies version negotiation using Version Negotiation 111 packets, which adds an extra round trip to connection establishment 112 if needed. 114 It is beneficial to avoid additional round trips whenever possible, 115 especially given that most incremental versions are broadly similar 116 to the the previous version. This specification also defines a 117 simple version negotiation mechanism which leverages similarities 118 between versions and can negotiate between the set of "compatible" 119 versions without additional round trips. 121 1.1. Conventions and Definitions 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 In this document, the Maximum Segment Lifetime (MSL) represents the 130 time a QUIC packet can exist in the network. Implementations can 131 make this configurable, and a RECOMMENDED value is one minute. 133 2. Version Negotiation Mechanism 135 This document specifies two means of performing version negotiation: 136 one "incompatible" which requires a round trip and is applicable to 137 all versions, and one "compatible" that allows saving the round trip 138 but only applies when the versions are compatible. 140 The client initiates a QUIC connection by choosing an initial version 141 and sending a first flight of QUIC packets with a long header to the 142 server [INV]. The client's first flight includes Version Information 143 (see Section 3) which will be used to optionally enable compatible 144 version negotation (see Section 2.3), and to prevent version 145 downgrade attacks (see Section 4). We'll refer to the version of the 146 very first packets the client sends as the "original version" and the 147 version of the first packets the client sends in a given QUIC 148 connection as the "client's chosen version". 150 Upon receiving this first flight, the server verifies whether it 151 knows how to parse first flights from the original version. If it 152 does not, then it starts incompatible version negotiation, see 153 Section 2.1, which causes the client to initiate a new connection 154 with a different version. For instance, if the client initiates a 155 connection with version A and the server starts incompatible version 156 negotiation and the client then initiates a new connection with 157 version B, we say that the first connection's client chosen version 158 is A, the second connection's client chosen version is B, and the 159 original version for the entire sequence is A. 161 If the server can parse the first flight, it can either establish the 162 connection using the client's chosen version, or it MAY select any 163 other compatible version, as described in Section 2.3. 165 Note that it is possible for a server to have the ability to parse 166 the first flight of a given version without fully supporting it, in 167 the sense that it implements enough of the version's specification to 168 parse first flight packets but not enough to fully establish a 169 connection using that version. 171 2.1. Incompatible Version Negotiation 173 The server starts incompatible version negotiation by sending a 174 Version Negotiation packet. This packet SHALL include each entry 175 from the server's set of Offered Versions (see Section 5) in a 176 Supported Version field. The server MAY add reserved versions (as 177 defined in Section 6.3 of [QUIC]) in Supported Version fields. 179 Clients will ignore a Version Negotiation packet if it contains the 180 original version attempted by the client. The client also ignores a 181 Version Negotiation packet that contains incorrect connection ID 182 fields; see Section 6 of [INV]. 184 Upon receiving the Version Negotiation packet, the client will search 185 for a version it supports in the list provided by the server. If it 186 doesn't find one, it aborts the connection attempt. Otherwise, it 187 selects a mutually supported version and sends a new first flight 188 with that version - we refer to this version as the "negotiated 189 version". 191 The new first flight will allow the endpoints to establish a 192 connection using the negotiated version. The handshake of the 193 negotiated version will exchange version information (see Section 3) 194 required to ensure that version negotiation was genuine, i.e. that no 195 attacker injected packets in order to influence the version 196 negotiation process, see Section 4. 198 2.2. Compatible Versions 200 If A and B are two distinct versions of QUIC, A is said to be 201 "compatible" with B if it is possible to take a first flight of 202 packets from version A and convert it into a first flight of packets 203 from version B. As an example, if versions A and B are absolutely 204 equal in their wire image and behavior during the handshake but 205 differ after the handshake, then A is compatible with B and B is 206 compatible with A. Note that the conversion of the first flight can 207 be lossy: some data such as QUIC version 1 0-RTT packets could be 208 ignored during conversion and retransmitted later. 210 Version compatibility is not symmetric: it is possible for version A 211 to be compatible with version B and for B not to be compatible with 212 A. This could happen for example if version B is a strict superset 213 of version A: if version A includes the concept of streams and STREAM 214 frames, and version B includes the concepts of streams and tubes 215 along with STREAM and TUBE frames, then A would be compatible with B 216 but B would not be compatible with A. 218 Note that version compatibility does not mean that every single 219 possible instance of a first flight will succeed in conversion to the 220 other version. A first flight using version A is said to be 221 "compatible" with version B if two conditions are met: first that 222 version A is compatible with version B, and second that the 223 conversion of this first flight to version B is well-defined. For 224 example, if version B is equal to A in all aspects except it 225 introduced a new frame in its first flight that version A cannot 226 parse or even ignore, then B could still be compatible with A as 227 conversions would succeed for connections where that frame is not 228 used. In this example, first flights using version B that carry this 229 new frame would not be compatible with version A. 231 When a new version of QUIC is defined, it is assumed to not be 232 compatible with any other version unless otherwise specified. 233 Similarly, no other version is compatible with the new version unless 234 otherwise specified. Implementations MUST NOT assume compatibility 235 between versions unless explicitly specified. 237 Note that both endpoints might disagree on whether two versions are 238 compatible or not. For example, two versions could have been defined 239 concurrently and then specified as compatible in a third document 240 much later - in that scenario one endpoint might be aware of the 241 compatibility document while the other may not. 243 2.3. Compatible Version Negotiation 245 When the server can parse the client's first flight using the 246 client's chosen version, it can extract the client's Version 247 Information structure (see Section 3). This contains the list of 248 versions that the client knows its first flight is compatible with. 250 In order to perform compatible version negotiation, the server MUST 251 select one of these versions that (1) it supports and (2) it knows 252 the client's chosen version to be compatible with. Once the server 253 has selected a version, termed the "negotiated version", it then 254 attempts to convert the client's first flight into that version, and 255 replies to the client as if it had received the converted first 256 flight. 258 If those formats are identical, as in cases where the negotiated 259 version is the same as the client's chosen version, then this will be 260 the identity transform. If the first flight is correctly formatted, 261 then this conversion process cannot fail by definition of the first 262 flight being compatible; if the server is unable to convert the first 263 flight, it MUST abort the handshake. 265 Clients can determine the server's negotiated version by examining 266 the QUIC long header Version field. It is possible for the server to 267 initially send packets with the client's chosen version before 268 switching to the negotiated version (for example, this can happen 269 when the client's Version Information structure spans multiple 270 packets; in that case the server might acknowledge the first packet 271 in the client's chosen version and later switch to a different 272 negotiated version). 274 Note that, after the first flight is converted to the negotiated 275 version, the handshake completes in the negotiated version. The 276 entire handshake (including the converted first flight) needs to 277 conform to the rules of the negotiated version. For instance, if the 278 negotiated version requires that the 5-tuple remain stable for the 279 entire handshake (as QUIC version 1 does), then this applies to the 280 entire handshake, including the first flight. 282 Note also that the client can disable compatible version negotiation 283 by only including the Chosen Version in the Other Versions field of 284 the Version Information transport parameter. 286 If the server does not find a compatible version (including the 287 client's chosen version), it will perform incompatible version 288 negotiation instead, see Section 2.1. 290 Note that it is possible to have incompatible version negotation 291 followed by compatible version negotiation. For instance, if version 292 A is compatible with B and C is compatible with D, the following 293 scenario could occur: 295 Client Server 297 Chosen = A, Other Versions = (A, B) -----------------> 298 <------------------------ Version Negotiation = (D, C) 300 Chosen = C, Other Versions = (C, D) -----------------> 301 <-------------------------------------- Negotiated = D 303 Figure 1: Combined Negotiation Example 305 In this example, the client selected C from the server's Version 306 Negotiation packet, but the server preferred D and then selected it 307 from the client's offer. 309 2.4. Connections and Version Negotiation 311 QUIC connections are shared state between a client and a server 312 [INV]. The compatible version negotiation mechanism defined in this 313 document (see Section 2.3) is performed as part of a single QUIC 314 connection; that is, the packets with the client's chosen version are 315 part of the same connection as the packets with the negotiated 316 version. 318 In comparison, the incompatible version negotiation mechanism, which 319 leverages QUIC Version Negotiation packets (see Section 2.1) 320 conceptually operates across two QUIC connections: the connection 321 attempt prior to receiving the Version Negotiation packet is distinct 322 from the connection with the incompatible version that follows. 324 Note that this separation across two connections is conceptual: it 325 applies to normative requirements on QUIC connections, but does not 326 require implementations to internally use two distinct connection 327 objects. 329 2.5. Client Choice of Original Version 331 When the client picks its original version, it will try to avoid 332 incompatible version negotiation to save a round trip. Therefore, 333 the client SHOULD pick an original version to maximize the combined 334 probability that both: 336 * The server knows how to parse first flights from the original 337 version. 339 * The original version is compatible with the client's preferred 340 version. 342 Without additional information, this could mean selecting the oldest 343 version that the client supports. 345 3. Version Information 347 During the handshake, endpoints will exchange Version Information, 348 which consists of a chosen version and a list of other versions. Any 349 version of QUIC that supports this mechanism MUST provide a mechanism 350 to exchange Version Information in both directions during the 351 handshake, such that this data is authenticated. 353 In QUIC version 1, the Version Information is transmitted using a new 354 transport parameter, version_information. The contents of Version 355 Information are shown below (using the notation from the "Notational 356 Conventions" section of [QUIC]): 358 Version Information { 359 Chosen Version (32), 360 Other Versions (32) ..., 361 } 363 Figure 2: Version Information Format 365 The content of each field is described below: 367 Chosen Version: The version that the sender has chosen to use for 368 this connection. In most cases, this field will be equal to the 369 value of the Version field in the long header that carries this 370 data. 372 The contents of the Other Versions field depends on whether it is 373 sent by the client or by the server. 375 Client-Sent Other Versions: When sent by a client, the Other 376 Versions field lists all the versions that this first flight is 377 compatible with, ordered by descending preference. Note that the 378 version in the Chosen Version field MUST be included in this list 379 to allow the client to communicate the chosen version's 380 preference. Note that this preference is only advisory, servers 381 MAY choose to use their own preference instead. 382 Server-Sent Other Versions: When sent by a server, the Other 383 Versions field lists all the Fully-Deployed Versions of this 384 server deployment, see Section 5. Note that the version in the 385 Chosen Version field is not necessarily included in this list, 386 because the server operator could be in the process of removing 387 support for this version. For the same reason, the Other Versions 388 field MAY be empty. 390 Clients and servers MAY both include versions following the pattern 391 0x?a?a?a?a in their Other Versions list. Those versions are reserved 392 to exercise version negotiation (see the Versions section of [QUIC]), 393 and will never be selected when choosing a version to use. 395 4. Version Downgrade Prevention 397 Clients MUST ignore any received Version Negotiation packets that 398 contain the version that they initially attempted. A client that 399 makes a connection attempt based on information received from a 400 Version Negotiation packet MUST ignore any Version Negotiation 401 packets it receives in response to that connection attempt. 403 Both endpoints MUST parse their peer's Version Information during the 404 handshake. If parsing the Version Information failed (for example, 405 if it is too short or if its length is not divisible by four), then 406 the endpoint MUST close the connection; if the connection was using 407 QUIC version 1, that connection closure MUST use a transport error of 408 type TRANSPORT_PARAMETER_ERROR. If an endpoint receives a Chosen 409 Version equal to zero, or any Other Version equal to zero, it MUST 410 treat it as a parsing failure. 412 Every QUIC version that supports version negotiation MUST define a 413 method for closing the connection with a version negotiation error. 414 For QUIC version 1, version negotiation errors are signaled using a 415 transport error of type VERSION_NEGOTIATION_ERROR; see Section 10.2. 417 If the Version Information was missing, the endpoints MAY complete 418 the handshake. However, if a client has reacted to a Version 419 Negotiation packet and the Version Information was missing, the 420 client MUST close the connection with a version negotiation error. 422 If the client received and acted on a Version Negotiation packet, the 423 client MUST validate the server's Other Versions field. The Other 424 Versions field is validated by confirming that the client would have 425 attempted the same version with knowledge of the versions the server 426 supports. That is, the client would have selected the same version 427 if it received a Version Negotiation packet that listed the versions 428 in the server's Other Versions field, plus the negotiated version. 429 If the client would have selected a different version, the client 430 MUST close the connection with a version negotiation error. In 431 particular, if the client reacted to a Version Negotiation packet and 432 the server's Other Versions field is empty, the client MUST close the 433 connection with a version negotiation error. These connection 434 closures prevent an attacker from being able to use forged Version 435 Negotiation packets to force a version downgrade. 437 This validation of Other Versions is not sufficient to prevent 438 downgrade. Downgrade prevention also depends on the client ignoring 439 Version Negotiation packets that contain the original version; see 440 Section 2.1. 442 After the process of version negotiation in this document completes, 443 the version in use for the connection is the version that the server 444 sent in the Chosen Version field of its Version Information. That 445 remains true even if other versions were used in the Version field of 446 long headers at any point in the lifetime of the connection. In 447 particular, since during compatible version negotiation the client is 448 made aware of the negotiated version by the QUIC long header version 449 (see Section 2.3), clients MUST validate that the server's Chosen 450 Version is equal to the negotiated version; if they do not match, the 451 client MUST close the connection with a version negotiation error. 452 This prevents an attacker's ability to influence version negotiation 453 by forging the Version long header field. 455 5. Server Deployments of QUIC 457 While this document mainly discusses a single QUIC server, it is 458 common for deployments of QUIC servers to include a fleet of multiple 459 server instances. We therefore define the following terms: 461 Acceptable Versions: This is the set of versions supported by a 462 given server instance. More specifically, these are the versions 463 that a given server instance will use if a client sends a first 464 flight using them. 465 Offered Versions: This is the set of versions that a given server 466 instance will send in a Version Negotiation packet if it receives 467 a first flight from an unknown version. This set will most often 468 be equal to the Acceptaple Versions set, except during short 469 transitions while versions are added or removed (see below). 471 Fully-Deployed Versions: This is the set of QUIC versions that is 472 supported and negotiated by every single QUIC server instance in 473 this deployment. If a deployment only contains a single server 474 instance, then this set is equal to the Offered Versions set, 475 except during short transitions while versions are added or 476 removed (see below). 478 If a deployment contains multiple server instances, software updates 479 may not happen at exactly the same time on all server instances. 480 Because of this, a client might receive a Version Negotiation packet 481 from a server instance that has already been updated and the client's 482 resulting connection attempt might reach a different server instance 483 which hasn't been updated yet. 485 However, even when there is only a single server instance, it is 486 still possible to receive a stale Version Negotiation packet if the 487 server performs its software update while the Version Negotiation 488 packet is in flight. 490 This could cause the version downgrade prevention mechanism described 491 in Section 4 to falsely detect a downgrade attack. To avoid that, 492 server operators SHOULD perform a three-step process when they wish 493 to add or remove support for a version: 495 When adding support for a new version: 497 * The first step is to progressively add support for the new version 498 to all server instances. This step updates the Acceptable 499 Versions but not the Offered Versions nor the Fully-Deployed 500 Versions. Once all server instances have been updated, operators 501 wait for at least one MSL to allow any in-flight Version 502 Negotiation packets to arrive. 504 * Then, the second step is to progressively add the new version to 505 Offered Versions on all server instances. Once complete, 506 operators wait for at least another MSL. 508 * Finally, the third step is to progressively add the new version to 509 Fully-Deployed Versions on all server instances. 511 When removing support for a version: 513 * The first step is to progressively remove the version from Fully- 514 Deployed Versions on all server instances. Once it has been 515 removed on all server instances, operators wait for at least one 516 MSL to allow any in-flight Version Negotiation packets to arrive. 518 * Then, the second step is to progressively remove the version from 519 Offered Versions on all server instances. Once complete, 520 operators wait for at least another MSL. 522 * Finally, the third step is to progressively remove support for the 523 version from all server instances. That step updates the 524 Acceptable Versions. 526 Note that this opens connections to version downgrades (but only for 527 partially-deployed versions) during the update window, since those 528 could be due to clients communicating with both updated and non- 529 updated server instances. 531 6. Application Layer Protocol Considerations 533 When a client creates a QUIC connection, its goal is to use an 534 application layer protocol. Therefore, when considering which 535 versions are compatible, clients will only consider versions that 536 support one of the intended application layer protocols. If the 537 client's first flight advertises multiple Application Layer Protocol 538 Negotiation (ALPN) [ALPN] tokens and multiple compatible versions, it 539 is possible for some application layer protocols to not be able to 540 run over some of the offered compatible versions. It is the server's 541 responsibility to only select an ALPN token that can run over the 542 compatible QUIC version that it selects. 544 A given ALPN token MUST NOT be used with a new QUIC version different 545 from the version for which the ALPN token was originally defined, 546 unless all the following requirements are met: 548 * The new QUIC version supports the transport features required by 549 the application protocol. 551 * The new QUIC version supports ALPN. 553 * The version of QUIC for which the ALPN token was originally 554 defined is compatible with the new QUIC version. 556 When incompatible version negotiation is in use, the second 557 connection which is created in response to the received version 558 negotiation packet MUST restart its application layer protocol 559 negotiation process without taking into account the original version. 561 7. Considerations for Future Versions 563 In order to facilitate the deployment of future versions of QUIC, 564 designers of future versions SHOULD attempt to design their new 565 version such that commonly deployed versions are compatible with it. 567 QUIC version 1 defines multiple features which are not documented in 568 the QUIC invariants. Since at the time of writing QUIC version 1 is 569 widely deployed, this section discusses considerations for future 570 versions to help with compatibility with QUIC version 1. 572 7.1. Interaction with Retry 574 QUIC version 1 features Retry packets, which the server can send to 575 validate the client's IP address before parsing the client's first 576 flight. A server that sends a Retry packet can do so before parsing 577 the client's first flight. A server that sends a Retry packet 578 therefore might not have processed the client's Version Information 579 before doing so. 581 If a future document wishes to define compatibility between two 582 versions that support retry, that document MUST specify how version 583 negotiation (both compatible and incompatible) interacts with retry 584 during a handshake that requires both. For example, that could be 585 accomplished by having the server send a Retry packet in the original 586 version first thereby validating the client's IP address before 587 attempting compatible version negotiation. If both versions support 588 authenticating Retry packets, the compatibility defition needs to 589 define how to authenticate the Retry in the negotiated version 590 handshake even though the Retry itself was sent using the client's 591 chosen version. 593 7.2. Interaction with TLS resumption 595 QUIC version 1 uses TLS 1.3, which supports session resumption by 596 sending session tickets in one connection that can be used in a later 597 connection; see Section 2.2 of [TLS]. New versions that also use TLS 598 1.3 SHOULD mandate that their session tickets are tightly scoped to 599 one version of QUIC; i.e., require that clients not use them across 600 multiple version and that servers validate this client requirement. 602 7.3. Interaction with 0-RTT 604 QUIC version 1 allows sending data from the client to the server 605 during the handshake, by using 0-RTT packets. If a future document 606 wishes to define compatibility between two versions that support 607 0-RTT, that document MUST address the scenario where there are 0-RTT 608 packets in the client's first flight. For example, this could be 609 accomplished by defining which transformations are applied to 0-RTT 610 packets. That document could specify that compatible version 611 negotiation causes 0-RTT data to be rejected by the server. 613 8. Special Handling for QUIC Version 1 615 Because QUIC version 1 was the only IETF Standards Track version of 616 QUIC published before this document, it is handled specially as 617 follows: if a client is starting a QUIC version 1 connection in 618 response to a received Version Negotiation packet, and the 619 version_information transport parameter is missing from the server's 620 transport parameters, then the client SHALL proceed as if the 621 server's transport parameters contained a version_information 622 transport parameter with a Chosen Version set to 0x00000001 and an 623 Other Version list containing exactly one version set to 0x00000001. 624 This allows version negotiation to work with servers that only 625 support QUIC version 1. Note that implementations which wish to use 626 version negotiation to negotiate versions other than QUIC version 1 627 will need to implement the version negotiation mechanism defined in 628 this document. 630 9. Security Considerations 632 The security of this version negotiation mechanism relies on the 633 authenticity of the Version Information exchanged during the 634 handshake. In QUIC version 1, transport parameters are authenticated 635 ensuring the security of this mechanism. Negotiation between 636 compatible versions will have the security of the weakest common 637 version. 639 The requirement that versions not be assumed compatible mitigates the 640 possibility of cross-protocol attacks, but more analysis is still 641 needed here. 643 10. IANA Considerations 645 10.1. QUIC Transport Parameter 647 This document registers a new value in the "QUIC Transport 648 Parameters" registry maintained at . 651 Value: 0xFF73DB 652 Parameter Name: version_information 653 Status: provisional 654 Specification: This document 656 When this document is approved, it will request permanent allocation 657 of a codepoint in the 0-63 range to replace the provisional codepoint 658 described above. 660 10.2. QUIC Transport Error Code 662 This document registers a new value in the "QUIC Transport Error 663 Codes" registry maintained at . 666 Value: 0x53F8 667 Code: VERSION_NEGOTIATION_ERROR 668 Description: Error negotiating version 669 Status: provisional 670 Specification: This document 672 When this document is approved, it will request permanent allocation 673 of a codepoint in the 0-63 range to replace the provisional codepoint 674 described above. 676 11. Normative References 678 [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 679 "Transport Layer Security (TLS) Application-Layer Protocol 680 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 681 July 2014, . 683 [INV] Thomson, M., "Version-Independent Properties of QUIC", 684 RFC 8999, DOI 10.17487/RFC8999, May 2021, 685 . 687 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 688 Multiplexed and Secure Transport", RFC 9000, 689 DOI 10.17487/RFC9000, May 2021, 690 . 692 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 693 Requirement Levels", BCP 14, RFC 2119, 694 DOI 10.17487/RFC2119, March 1997, 695 . 697 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 698 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 699 May 2017, . 701 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 702 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 703 . 705 Acknowledgments 707 The authors would like to thank Nick Banks, Mike Bishop, Ryan 708 Hamilton, Roberto Peon, Anthony Rossi, and Martin Thomson for their 709 input and contributions. 711 Authors' Addresses 713 David Schinazi 714 Google LLC 715 1600 Amphitheatre Parkway 716 Mountain View, CA 94043 717 United States of America 718 Email: dschinazi.ietf@gmail.com 720 Eric Rescorla 721 Mozilla 722 Email: ekr@rtfm.com