idnits 2.17.1 draft-duke-quic-version-aliasing-04.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 document seems to lack a Security Considerations section. ** The abstract seems to contain references ([QUIC-TRANSPORT]), 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 (30 October 2020) is 1272 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- No information found for draft-ietf-quic-tls-latest - is the name correct? -- No information found for draft-ietf-quic-version-negotiation-latest - is the name correct? -- No information found for draft-ietf-tls-esni-latest - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC M. Duke 3 Internet-Draft F5 Networks, Inc. 4 Intended status: Experimental 30 October 2020 5 Expires: 3 May 2021 7 QUIC Version Aliasing 8 draft-duke-quic-version-aliasing-04 10 Abstract 12 The QUIC transport protocol [QUIC-TRANSPORT] preserves its future 13 extensibility partly by specifying its version number. There will be 14 a relatively small number of published version numbers for the 15 foreseeable future. This document provides a method for clients and 16 servers to negotiate the use of other version numbers in subsequent 17 connections and encrypts Initial Packets using secret keys instead of 18 standard ones. If a sizeable subset of QUIC connections use this 19 mechanism, this should prevent middlebox ossification around the 20 current set of published version numbers and the contents of QUIC 21 Initial packets, as well as improving the protocol's privacy 22 properties. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 3 May 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 60 3. The Version Alias Transport Parameter . . . . . . . . . . . . 4 61 3.1. Version Number Generation . . . . . . . . . . . . . . . . 5 62 3.2. Initial Token Extension (ITE) Generation . . . . . . . . 5 63 3.3. Salt and Packet Length Offset Generation . . . . . . . . 6 64 3.4. Expiration Time . . . . . . . . . . . . . . . . . . . . . 6 65 3.5. Format . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.6. Multiple Servers for One Domain . . . . . . . . . . . . . 8 67 4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 68 5. Server Actions on Aliased Version Numbers . . . . . . . . . . 9 69 6. Considerations for Retry Packets . . . . . . . . . . . . . . 10 70 7. Security and Privacy Considerations . . . . . . . . . . . . . 10 71 7.1. Version Downgrade . . . . . . . . . . . . . . . . . . . . 11 72 7.2. Retry Injection . . . . . . . . . . . . . . . . . . . . . 11 73 7.3. Increased Linkability . . . . . . . . . . . . . . . . . . 12 74 7.4. Salt Polling Attack . . . . . . . . . . . . . . . . . . . 12 75 7.5. Increased Processing of Garbage UDP Packets . . . . . . . 13 76 7.6. Increased Retry Overhead . . . . . . . . . . . . . . . . 13 77 7.7. Request Forgery Attacks . . . . . . . . . . . . . . . . . 13 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 81 9.2. Informative References . . . . . . . . . . . . . . . . . 14 82 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 14 83 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 14 84 B.1. since draft-duke-quic-version-aliasing-03 . . . . . . . . 15 85 B.2. since draft-duke-quic-version-aliasing-02 . . . . . . . . 15 86 B.3. since draft-duke-quic-version-aliasing-01 . . . . . . . . 15 87 B.4. since draft-duke-quic-version-aliasing-00 . . . . . . . . 15 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction 92 The QUIC version number is critical to future extensibility of the 93 protocol. Past experience with other protocols, such as TLS1.3 94 [RFC8446], shows that middleboxes might attempt to enforce that QUIC 95 packets use versions known at the time the middlebox was implemented. 96 This has a chilling effect on deploying experimental and standard 97 versions on the internet. 99 Each version of QUIC has a "salt" [QUIC-TLS] that is used to derive 100 the keys used to encrypt Initial packets. As each salt is published 101 in a standards document, any observer can decrypt these packets and 102 inspect the contents, including a TLS Client Hello. A subsidiary 103 mechanism like Encrypted SNI [ENCRYPTED-SNI] might protect some of 104 the TLS fields inside a TLS Client Hello. 106 This document proposes "QUIC Version Aliasing," a standard way for 107 servers to advertise the availability of other versions inside the 108 cryptographic protection of a QUIC handshake. These versions are 109 syntactically identical to the QUIC version in which the 110 communication takes place, but use a different salt. In subsequent 111 communications, the client uses the new version number and encrypts 112 its Initial packets with a key derived from the provided salt. These 113 version numbers and salts are unique to the client. 115 If a large subset of QUIC traffic adopts his technique, middleboxes 116 will be unable to enforce particular version numbers or policy based 117 on Client Hello contents without incurring unacceptable penalties on 118 users. This would simultaneously protect the protocol against 119 ossification and improve its privacy properties. 121 1.1. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 In this document, these words will appear with that interpretation 128 only when in ALL CAPS. Lower case uses of these words are not to be 129 interpreted as carrying significance described in RFC 2119. 131 A "standard version" is a QUIC version that would be advertised in a 132 QUIC version negotiation and conforms to a specification. Any 133 aliased version corresponds to a standard version in all its formats 134 and behaviors, except for the version number field in long headers. 136 An "aliased version" is a version with a number generated in 137 accordance with this document. Except for the version field in long 138 headers, it conforms entirely to the specification of the standard 139 version. 141 2. Protocol Overview 143 When they instantiate a connection, servers select an alternate 144 32-bit version number, and optionally an initial token extension, for 145 the next connection at random and securely derive a salt and Packet 146 Length Offset from those values using a repeatable process. They 147 communicate this using a transport parameter extension including the 148 version, initial token extension, salt, Packet Length Offset, and an 149 expiration time for that value. 151 If a client next connects to that server within the indicated 152 expiration time, it MAY use the provided version number and encrypt 153 its Initial Packets using a key derived from the provided salt. It 154 adds the Packet Length Offset to the true packet length when encoding 155 it in the long header. If the server provided an Initial Token 156 Extension, the client puts it in the Initial Packet token field. If 157 there is another token the client wishes to include, it appends the 158 Initial Token Extension to that token. The server can reconstruct 159 the salt and Packet Length Offset from the requested version and 160 token, and proceed with the connection normally. 162 The Packet Length Offset is provides a low-cost way for the server to 163 verify it can derive a valid salt from the inputs without trial 164 decryption. This has important security implications, as described 165 in Section 7.2. 167 When generating a salt and Packet Length Offset, servers can choose 168 between doing so randomly and storing the mapping, or using a 169 cryptographic process to transform the aliased version number and 170 token extension into the salt. The two options provide a simple 171 tradeoff between computational complexity and storage requirements. 173 Note that clients and servers MUST implement 174 [QUIC-VERSION-NEGOTIATION] to use this specification. Therefore, 175 servers list supported versions in Version Negotiation Packets. Both 176 clients and servers list supported versions in Version Negotiation 177 Transport Parameters. 179 3. The Version Alias Transport Parameter 180 3.1. Version Number Generation 182 Servers MUST use a random process to generate version numbers. This 183 version number MUST NOT correspond to a QUIC version the server 184 advertises in QUIC Version Negotiation packets or transport 185 parameters. Servers SHOULD also exclude version numbers used in 186 known specifications or experiments to avoid confusion at clients, 187 whether or not they have plans to support those specifications. 189 Servers MUST NOT use client-controlled information (e.g. the client 190 IP address) in the random process, see Section 7.4. 192 Servers MUST NOT advertise these versions in QUIC Version Negotiation 193 packets. 195 3.2. Initial Token Extension (ITE) Generation 197 Servers SHOULD generate an Initial Token Extension (ITE) to provide 198 additional entropy in salt generation. Two clients that receive the 199 same version number but different extensions will not be able to 200 decode each other's Initial Packets. 202 Servers MAY choose any length that will allow client Initial Packets 203 to fit within the minimum QUIC packet size of 1200 octets. A four- 204 octet extension is RECOMMENDED. The ITE MUST appear to be random to 205 observers. 207 If a server supports multiple standard versions, it MUST either 208 encode the standard version of the current connection in the ITE or 209 store it in a lookup table. 211 If the server chooses to encode the standard version, it MUST be 212 cryptographically protected. 214 Encoded standard versions MUST be robust to false positives. That 215 is, if decoded with a new key, the version encoding must return as 216 invalid, rather than an incorrect value. 218 Alternatively, servers MAY store a mapping of unexpired aliased 219 versions and ITEs to standard versions. This mapping SHOULD NOT 220 create observable patterns, e.g. one plaintext bit indicates if the 221 standard version is 1 or 2. 223 The server MUST be able to distinguish ITEs from Resumption and Retry 224 tokens in incoming Initial Packets that contain an aliased version 225 number. As the server controls the lengths and encoding of each, 226 there are many ways to guarantee this. 228 3.3. Salt and Packet Length Offset Generation 230 The salt is an opaque 20-octet field. It is used to generate Initial 231 connection keys using the process described in [QUIC-TLS]. 233 The Packet Length Offset is a 64-bit unsigned integer with a maximum 234 value of 2^62 - 1. Clients MUST ignore a transport parameter with a 235 value that exceeds this limit. 237 To reduce header overhead, servers MAY consistently use a Packet 238 Length Offset of zero if and only if it either (1) never sends Retry 239 packets, or (2) can guarantee, through the use of persistent storage 240 or other means, that it will never lose the cryptographic state 241 required to generate the salt before the promised expiration time. 242 Section 7.2 describes the implications if it uses zero without 243 meeting these conditions. 245 Servers MUST either generate a random salt and Packet Length Offset 246 and store a mapping of aliased version and ITE to salt and offset, or 247 generate the salt and offset using a cryptographic method that uses 248 the version number, ITE, and only server state that is persistent 249 across connections. 251 If the latter, servers MUST implement a method that it can repeat 252 deterministically at a later time to derive the salt and offset from 253 the incoming version number and ITE. It MUST NOT use client 254 controlled information other than the version number and ITE; for 255 example, the client's IP address and port. 257 3.4. Expiration Time 259 Servers should select an expiration time in seconds, measured from 260 the instant the transport parameter is first sent. This time SHOULD 261 be less than the time until the server expects to support new QUIC 262 versions, rotate the keys used to encode information in the version 263 number, or rotate the keys used in salt generation. 265 Furthermore, the expiration time SHOULD be short enough to frustrate 266 a salt polling attack ({salt-polling}}) 268 Conversely, an extremely short expiration time will often force the 269 client to use standard QUIC version numbers and salts. 271 3.5. Format 273 This document defines a new transport parameter extension for QUIC 274 with identifier 0x5641. The contents of the value field are 275 indicated below. 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Version (32) | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | | 283 + + 284 | | 285 + + 286 | Salt (160) | 287 + + 288 | | 289 + + 290 | | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Packet Length Offset (i) | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Expiration (i) | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Initial Token Extension (variable) | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Figure 1: Version Alias Transport Parameter value 301 The definition of the fields is described above. Note that the 302 "Expiration" field is in seconds, and its length is encoded using the 303 Variable Length Integer encoding from Section 16 of [QUIC-TRANSPORT]. 305 The Packet Length Offset is also encoded as a Variable Length 306 Integer. 308 Clients can determine the length of the Initial Token Extension by 309 subtracting known and encoded field lengths from the overall 310 transport parameter length. 312 Note that servers that support version aliasing need not send the 313 transport parameter on every connection. Therefore, a client MAY 314 attempt to connect with an unexpired aliased version even if in its 315 most recent connection it did not receive the transport parameter. 317 Clients MAY remember the value in this transport parameter for future 318 connections. Servers MUST either store the contents of the transport 319 parameter, or preserve the state to compute the full contents based 320 on what the client provides. 322 3.6. Multiple Servers for One Domain 324 If multiple servers serve the same entity behind a load balancer, all 325 such servers SHOULD either have a common configuration for encoding 326 standard versions and computing salts, or share a common database of 327 mappings. They MUST NOT generate version numbers that any of them 328 would advertise in a Version Negotiation Packet or Transport 329 Parameter. 331 4. Client Behavior 333 When a client receives the Version Alias Transport Parameter, it MAY 334 cache the version number, ITE, salt, Packet Length Offset, and the 335 expiration of these values. It MAY use the version number and ITE in 336 a subsequent connection and compute the initial keys using the 337 provided salt. 339 Clients MUST NOT advertise aliased versions in the Version 340 Negotiation Transport Parameter unless they support a standard 341 version with the same number. Including that number signals support 342 for the standard version, not the aliased version. 344 Clients SHOULD NOT attempt to use the provided version number and 345 salt after the provided Expiration time has elapsed. 347 Clients MAY decline to use the provided version number or salt in 348 more than one connection. It SHOULD do so if its IP address has 349 changed between two connection attempts. Using a consistent version 350 number can link the client across connection attempts. 352 Clients MUST use the same standard version to format the Initial 353 Packet as the standard version used in the connection that provided 354 the aliased version. 356 If the server provided an ITE, the client MUST append it to any 357 Initial Packet token it is including from a Retry packet or NEW_TOKEN 358 frame, if it is using the associated aliased version. If there is no 359 such token, it simply includes the ITE as the entire token. 361 The QUIC Token Length field MUST include the length of both any Retry 362 or NEW_TOKEN token and the ITE. 364 The Length fields of all Initial, Handshake, and 0-RTT packets in the 365 connection are set to the value described in [QUIC-TRANSPORT] plus 366 the provided Packet Length Offset, modulo 2^62. 368 If the response to an Initial packet using the provided version is a 369 Version Negotiation Packet, the client SHOULD cease attempting to use 370 that version and salt to the server unless it later determines that 371 the packet was the result of a version downgrade, see Section 7.1. 373 If a client receives an aliased version number that matches a 374 standard version that the client supports, it SHOULD assume the 375 server does not support the standard version and MUST use aliased 376 version behaviors in any connection with the server using that 377 version number. 379 If a client receives a Version Negotiation packet or Version 380 Negotiation transport parameter advertising a version number the 381 server previously sent as an aliased version, and the client verifies 382 any Version Negotiation Packet is not a Version Downgrade attack 383 (Section 7.1), it MUST discard the aliased version number, ITE, 384 packet length offset, and salt and not use it in future connections. 386 5. Server Actions on Aliased Version Numbers 388 When a server receives an Initial Packet with an unsupported version 389 number, it SHOULD send a Version Negotiation Packet if it is 390 specifically configured not to generate that version number at 391 random. 393 Otherwise, it extracts the ITE, if any, and either looks up the 394 corresponding salt in its database or computes it using the technique 395 originally used to derive the salt from the version number and ITE. 397 The server similarly obtains the Packet Length Offset and subtracts 398 it from the provided Length field, modulo 2^62. If the resulting 399 value is larger than the entire UDP datagram, the server discards the 400 packet and SHOULD send a Version Negotiation Packet. 402 If the server supports multiple standard versions, it uses the 403 standard version extracted by the ITE or stored in the mapping to 404 parse the decrypted packet. 406 In all packets with long headers, the server uses the aliased version 407 number and adds the Packet Length Offset to the length field. 409 In the extremely unlikely event that the Packet Length Offset 410 resulted in a legal value but the salt is incorrect, the packet may 411 fail authentication. If so, or the encoded standard version is not 412 supported at the server, the server SHOULD send a Version Negotiation 413 Packet. 415 To reduce linkability for the client, servers SHOULD provide a new 416 Version Alias transport parameter, with a new version number, ITE, 417 salt, and Packet Length Offset, each time a client connects. 418 However, issuing version numbers to a client SHOULD be rate-limited 419 to mitigate the salt polling attack Section 7.4. 421 6. Considerations for Retry Packets 423 QUIC Retry packets reduce the load on servers during periods of 424 stress by forcing the client to prove it possesses the IP address 425 before the server decrypts any Initial Packets or establishes any 426 connection state. Version aliasing substantially complicates the 427 process. 429 If a server has to send a Retry packet, the required format is 430 ambiguous without understanding which standard version to use. If 431 all supported standard versions use the same Retry format, it simply 432 uses that format with the client-provided version number. 434 If the supported standard versions use different Retry formats, the 435 server obtains the standard version via lookup or decoding and 436 formats a Retry containing the aliased version number accordingly. 438 Servers generate the Retry Integrity Tag of a Retry Packet using the 439 procedure in Section 5.8 of [QUIC-TLS]. However, for aliased 440 versions, the secret key K uses the first 16 octets of the aliased 441 salt instead of the key provided in the specification. 443 Clients MUST ignore Retry packets that contain a QUIC version other 444 than the version it used in its Initial Packet. 446 Servers MUST NOT reply to a packet with an incorrect Length field in 447 its long header with a Retry packet; it SHOULD reply with Version 448 Negotiation as described above. 450 7. Security and Privacy Considerations 452 This document intends to improve the existing security and privacy 453 properties of QUIC by dramatically improving the secrecy of QUIC 454 Initial Packets. However, there are new attacks against this 455 mechanism. 457 7.1. Version Downgrade 459 A countermeasure against version aliasing is the downgrade attack. 460 Middleboxes may drop a packet containing a random version and imitate 461 the server's failure to correctly process it. Clients and servers 462 are required to implement [QUIC-VERSION-NEGOTIATION] to detect 463 downgrades. 465 Note that downgrade detection only works after receiving a response 466 from the server. If a client immediately responds to a Version 467 Negotiation Packet with an Initial Packet with a standard version 468 number, it will have exposed its request in a format readable to 469 observers before it discovers if the Version Negotiation Packet is 470 authentic. A client SHOULD wait for an interval to see if a valid 471 response comes from the server before assuming the version 472 negotiation is valid. The client MAY also alter its Initial Packet 473 (e.g., its ALPN field) to sanitize sensitive information and obtain 474 another aliased version before proceeding with its true request. 476 Servers that support version aliasing SHOULD be liberal about the 477 Initial Packet content they receive, keeping the connection open long 478 enough to deliver their transport parameters, to support this 479 mechanism. 481 7.2. Retry Injection 483 QUIC Version 1 Retry packets are spoofable, as they follow a fixed 484 format, are sent in plaintext, and the integrity protection uses a 485 widely known key. As a result, QUIC Version 1 has verification 486 mechanisms in subsequent packets of the connection to validate the 487 origin of the Retry. 489 Version aliasing largely frustrates this attack. As the integrity 490 check key is derived from the secret salt, packets from attackers 491 will fail their integrity check and the client will ignore them. 493 The Packet Length Offset is important in this framework. Without 494 this mechanism, servers would have to perform trial decryption to 495 verify the client was using the correct salt. As this does not occur 496 before sending Retry Packets, servers would not detect disagreement 497 on the salt beforehand and would send a Retry packet signed with a 498 different salt than the client expects. Therefore, a client that 499 received a Retry packet with an invalid integrity check would not be 500 able to distinguish between the following possibilities: 502 * a Retry packet corrupted in the network, which should be ignored; 503 * a Retry packet generated by an attacker, which should be ignored; 504 or 506 * a Retry packet from a server that lost its cryptographic state, 507 meaning that further communication with aliased versions is 508 impossible and the client should revert to using a standard 509 version. 511 The Packet Length Offset introduces sufficient entropy to make the 512 third possibility exceedingly unlikely. 514 7.3. Increased Linkability 516 As each version number and ITE is unique to each client, if a client 517 uses one twice, those two connections are extremely likely to be from 518 the same host. If the client has changed IP address, this is a 519 significant increase in linkability relative to QUIC with a standard 520 version numbers. 522 7.4. Salt Polling Attack 524 Observers that wish to decode Initial Packets might open a large 525 number of connections to the server in an effort to obtain part of 526 the mapping of version numbers and ITEs to salts for a server. While 527 storage-intensive, this attack could increase the probability that at 528 least some version-aliased connections are observable. There are 529 three mitigations servers can execute against this attack: 531 * use a longer ITE to increase the entropy of the salt, 533 * rate-limit transport parameters sent to a particular client, and/ 534 or 536 * set a low expiration time to reduce the lifetime of the attacker's 537 database. 539 Segmenting the version number space based on client information, i.e. 540 using only a subset of version numbers for a certain IP address 541 range, would significantly amplify an attack. Observers will 542 generally be on the path to the client and be able to mimic having an 543 identical IP address. Segmentation in this way would dramatically 544 reduce the search space for attackers. Thus, servers are prohibited 545 from using this mechanism. 547 7.5. Increased Processing of Garbage UDP Packets 549 As QUIC shares the UDP protocol number with other UDP applications, 550 in some deployments it may be possible for traffic intended for other 551 UDP applications to arrive at a QUIC server endpoint. When servers 552 support a finite set of version numbers, a valid version number field 553 is a strong indicator the packet is, in fact, QUIC. If the version 554 number is invalid, a QUIC Version Negotiation is a low-cost response 555 that triggers very early in packet processing. 557 However, a server that provides version aliasing is prepared to 558 accept almost any version number. As a result, many more 559 sufficiently sized UDP payloads with the first bit set to '1' are 560 potential QUIC Initial Packets that require generation of a salt and 561 Packet Length Offset. 563 Note that a nonzero Packet Length Offset will allow the server to 564 drop all but approximately 1 in every 2^49 packets, so trial 565 decryption is unnecessary. 567 While not a more potent attack then simply sending valid Initial 568 Packets, servers may have to provision additional resources to 569 address this possibility. 571 7.6. Increased Retry Overhead 573 This document requires two small cryptographic operations to build a 574 Retry packet instead of one, placing more load on servers when 575 already under load. 577 7.7. Request Forgery Attacks 579 Section 21.4 of [QUIC-TRANSPORT] describes the request forgery 580 attack, where a QUIC endpoint can cause its peer to deliver packets 581 to a victim with specific content. 583 Version aliasing allows the server to specify the contents of the 584 version field and part of the token field in Initial packets sent by 585 the client, potentially increasing the potency of this attack. 587 8. IANA Considerations 589 This draft chooses a transport parameter (0x5641) to minimize the 590 risk of collision. IANA should assign a permanent value from the 591 QUIC Transport Parameter Registry. 593 9. References 594 9.1. Normative References 596 [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using Transport 597 Layer Security (TLS) to Secure QUIC", Work in Progress, 598 Internet-Draft, draft-ietf-quic-tls-latest, 599 . 601 [QUIC-TRANSPORT] 602 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 603 Multiplexed and Secure Transport", Work in Progress, 604 Internet-Draft, draft-ietf-quic-transport, 605 . 607 [QUIC-VERSION-NEGOTIATION] 608 Schinazi, D., Ed. and E. Rescorla, Ed., "Compatible 609 Version Negotiation for QUIC", Work in Progress, Internet- 610 Draft, draft-ietf-quic-version-negotiation-latest, 611 . 614 9.2. Informative References 616 [ENCRYPTED-SNI] 617 Rescorla, E., Ed., Oku, K., Ed., Sullivan, N., Ed., and 618 C.A. Wood, Ed., "Encrypted Server Name Indication for TLS 619 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 620 esni-latest, 621 . 623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 624 Requirement Levels", BCP 14, RFC 2119, 625 DOI 10.17487/RFC2119, March 1997, 626 . 628 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 629 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 630 . 632 Appendix A. Acknowledgments 634 Marten Seemann was the original creator of the version aliasing 635 approach. 637 Appendix B. Change Log 639 *RFC Editor's Note:* Please remove this section prior to 640 publication of a final version of this document. 642 B.1. since draft-duke-quic-version-aliasing-03 644 * Discussed request forgery attacks 646 B.2. since draft-duke-quic-version-aliasing-02 648 * Specified 0RTT status of the transport parameter 650 B.3. since draft-duke-quic-version-aliasing-01 652 * Fixed all references to "seed" where I meant "salt." 654 * Added the Packet Length Offset, which eliminates Retry Injection 655 Attacks 657 B.4. since draft-duke-quic-version-aliasing-00 659 * Added "Initial Token Extensions" to increase salt entropy and make 660 salt polling attacks impractical. 662 * Allowed servers to store a mapping of version number and ITE to 663 salt instead. 665 * Made standard version encoding mandatory. This dramatically 666 simplifies the new Retry logic and changes the security model. 668 * Added references to Version Negotiation Transport Parameters. 670 * Extensive readability edit. 672 Author's Address 674 Martin Duke 675 F5 Networks, Inc. 677 Email: martin.h.duke@gmail.com