idnits 2.17.1 draft-duke-quic-version-aliasing-01.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 (23 April 2020) is 1464 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 23 April 2020 5 Expires: 25 October 2020 7 QUIC Version Aliasing 8 draft-duke-quic-version-aliasing-01 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 25 October 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 60 3. The Version Alias Transport Parameter . . . . . . . . . . . . 4 61 3.1. Version Number Generation . . . . . . . . . . . . . . . . 4 62 3.2. Initial Token Extension (ITE) Generation . . . . . . . . 5 63 3.3. Salt Generation . . . . . . . . . . . . . . . . . . . . . 5 64 3.4. Expiration Time . . . . . . . . . . . . . . . . . . . . . 6 65 3.5. Format . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.6. Multiple Servers for One Domain . . . . . . . . . . . . . 7 67 4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 7 68 5. Server Actions on Aliased Version Numbers . . . . . . . . . . 8 69 6. Considerations for Retry Packets . . . . . . . . . . . . . . 9 70 7. Security and Privacy Considerations . . . . . . . . . . . . . 10 71 7.1. Version Downgrade . . . . . . . . . . . . . . . . . . . . 10 72 7.2. Retry Injection . . . . . . . . . . . . . . . . . . . . . 10 73 7.3. Increased Linkability . . . . . . . . . . . . . . . . . . 11 74 7.4. Seed Polling Attack . . . . . . . . . . . . . . . . . . . 11 75 7.5. Increased Processing of Garbage UDP Packets . . . . . . . 12 76 7.6. Increased Retry Overhead . . . . . . . . . . . . . . . . 12 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 80 9.2. Informative References . . . . . . . . . . . . . . . . . 13 81 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13 82 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 13 83 B.1. since draft-duke-quic-version-aliasing-00 . . . . . . . . 13 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Introduction 88 The QUIC version number is critical to future extensibility of the 89 protocol. Past experience with other protocols, such as TLS1.3 90 [RFC8446], shows that middleboxes might attempt to enforce that QUIC 91 packets use versions known at the time the middlebox was implemented. 92 This has a chilling effect on deploying experimental and standard 93 versions on the internet. 95 Each version of QUIC has a "salt" [QUIC-TLS] that is used to derive 96 the keys used to encrypt Initial packets. As each salt is published 97 in a standards document, any observer can decrypt these packets and 98 inspect the contents, including a TLS Client Hello. A subsidiary 99 mechanism like Encrypted SNI [ENCRYPTED-SNI] might protect some of 100 the TLS fields inside a TLS Client Hello. 102 This document proposes "QUIC Version Aliasing," a standard way for 103 servers to advertise the availability of other versions inside the 104 cryptographic protection of a QUIC handshake. These versions are 105 syntactically identical to the QUIC version in which the 106 communication takes place, but use a different salt. In subsequent 107 communications, the client uses the new version number and encrypts 108 its Initial packets with a key derived from the provided salt. These 109 version numbers and salts are unique to the client. 111 If a large subset of QUIC traffic adopts his technique, middleboxes 112 will be unable to enforce particular version numbers or policy based 113 on Client Hello contents without incurring unacceptable penalties on 114 users. This would simultaneously protect the protocol against 115 ossification and improve its privacy properties. 117 1.1. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 In this document, these words will appear with that interpretation 124 only when in ALL CAPS. Lower case uses of these words are not to be 125 interpreted as carrying significance described in RFC 2119. 127 A "standard version" is a QUIC version that would be advertised in a 128 QUIC version negotiation and conforms to a specification. Any 129 aliased version corresponds to a standard version in all its formats 130 and behaviors, except for the version number field in long headers. 132 An "aliased version" is a version with a number generated in 133 accordance with this document. Except for the version field in long 134 headers, it conforms entirely to the specification of the standard 135 version. 137 2. Protocol Overview 139 When they instantiate a connection, servers select an alternate 140 32-bit version number, and optionally an initial token extension, for 141 the next connection at random and securely derive a salt from those 142 values using a repeatable process. They communicate this using a 143 transport parameter extension including the version, initial token 144 extension, salt, and an expiration time for that value. 146 If a client next connects to that server within the indicated 147 expiration time, it MAY use the provided version number and encrypt 148 its Initial Packets using a key derived from the provided salt. If 149 the server provided an Initial Token Extension, the client puts it in 150 the Initial Packet token field. If there is another token the client 151 wishes to include, it appends the Initial Token Extension to that 152 token. The server can reconstruct the salt from the requested 153 version and token, and proceed with the connection normally. 155 When generating a salt, servers can choose between doing so randomly 156 and storing the mapping, or using a cryptographic process to 157 transform the aliased version number and token extension into the 158 salt. The two options provide a simple tradeoff between 159 computational complexity and storage requirements. 161 Note that clients and servers MUST implement 162 [QUIC-VERSION-NEGOTIATION] to use this specification. Therefore, 163 servers list supported versions in Version Negotiation Packets. Both 164 clients and servers list supported versions in Version Negotiation 165 Transport Parameters. 167 3. The Version Alias Transport Parameter 169 3.1. Version Number Generation 171 Servers MUST use a random process to generate version numbers. This 172 version number MUST NOT correspond to a QUIC version the server 173 advertises in QUIC Version Negotiation packet or transport parameter. 174 Servers SHOULD also exclude version numbers used in known 175 specifications or experiments to avoid confusion at clients, whether 176 or not they have plans to support those specifications. 178 Servers MUST NOT use client-controlled information (e.g. the client 179 IP address) in the random process, see Section 7.4. 181 Servers MUST NOT advertise these versions in QUIC Version Negotiation 182 packets. 184 3.2. Initial Token Extension (ITE) Generation 186 Servers SHOULD generate an Initial Token Extension (ITE) to provide 187 additional entropy in salt generation. Two clients that receive the 188 same version number but different extensions will not be able to 189 decode each other's Initial Packets. 191 Servers MAY choose any length that will allow client Initial Packets 192 to fit within the minimum QUIC packet size of 1200 octets. A four- 193 octet extension is RECOMMENDED. The ITE MUST appear to be random to 194 observers. 196 If a server supports multiple standard versions, it MUST either 197 encode the standard version of the current connection in the ITE or 198 store it in a lookup table. 200 If the server chooses to encode the standard version, it MUST be 201 cryptographically protected. 203 Encoded standard versions MUST be robust to false positives. That 204 is, if decoded with a new key, the version encoding must return as 205 invalid, rather than an incorrect value. 207 Alternatively, servers MAY store a mapping of unexpired aliased 208 versions and ITEs to standard versions. This mapping SHOULD NOT 209 create observable patterns, e.g. one plaintext bit indicates if the 210 standard version is 1 or 2. 212 The server MUST be able to distinguish ITEs from Resumption and Retry 213 tokens in incoming Initial Packets that contain an aliased version 214 number. As the server controls the lengths and encoding of each, 215 there are many ways to guarantee this. 217 3.3. Salt Generation 219 The salt is an opaque 20-octet field. It is used to generate Initial 220 connection keys using the process described in [QUIC-TLS]. 222 Servers MUST either generate a random salt and store a mapping of 223 aliased version and ITE to salt, or generate the salt using a 224 cryptographic method that uses the version number, ITE, and only 225 server state that is persistent across connections. 227 If the latter, servers MUST implement a method that it can repeat 228 deterministically at a later time to derive the salt from the 229 incoming version number and ITE. It MUST NOT use client controlled 230 information other than the version number and ITE; for example, the 231 client's IP address and port. 233 3.4. Expiration Time 235 Servers should select an expiration time in seconds, measured from 236 the instant the transport parameter is first sent. This time SHOULD 237 be less than the time until the server expects to support new QUIC 238 versions, rotate the keys used to encode information in the version 239 number, or rotate the keys used in salt generation. 241 Furthermore, the expiration time SHOULD be short enough to frustrate 242 a seed polling attack ({seed-polling}}) 244 Conversely, an extremely short expiration time will often force the 245 client to use standard QUIC version numbers and salts. 247 3.5. Format 249 This document defines a new transport parameter extension for QUIC 250 with identifier 0x5641. The contents of the value field are 251 indicated below. 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Version (32) | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | | 259 + + 260 | | 261 + + 262 | Salt (160) | 263 + + 264 | | 265 + + 266 | | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Expiration (i) | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Initial Token Extension (variable) | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Figure 1: Version Alias Transport Parameter value 275 The definition of the fields is described above. Note that the 276 "Expiration" field is in seconds, and its length is encoded using the 277 Variable Length Integer encoding from Section 16 of [QUIC-TRANSPORT]. 279 Clients can determine the length of the Initial Token Extension by 280 subtracting known and encoded field lengths from the overall 281 transport parameter length. 283 3.6. Multiple Servers for One Domain 285 If multiple servers serve the same entity behind a load balancer, all 286 such servers SHOULD either have a common configuration for encoding 287 standard versions and computing salts, or share a common database of 288 mappings. They MUST NOT generate version numbers that any of them 289 would advertise in a Version Negotiation Packet or Transport 290 Parameter. 292 4. Client Behavior 294 When a client receives the Version Alias Transport Parameter, it MAY 295 cache the version number, ITE, salt, and the expiration of this 296 value. It MAY use the version number and ITE in a subsequent 297 connection and compute the initial keys using the provided salt. 299 Clients MUST NOT advertise aliased versions in the Version 300 Negotiation Transport Parameter unless they support a standard 301 version with the same number. Including that number signals support 302 for the standard version, not the aliased version. 304 Clients SHOULD NOT attempt to use the provided version number and 305 salt after the provided Expiration time has elapsed. 307 Clients MAY decline to use the provided version number or salt in 308 more than one connection. It SHOULD do so if its IP address has 309 changed between two connection attempts. Using a consistent version 310 number can link the client across connection attempts. 312 Clients MUST use the same standard version to format the Initial 313 Packet as the standard version used in the connection that provided 314 the aliased version. 316 If the server provided an ITE, the client MUST append it to any 317 Initial Packet token it is including from a Retry packet or NEW_TOKEN 318 frame, if it is using the associated aliased version. If there is no 319 such token, it simply includes the ITE as the entire token. 321 The QUIC Token Length field MUST include the length of both any Retry 322 or NEW_TOKEN token and the ITE. 324 If the response to an Initial packet using the provided version is a 325 Version Negotiation Packet, the client SHOULD cease attempting to use 326 that version and salt to the server unless it later determines that 327 the packet was the result of a version downgrade, see Section 7.1. 329 If a client receives an aliased version number that matches a 330 standard version that the client supports, it SHOULD assume the 331 server does not support the standard version and MUST use aliased 332 version behaviors in any connection with the server using that 333 version number. 335 If a client receives a Version Negotiation packet or Version 336 Negotiation transport parameter advertising a version number the 337 server previously sent as an aliased version, and the client verifies 338 any Version Negotiation Packet is not a Version Downgrade attack 339 (Section 7.1), it MUST discard the aliased version number, ITE, and 340 salt and not use it in future connections. 342 5. Server Actions on Aliased Version Numbers 344 When a server receives an Initial Packet with an unsupported version 345 number, it SHOULD send a Version Negotiation Packet if it is 346 specifically configured not to generate that version number at 347 random. 349 Otherwise, it extracts the ITE, if any, and either looks up the 350 corresponding salt in its database or computes it using the technique 351 originally used to derive the salt from the version number and ITE. 353 If the server supports multiple standard versions, it uses the 354 standard version extracted by the ITE or stored in the mapping to 355 parse the decrypted packet. 357 If the computed seed results in a packet that fails authentication, 358 or the encoded standard version is not supported at the server, the 359 server SHOULD send a Version Negotiation Packet. 361 To reduce linkability for the client, servers SHOULD provide a new 362 Version Alias transport parameter, with a new version number, ITE, 363 and salt, each time a client connects. However, issuing version 364 numbers to a client SHOULD be rate- limited to mitigate the seed 365 polling attack Section 7.4. 367 6. Considerations for Retry Packets 369 QUIC Retry packets reduce the load on servers during periods of 370 stress by forcing the client to prove it possesses the IP address 371 before the server decrypts any Initial Packets or establishes any 372 connection state. Version aliasing substantially complicates the 373 process. 375 If a server has to send a Retry packet, the required format is 376 ambiguous without understanding which standard version to use. If 377 all supported standard versions use the same Retry format, it simply 378 uses that format with the client-provided version number. 380 If the supported standard versions use different Retry formats, the 381 server obtains the standard version via lookup or decoding and 382 formats a Retry containing the aliased version number accordingly. 384 Servers generate the Retry Integrity Tag of a Retry Packet using the 385 procedure in Section 5.8 of [QUIC-TLS]. However, for aliased 386 versions, the secret key K uses the first 16 octets of the aliased 387 salt instead of the key provided in the specification. 389 Clients MUST ignore Retry packets that contain a QUIC version other 390 than the version it used in its Initial Packet. 392 If the client receives a Retry with a valid Integrity Tag, it MUST 393 send another Initial Packet with the aliased version, and the ITE 394 appended to the Retry Token. Invalid Retry Integrity Tokens are, for 395 standard versions, usually the result of packet corruption in the 396 network. For an aliased version, it might also mean that the server 397 has lost its state to correctly compute the salt. As it therefore 398 has no valid aliased version, the client SHOULD attempt to connect 399 with an Initial packet that contains the same standard version and 400 the supplied Retry Token. 402 A Retry Injection attack (Section 7.2) can result in Retry packets 403 with invalid integrity tags. The client SHOULD NOT discard its 404 stored aliased versions until the subsequent connection to the server 405 verifies that the Retry came from the server. 407 As further protection against this attack, after starting a 408 connection with a valid Retry token, servers SHOULD issue tokens 409 using NEW_TOKEN frames and clients SHOULD keep connections using 410 standard versions open long enough to receive such tokens. 412 7. Security and Privacy Considerations 414 This document intends to improve the existing security and privacy 415 properties of QUIC by dramatically improving the secrecy of QUIC 416 Initial Packets. However, there are new attacks against this 417 mechanism. 419 7.1. Version Downgrade 421 A countermeasure against version aliasing is the downgrade attack. 422 Middleboxes may drop a packet containing a random version and imitate 423 the server's failure to correctly process it. Clients and servers 424 are required to implement [QUIC-VERSION-NEGOTIATION] to detect 425 downgrades. 427 Note that downgrade detection only works after receiving a response 428 from the server. If a client immediately responds to a Version 429 Negotiation Packet with an Initial Packet with a standard version 430 number, it will have exposed its request in a format readable to 431 observers before it discovers if the Version Negotiation Packet is 432 authentic. A client SHOULD wait for an interval to see if a valid 433 response comes from the server before assuming the version 434 negotiation is valid. The client MAY also alter its Initial Packet 435 (e.g., its ALPN field) to sanitize sensitive information and obtain 436 another aliased version before proceeding with its true request. 438 Servers that support version aliasing SHOULD be liberal about the 439 Initial Packet content they receive, keeping the connection open long 440 enough to deliver their transport parameters, to support this 441 mechanism. 443 7.2. Retry Injection 445 An attacker might try to force the client to a standard QUIC version 446 by injecting Retry packets. For example, a man-in-the-middle could 447 drop an Initial Packet and generate a Retry packet in response, 448 though the Integrity Tag would be invalid. 450 The client will then connect with the standard version, and thus be 451 decodable. However, the QUIC protocol detects this interference on 452 the next handshake, thanks to the contents of the Retry token. 453 Therefore, clients are discouraged from immediately assuming aliased 454 versions are invalid upon receipt of such a packet. 456 A more sophisticated attack instead changes some integrity bits in a 457 valid Retry packet. As the Retry token is valid, the next handshake 458 will not detect the intrusion and the client will believe the Retry 459 packet legitimately signaled that the standard version was invalid. 461 In general, the client will then receive a new aliased version. If 462 the client has no token from a NEW_TOKEN frame, a subsequent 463 connection attempt with an aliased version could also trigger a Retry 464 and allow the same attack. Providing a token in a NEW_TOKEN frame 465 bypasses the server Retry mechanism so that the attacker cannot 466 continuously have legitimate Retry packets to modify in this way. 468 7.3. Increased Linkability 470 As each version number and ITE is unique to each client, if a client 471 uses one twice, those two connections are extremely likely to be from 472 the same host. If the client has changed IP address, this is a 473 significant increase in linkability relative to QUIC with a standard 474 version numbers. 476 7.4. Seed Polling Attack 478 Observers that wish to decode Initial Packets might open a large 479 number of connections to the server in an effort to obtain part of 480 the mapping of version numbers and ITEs to salts for a server. While 481 storage-intensive, this attack could increase the probability that at 482 least some version-aliased connections are observable. There are 483 three mitigations servers can execute against this attack: 485 * use a longer ITE to increase the entropy of the salt, 487 * rate-limit transport parameters sent to a particular client, and/ 488 or 490 * set a low expiration time to reduce the lifetime of the attacker's 491 database. 493 Segmenting the version number space based on client information, i.e. 494 using only a subset of version numbers for a certain IP address 495 range, would significantly amplify an attack. Observers will 496 generally be on the path to the client and be able to mimic having an 497 identical IP address. Segmentation in this way would dramatically 498 reduce the search space for attackers. Thus, servers are prohibited 499 from using this mechanism. 501 7.5. Increased Processing of Garbage UDP Packets 503 As QUIC shares the UDP protocol number with other UDP applications, 504 in some deployments it may be possible for traffic intended for other 505 UDP applications to arrive at a QUIC server endpoint. When servers 506 support a finite set of version numbers, a valid version number field 507 is a strong indicator the packet is, in fact, QUIC. If the version 508 number is invalid, a QUIC Version Negotiation is a low-cost response 509 that triggers very early in packet processing. 511 However, a server that provides version aliasing is prepared to 512 accept almost any version number. As a result, many more 513 sufficiently sized UDP payloads with the first bit set to '1' are 514 potential QUIC Initial Packets that require generation of a salt, 515 some initial connection state, and a decryption operation. 517 While not a more potent attack then simply sending valid Initial 518 Packets, servers may have to provision additional resources to 519 address this possibility. 521 7.6. Increased Retry Overhead 523 This document requires two small cryptographic operations to build a 524 Retry packet instead of one, placing more load on servers when 525 already under load. 527 8. IANA Considerations 529 This draft chooses a transport parameter (0x5641) to minimize the 530 risk of collision. IANA should assign a permanent value from the 531 QUIC Transport Parameter Registry. 533 9. References 535 9.1. Normative References 537 [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using Transport 538 Layer Security (TLS) to Secure QUIC", Work in Progress, 539 Internet-Draft, draft-ietf-quic-tls-latest, 540 . 542 [QUIC-TRANSPORT] 543 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 544 Multiplexed and Secure Transport", Work in Progress, 545 Internet-Draft, draft-ietf-quic-transport, 546 . 548 [QUIC-VERSION-NEGOTIATION] 549 Schinazi, D., Ed. and E. Rescorla, Ed., "Compatible 550 Version Negotiation for QUIC", Work in Progress, Internet- 551 Draft, draft-ietf-quic-version-negotiation-latest, 552 . 555 9.2. Informative References 557 [ENCRYPTED-SNI] 558 Rescorla, E., Ed., Oku, K., Ed., Sullivan, N., Ed., and 559 C.A. Wood, Ed., "Encrypted Server Name Indication for TLS 560 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 561 esni-latest, 562 . 564 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 565 Requirement Levels", BCP 14, RFC 2119, 566 DOI 10.17487/RFC2119, March 1997, 567 . 569 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 570 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 571 . 573 Appendix A. Acknowledgments 575 Marten Seemann was the original progenitor of the version aliasing 576 approach. 578 Appendix B. Change Log 580 *RFC Editor's Note:* Please remove this section prior to 581 publication of a final version of this document. 583 B.1. since draft-duke-quic-version-aliasing-00 585 * Added "Initial Token Extensions" to increase seed entropy and make 586 seed polling attacks impractical. 588 * Allowed servers to store a mapping of version number and ITE to 589 seed instead. 591 * Made standard version encoding mandatory. This dramatically 592 simplifies the new Retry logic and changes the security model. 594 * Added references to Version Negotiation Transport Parameters. 596 * Extensive readability edit. 598 Author's Address 600 Martin Duke 601 F5 Networks, Inc. 603 Email: martin.h.duke@gmail.com