idnits 2.17.1 draft-ietf-quic-version-negotiation-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 November 2020) is 1268 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-32 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC Working Group D. Schinazi 3 Internet-Draft Google LLC 4 Intended status: Informational E. Rescorla 5 Expires: 6 May 2021 Mozilla 6 2 November 2020 8 Compatible Version Negotiation for QUIC 9 draft-ietf-quic-version-negotiation-02 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 offered is unacceptable. This document describes 16 a version negotiation mechanism that allows a client and server to 17 select a mutually supported version. Optionally, if the original and 18 negotiated version share a compatible Initial format, the negotiation 19 can take place without incurring an extra round trip. 21 Discussion of this work is encouraged to happen on the QUIC IETF 22 mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub 23 repository which contains the draft: https://github.com/quicwg/ 24 version-negotiation/ (https://github.com/quicwg/version- 25 negotiation/). 27 Discussion Venues 29 This note is to be removed before publishing as an RFC. 31 Source for this draft and an issue tracker can be found at 32 https://github.com/quicwg/version-negotiation. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 6 May 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 68 3. Version Negotiation Mechanism . . . . . . . . . . . . . . . . 3 69 4. Version Negotiation Transport Parameter . . . . . . . . . . . 4 70 5. Version Downgrade Prevention . . . . . . . . . . . . . . . . 6 71 6. Supported Versions . . . . . . . . . . . . . . . . . . . . . 7 72 7. Compatible Versions . . . . . . . . . . . . . . . . . . . . . 7 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 10. Normative References . . . . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 QUIC [QUIC] does not provide a complete version negotiation (VN) 81 mechanism; the VN packet only allows the server to indicate that the 82 version the client offered is unacceptable, but doesn't allow the 83 client to safely make use of that information to create a new 84 connection with a mutually supported version. With proper safety 85 mechanisms in place, the VN packet can be part of a mechanism to 86 allow two QUIC implementations to negotiate between two totally 87 disjoint versions of QUIC, at the cost of an extra round trip. 88 However, it is beneficial to avoid that cost whenever possible, 89 especially given that most incremental versions are broadly similar 90 to the the previous version. 92 This specification describes a simple version negotiation mechanism 93 which optionally leverages similarities between versions and can 94 negotiate between the set of "compatible" versions in a single round 95 trip. 97 Discussion of this work is encouraged to happen on the QUIC IETF 98 mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub 99 repository which contains the draft: https://github.com/quicwg/ 100 version-negotiation/ (https://github.com/quicwg/version- 101 negotiation/). 103 2. Conventions and Definitions 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in BCP 108 14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 3. Version Negotiation Mechanism 113 The mechanism defined in this document is straightforward: the client 114 maintains a list of QUIC versions it supports, ordered by preference. 115 Its Initial packet is sent using the version that the server is most 116 likely to support (in the absence of other information, this will 117 often be the oldest version the client supports); that Initial packet 118 then lists all compatible versions (Section 7) that the client 119 supports in the Compatible Version fields of its transport parameters 120 (Figure 1). Note that the client's compatible version list always 121 contains its currently attempted version. 123 * If the server supports one of the client's compatible versions, it 124 selects a version it supports from the client's compatible version 125 list. It then responds with that version in all of its future 126 packets (except for Retry, as below). 128 * If the server does not support any of the client's compatible 129 versions, it sends a Version Negotiation packet listing all the 130 versions it supports. 132 If the server leverages compatible versions and responds with a 133 different version from the client's currently attempted version, it 134 MUST NOT select a version not offered by the client. The client MUST 135 validate that the version in the server's packets is one of the 136 compatible versions that it offered and that it matches the 137 negotiated version in the server's transport parameters. 139 If the server sends a Retry, it MUST use the same version that the 140 client provided in its Initial. Version negotiation takes place 141 after the retry cycle is over. 143 In order for negotiation to complete successfully, the client's 144 Initial packet (and initial CRYPTO frames) MUST be interpretable by 145 the server. This implies that servers must retain the ability to 146 process the Initial packet from older versions as long as they are 147 reasonably popular. This is not generally an issue in practice as 148 long as the overall structure of the protocol remains similar. 150 4. Version Negotiation Transport Parameter 152 This document registers a new transport parameter, 153 "version_negotiation". The contents of this transport parameter 154 depend on whether the client or server is sending it, and are shown 155 below: 157 0 1 2 3 158 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Currently Attempted Version (32) | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Previously Attempted Version (32) | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Received Negotiation Version Count (i) ... 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | [Received Negotiation Version 1 (32)] | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | [Received Negotiation Version 2 (32)] | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 ... 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | [Received Negotiation Version N (32)] | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Compatible Version Count (i) ... 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Compatible Version 1 (32) | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | [Compatible Version 2 (32)] | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 ... 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | [Compatible Version N (32)] | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Figure 1: Client Transport Parameter Format 187 The content of each field is described below: 189 Currently Attempted Version: The version that the client is using in 190 this Initial. This field MUST be equal to the value of the 191 Version field in the long header that carries this transport 192 parameter. 194 Previously Attempted Version: If the client is sending this Initial 195 in response to a Version Negotiation packet, this field contains 196 the version that the client used in the previous Initial packet 197 that triggered the version negotiation packet. If the client did 198 not receive a Version Negotiation packet, this field SHALL be all- 199 zeroes. 201 Received Negotiation Version Count: A variable-length integer 202 specifying the number of Received Negotiation Version fields 203 following it. If the client is sending this Initial in response 204 to a Version Negotiation packet, the subsequent versions SHALL 205 include all the versions from that Version Negotiation packet in 206 order, even if they are not supported by the client (even if the 207 versions are reserved). If the client has not received a Version 208 Negotiation packet on this connection, this field SHALL be 0. 210 Compatible Version Count: A variable-length integer specifying the 211 number of Compatible Version fields following it. The client 212 lists all versions compatible with Currently Attempted Version in 213 the subsequent Compatible Version fields, ordered by descending 214 preference. Note that the version in the Currently Attempted 215 Version field MUST be included in the Compatible Version list to 216 allow the client to communicate the currently attempted version's 217 preference. 219 0 1 2 3 220 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Negotiated Version (32) | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Supported Version Count (i) ... 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Supported Version 1 (32) | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | [Supported Version 2 (32)] | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 ... 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | [Supported Version N (32)] | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 2: Server Transport Parameter Format 237 The content of each field is described below: 239 Negotiated Version: The version that the server chose to use for the 240 connection. This field SHALL be equal to the value of the Version 241 field in the long header that carries this transport parameter. 243 Supported Version Count: A variable-length integer specifying the 244 number of Supported Version fields following it. The server 245 encodes all versions it supports in the subsequent list, ordered 246 by descending preference. Note that the version in the Negotiated 247 Version field MUST be included in the Supported Version list. 249 Clients MAY include versions following the pattern "0x?a?a?a?a" in 250 their Compatible Version list, and the server in their Supported 251 Version list. Those versions are reserved to exercise version 252 negotiation (see the Versions section of [QUIC]), and MUST be ignored 253 when parsing these fields. On the other hand, the Received 254 Negotiation Version list MUST be identical to the received Version 255 Negotiation packet, so clients MUST NOT add or remove reserved 256 version from that list. 258 5. Version Downgrade Prevention 260 Clients MUST ignore any received Version Negotiation packets that 261 contain the version that they initially attempted. Once a client has 262 reacted to a Version Negotiation packet, it MUST drop all subsequent 263 Version Negotiation packets. 265 Servers MUST validate that the client's "Currently Attempted Version" 266 matches the version in the long header that carried the transport 267 parameter. Similarly, clients MUST validate that the server's 268 "Negotiated Version" matches the long header version. If an 269 endpoint's validation fails, it MUST close the connection with an 270 error of type VERSION_NEGOTIATION_ERROR. 272 When a server parses the client's "version_negotiation" transport 273 parameter, if the "Received Negotiation Version Count" is not zero, 274 the server MUST validate that it could have sent the Version 275 Negotation packet described by the client in response to an Initial 276 of version "Previously Attempted Version". In particular, the server 277 MUST ensure that there are no versions that it supports that are 278 absent from the Received Negotiation Versions, and that the ordering 279 matches the server's preference. If this validation fails, the 280 server MUST close the connection with an error of type 281 VERSION_NEGOTIATION_ERROR. This mitigates an attacker's ability to 282 forge Version Negotiation packets to force a version downgrade. 284 If a server operator is progressively deploying a new QUIC version 285 throughout its fleet, it MAY perform a two-step process where it 286 first progressively adds support for the new version, but without 287 enforcing its presence in Received Negotiation Versions. Once all 288 servers have been upgraded, the second step is to start enforcing 289 that the new version is present in Received Negotiation Versions. 290 This opens connections to version downgrades during the upgrade 291 window, since those could be due to clients communicating with both 292 upgraded and non-upgraded servers. 294 6. Supported Versions 296 The server's Supported Version list allows it to communicate the full 297 list of versions it supports to the client. In the case where 298 clients initially attempt connections with the oldest version they 299 support, this allows them to be notified of more recent versions the 300 server supports. If the client notices that the server supports a 301 version that is more preferable that the one initially attempted by 302 default, the client SHOULD cache that information and attempt the 303 preferred version in subsequent connections. 305 7. Compatible Versions 307 Two versions of QUIC A and B are said to be "compatible" if a version 308 A Initial can be used to negotiate version B and vice versa. The 309 most common scenario is a sequence of versions 1, 2, 3, etc. in which 310 all the Initial packets have the same basic structure but might 311 include specific extensions (especially inside the crypto handshake) 312 that are only meaningful in some subset of versions and are ignored 313 in others. Note that it is not possible to add new frame types in 314 Initial packets because QUIC frames do not use a self-describing 315 encoding, so unrecognized frame types cannot be parsed or ignored 316 (see the Extension Frames section of [QUIC]). 318 When a new version of QUIC is defined, it is assumed to not be 319 compatible with any other version unless otherwise specified. 320 Implementations MUST NOT assume compatibility between version unless 321 explicitly specified. 323 8. Security Considerations 325 The crypto handshake is already required to guarantee agreement on 326 the supported parameters, so negotiation between compatible versions 327 will have the security of the weakest common version. 329 The requirement that versions not be assumed compatible mitigates the 330 possibility of cross-protocol attacks, but more analysis is still 331 needed here. 333 The presence of the Attempted Version and Negotiated Version fields 334 mitigates an attacker's ability to forge packets by altering the 335 version. 337 9. IANA Considerations 339 If this document is approved, IANA shall assign the identifier 0x73DB 340 for the "version_negotiation" transport parameter from the QUIC 341 Transport Parameter Registry and the identifier 0x53F8 for 342 "VERSION_NEGOTIATION_ERROR" from the QUIC Transport Error Codes 343 registry. 345 10. Normative References 347 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 348 and Secure Transport", Work in Progress, Internet-Draft, 349 draft-ietf-quic-transport-32, 20 October 2020, 350 . 353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 354 Requirement Levels", BCP 14, RFC 2119, 355 DOI 10.17487/RFC2119, March 1997, 356 . 358 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 359 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 360 May 2017, . 362 Authors' Addresses 364 David Schinazi 365 Google LLC 366 1600 Amphitheatre Parkway 367 Mountain View, California 94043, 368 United States of America 370 Email: dschinazi.ietf@gmail.com 372 Eric Rescorla 373 Mozilla 375 Email: ekr@rtfm.com