idnits 2.17.1 draft-schinazi-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [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 (November 04, 2019) is 1627 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 357 -- Looks like a reference, but probably isn't: '2' on line 359 -- Looks like a reference, but probably isn't: '3' on line 361 -- Looks like a reference, but probably isn't: '4' on line 363 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-23 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). 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: May 7, 2020 Mozilla 6 November 04, 2019 8 Compatible Version Negotiation for QUIC 9 draft-schinazi-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 [1] or on the GitHub repository which 23 contains the draft: http://github.com/ekr/draft-schinazi-quic- 24 version-negotiation [2]. 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 May 7, 2020. 43 Copyright Notice 45 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 62 3. Version Negotiation Mechanism . . . . . . . . . . . . . . . . 3 63 4. Version Negotiation Transport Parameter . . . . . . . . . . . 4 64 5. Version Downgrade Prevention . . . . . . . . . . . . . . . . 6 65 6. Supported Versions . . . . . . . . . . . . . . . . . . . . . 7 66 7. Compatible Versions . . . . . . . . . . . . . . . . . . . . . 7 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 10.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 QUIC [QUIC] does not provide a complete version negotiation (VN) 77 mechanism; the VN packet only allows the server to indicate that the 78 version the client offered is unacceptable, but doesn't allow the 79 client to safely make use of that information to create a new 80 connection with a mutually supported version. With proper safety 81 mechanisms in place, the VN packet can be part of a mechanism to 82 allow two QUIC implementations to negotiate between two totally 83 disjoint versions of QUIC, at the cost of an extra round trip. 84 However, it is beneficial to avoid that cost whenever possible, 85 especially given that most incremental versions are broadly similar 86 to the the previous version. 88 This specification describes a simple version negotiation mechanism 89 which optionally leverages similarities between versions and can 90 negotiate between the set of "compatible" versions in a single round 91 trip. 93 Discussion of this work is encouraged to happen on the QUIC IETF 94 mailing list quic@ietf.org [3] or on the GitHub repository which 95 contains the draft: http://github.com/ekr/draft-schinazi-quic- 96 version-negotiation [4]. 98 2. Conventions and Definitions 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 3. Version Negotiation Mechanism 108 The mechanism defined in this document is straightforward: the client 109 maintains a list of QUIC versions it supports, ordered by preference. 110 Its Initial packet is sent using the version that the server is most 111 likely to support (in the absence of other information, this will 112 often be the oldest version the client supports); that Initial packet 113 then lists all compatible versions (Section 7) that the client 114 supports in the Compatible Version fields of its transport parameters 115 (Figure 1). Note that the client's compatible version list always 116 contains its currently attempted version. 118 o If the server supports one of the client's compatible versions, it 119 selects a version it supports from the client's compatible version 120 list. It then responds with that version in all of its future 121 packets (except for Retry, as below). 123 o If the server does not support any of the client's compatible 124 versions, it sends a Version Negotiation packet listing all the 125 versions it supports. 127 If the server leverages compatible versions and responds with a 128 different version from the client's currently attempted version, it 129 MUST NOT select a version not offered by the client. The client MUST 130 validate that the version in the server's packets is one of the 131 compatible versions that it offered and that it matches the 132 negotiated version in the server's transport parameters. 134 If the server sends a Retry, it MUST use the same version that the 135 client provided in its Initial. Version negotiation takes place 136 after the retry cycle is over. 138 In order for negotiation to complete successfully, the client's 139 Initial packet (and initial CRYPTO frames) MUST be interpretable by 140 the server. This implies that servers must retain the ability to 141 process the Initial packet from older versions as long as they are 142 reasonably popular. This is not generally an issue in practice as 143 long as the the overall structure of the protocol remains similar. 145 4. Version Negotiation Transport Parameter 147 This document registers a new transport parameter, 148 "version_negotiation". The contents of this transport parameter 149 depend on whether the client or server is sending it, and are shown 150 below: 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Currently Attempted Version (32) | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Previously Attempted Version (32) | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Received Negotiation Version Count (i) ... 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | [Received Negotiation Version 1 (32)] | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | [Received Negotiation Version 2 (32)] | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 ... 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | [Received Negotiation Version N (32)] | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Compatible Version Count (i) ... 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Compatible Version 1 (32) | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | [Compatible Version 2 (32)] | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 ... 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | [Compatible Version N (32)] | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Figure 1: Client Transport Parameter Format 182 The content of each field is described below: 184 Currently Attempted Version: The version that the client is using in 185 this Initial. This field MUST be equal to the value of the 186 Version field in the long header that carries this transport 187 parameter. 189 Previously Attempted Version: If the client is sending this Initial 190 in response to a Version Negotiation packet, this field contains 191 the version that the client used in the previous Initial packet 192 that triggered the version negotiation packet. If the client did 193 not receive a Version Negotiation packet, this field SHALL be all- 194 zeroes. 196 Received Negotiation Version Count: A variable-length integer 197 specifying the number of Received Negotiation Version fields 198 following it. If the client is sending this Initial in response 199 to a Version Negotiation packet, the subsequent versions SHALL 200 include all the versions from that Version Negotiation packet in 201 order, even if they are not supported by the client (even if the 202 versions are reserved). If the client has not received a Version 203 Negotiation packet on this connection, this field SHALL be 0. 205 Compatible Version Count: A variable-length integer specifying the 206 number of Compatible Version fields following it. The client 207 lists all versions compatible with Currently Attempted Version in 208 the subsequent Compatible Version fields, ordered by descending 209 preference. Note that the version in the Currently Attempted 210 Version field MUST be included in the Compatible Version list to 211 allow the client to communicate the currently attempted version's 212 preference. 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Negotiated Version (32) | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Supported Version Count (i) ... 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Supported Version 1 (32) | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | [Supported Version 2 (32)] | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 ... 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | [Supported Version N (32)] | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 2: Server Transport Parameter Format 232 The content of each field is described below: 234 Negotiated Version: The version that the server chose to use for the 235 connection. This field SHALL be equal to the value of the Version 236 field in the long header that carries this transport parameter. 238 Supported Version Count: A variable-length integer specifying the 239 number of Supported Version fields following it. The server 240 encodes all versions it supports in the subsequent list, ordered 241 by descending preference. Note that the version in the Negotiated 242 Version field MUST be included in the Supported Version list. 244 Clients MAY include versions following the pattern "0x?a?a?a?a" in 245 their Compatible Version list, and the server in their Supported 246 Version list. Those versions are reserved to exercise version 247 negotiation (see the Versions section of [QUIC]), and MUST be ignored 248 when parsing these fields. On the other hand, the Received 249 Negotiation Version list MUST be identical to the received Version 250 Negotiation packet, so clients MUST NOT add or remove reserved 251 version from that list. 253 5. Version Downgrade Prevention 255 Clients MUST ignore any received Version Negotiation packets that 256 contain the version that they initially attempted. 258 Servers MUST validate that the client's "Currently Attempted Version" 259 matches the version in the long header that carried the transport 260 parameter. Similarly, clients MUST validate that the server's 261 "Negotiated Version" matches the long header version. If an 262 endpoint's validation fails, it MUST close the connection with an 263 error of type VERSION_NEGOTIATION_ERROR. 265 When a server parses the client's "version_negotiation" transport 266 parameter, if the "Received Negotiation Version Count" is not zero, 267 the server MUST validate that it could have sent the Version 268 Negotation packet described by the client in response to an Initial 269 of version "Previously Attempted Version". In particular, the server 270 MUST ensure that there are no versions that it supports that are 271 absent from the Received Negotiation Versions, and that the ordering 272 matches the server's preference. If this validation fails, the 273 server MUST close the connection with an error of type 274 VERSION_NEGOTIATION_ERROR. This mitigates an attacker's ability to 275 forge Version Negotiation packets to force a version downgrade. 277 If a server operator is progressively deploying a new QUIC version 278 throughout its fleet, it MAY perform a two-step process where it 279 first progressively adds support for the new version, but without 280 enforcing its presence in Received Negotiation Versions. Once all 281 servers have been upgraded, the second step is to start enforcing 282 that the new version is present in Received Negotiation Versions. 283 This opens connections to version downgrades during the upgrade 284 window, since those could be due to clients communicating with both 285 upgraded and non-upgraded servers. 287 6. Supported Versions 289 The server's Supported Version list allows it to communicate the full 290 list of versions it supports to the client. In the case where 291 clients initially attempt connections with the oldest version they 292 support, this allows them to be notified of more recent versions the 293 server supports. If the client notices that the server supports a 294 version that is more preferable that the one initially attempted by 295 default, the client SHOULD cache that information and attempt the 296 preferred version in subsequent connections. 298 7. Compatible Versions 300 Two versions of QUIC A and B are said to be "compatible" if a version 301 A Initial can be used to negotiate version B and vice versa. The 302 most common scenario is a sequence of versions 1, 2, 3, etc. in which 303 all the Initial packets have the same basic structure but might 304 include specific extensions (especially inside the crypto handshake) 305 that are only meaningful in some subset of versions and are ignored 306 in others. Note that it is not possible to add new frame types in 307 Initial packets because QUIC frames do not use a self-describing 308 encoding, so unrecognized frame types cannot be parsed or ignored 309 (see the Extension Frames section of [QUIC]). 311 When a new version of QUIC is defined, it is assumed to not be 312 compatible with any other version unless otherwise specified. 313 Implementations MUST NOT assume compatibility between version unless 314 explicitly specified. 316 8. Security Considerations 318 The crypto handshake is already required to guarantee agreement on 319 the supported parameters, so negotiation between compatible versions 320 will have the security of the weakest common version. 322 The requirement that versions not be assumed compatible mitigates the 323 possibility of cross-protocol attacks, but more analysis is still 324 needed here. 326 The presence of the Attempted Version and Negotiated Version fields 327 mitigates an attacker's ability to forge packets by altering the 328 version. 330 9. IANA Considerations 332 If this document is approved, IANA shall assign the identifier 0x73DB 333 for the "version_negotiation" transport parameter from the QUIC 334 Transport Parameter Registry and the identifier 0x53F8 for 335 "VERSION_NEGOTIATION_ERROR" from the QUIC Transport Error Codes 336 registry. 338 10. References 340 10.1. Normative References 342 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 343 and Secure Transport", draft-ietf-quic-transport-23 (work 344 in progress), September 2019. 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, 348 DOI 10.17487/RFC2119, March 1997, 349 . 351 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 352 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 353 May 2017, . 355 10.2. URIs 357 [1] mailto:quic@ietf.org 359 [2] http://github.com/ekr/draft-schinazi-quic-version-negotiation 361 [3] mailto:quic@ietf.org 363 [4] http://github.com/ekr/draft-schinazi-quic-version-negotiation 365 Authors' Addresses 367 David Schinazi 368 Google LLC 369 1600 Amphitheatre Parkway 370 Mountain View, California 94043 371 United States of America 373 Email: dschinazi.ietf@gmail.com 375 Eric Rescorla 376 Mozilla 378 Email: ekr@rtfm.com