idnits 2.17.1 draft-duke-quic-version-aliasing-08.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (28 April 2022) is 729 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-quic-version-negotiation-07 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-14 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC M. Duke 3 Internet-Draft Google 4 Intended status: Experimental 28 April 2022 5 Expires: 30 October 2022 7 QUIC Version Aliasing 8 draft-duke-quic-version-aliasing-08 10 Abstract 12 The QUIC transport protocol preserves its future extensibility partly 13 by specifying its version number. There will be a relatively small 14 number of published version numbers for the foreseeable future. This 15 document provides a method for clients and servers to negotiate the 16 use of other version numbers in subsequent connections and encrypts 17 Initial Packets using secret keys instead of standard ones. If a 18 sizeable subset of QUIC connections use this mechanism, this should 19 prevent middlebox ossification around the current set of published 20 version numbers and the contents of QUIC Initial packets, as well as 21 improving the protocol's privacy properties. 23 Discussion Venues 25 This note is to be removed before publishing as an RFC. 27 Discussion of this document takes place on the mailing list 28 (quic@ietf.org), which is archived at 29 https://mailarchive.ietf.org/arch/browse/quic/. 31 Source for this draft and an issue tracker can be found at 32 https://github.com/martinduke/quic-version-aliasing. 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 30 October 2022. 50 Copyright Notice 52 Copyright (c) 2022 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 Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 69 2.1. Relationship to ECH and QUIC Protected Initials . . . . . 6 70 3. The Version Alias Transport Parameter . . . . . . . . . . . . 7 71 3.1. Aliased Version Number Generation . . . . . . . . . . . . 7 72 3.2. Initial Token Extension (ITE) Generation . . . . . . . . 7 73 3.3. Salt and Packet Length Offset Generation . . . . . . . . 8 74 3.4. Packet Type Generation . . . . . . . . . . . . . . . . . 8 75 3.5. Standard Version Number . . . . . . . . . . . . . . . . . 9 76 3.6. Expiration Time . . . . . . . . . . . . . . . . . . . . . 9 77 3.7. Format . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 3.8. Multiple Servers for One Domain . . . . . . . . . . . . . 11 79 3.9. Multiple Entities With One Load Balancer . . . . . . . . 11 80 4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 12 81 4.1. The aliasing_parameters Transport Parameter . . . . . . . 13 82 5. Server Actions on Aliased Version Numbers . . . . . . . . . . 14 83 6. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 6.1. Bad Salt Packets . . . . . . . . . . . . . . . . . . . . 15 85 6.2. Client Response to Bad Salt . . . . . . . . . . . . . . . 17 86 6.3. version_aliasing_fallback Transport Parameter . . . . . . 17 87 6.4. Server Response to version_aliasing_fallback Transport 88 Parameter . . . . . . . . . . . . . . . . . . . . . . . . 18 89 7. Considerations for Retry Packets . . . . . . . . . . . . . . 19 90 8. Security and Privacy Considerations . . . . . . . . . . . . . 19 91 8.1. Endpoint Impersonation . . . . . . . . . . . . . . . . . 19 92 8.2. First-Connection Privacy . . . . . . . . . . . . . . . . 20 93 8.3. Forcing Downgrade . . . . . . . . . . . . . . . . . . . . 20 94 8.4. Initial Packet Injection . . . . . . . . . . . . . . . . 21 95 8.5. Retry Injection . . . . . . . . . . . . . . . . . . . . . 21 96 8.6. Increased Linkability . . . . . . . . . . . . . . . . . . 22 97 8.7. Salt Polling . . . . . . . . . . . . . . . . . . . . . . 22 98 8.8. Server Fingerprinting . . . . . . . . . . . . . . . . . . 22 99 8.9. Increased Processing of Garbage UDP Packets . . . . . . . 23 100 8.10. Increased Retry Overhead . . . . . . . . . . . . . . . . 23 101 8.11. Request Forgery . . . . . . . . . . . . . . . . . . . . . 23 102 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 103 9.1. QUIC Version Registry . . . . . . . . . . . . . . . . . . 23 104 9.2. QUIC Transport Parameter Registry . . . . . . . . . . . . 24 105 9.3. QUIC Transport Error Codes Registry . . . . . . . . . . . 24 106 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 107 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 108 10.2. Informative References . . . . . . . . . . . . . . . . . 25 109 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 25 110 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25 111 B.1. since draft-duke-quic-version-aliasing-07 . . . . . . . . 25 112 B.2. since draft-duke-quic-version-aliasing-05 . . . . . . . . 26 113 B.3. since draft-duke-quic-version-aliasing-04 . . . . . . . . 26 114 B.4. since draft-duke-quic-version-aliasing-03 . . . . . . . . 26 115 B.5. since draft-duke-quic-version-aliasing-02 . . . . . . . . 26 116 B.6. since draft-duke-quic-version-aliasing-01 . . . . . . . . 26 117 B.7. since draft-duke-quic-version-aliasing-00 . . . . . . . . 26 118 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 120 1. Introduction 122 The QUIC version number is critical to future extensibility of the 123 protocol ([RFC9000]). Past experience with other protocols, such as 124 TLS1.3 [RFC8446], shows that middleboxes might attempt to enforce 125 that QUIC packets use versions known at the time the middlebox was 126 implemented. This deters deployment of experimental and standard 127 versions on the internet. 129 Each version of QUIC has a "salt" [RFC9001] that is used to derive 130 the keys used to encrypt Initial packets. As each salt is published 131 in a standards document, any observer can decrypt these packets and 132 inspect the contents, including a TLS Client Hello. A subsidiary 133 mechanism like Encrypted Client Hello [ECHO] might protect some of 134 the TLS fields inside a TLS Client Hello. 136 This document proposes "QUIC Version Aliasing," a standard way for 137 servers to advertise the availability of other versions inside the 138 cryptographic protection of a QUIC handshake. These versions are 139 syntactically identical to the QUIC version in which the 140 communication takes place, but use a different salt. In subsequent 141 communications, the client uses the new version number and encrypts 142 its Initial packets with a key derived from the provided salt. These 143 version numbers and salts are unique to the client. 145 If a large subset of QUIC traffic adopts his technique, middleboxes 146 will be unable to enforce particular version numbers or policy based 147 on Client Hello contents without incurring unacceptable penalties on 148 users. This would simultaneously protect the protocol against 149 ossification and improve its privacy properties. 151 1.1. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [RFC2119]. 157 In this document, these words will appear with that interpretation 158 only when in ALL CAPS. Lower case uses of these words are not to be 159 interpreted as carrying significance described in RFC 2119. 161 A "standard version" is a QUIC version that would be advertised in a 162 QUIC version negotiation and conforms to a specification. Any 163 aliased version corresponds to a standard version in all its formats 164 and behaviors, except for the version number field in long headers. 165 To be compatible with version aliasing, there MUST be no more than 166 four long header packet types, and the first client packet in a 167 standard version MUST encode the token as if it were a QUIC version 1 168 initial packet. That is: 170 * The most significant bit MUST be 1. 172 * The first field after the Source Connection ID MUST be a variable- 173 length integer including the length of a token. 175 * The second field after the Destination Connection ID MUST be a 176 field, with length indicated by the previous field, that contains 177 opaque data generated by the server. 179 * There must be a variable-length integer that encodes the packet 180 length, unprotected in the header. 182 An "aliased version" is a version with a number generated in 183 accordance with this document. Except for the version field in long 184 headers, it conforms entirely to the specification of the standard 185 version. 187 2. Protocol Overview 189 When they instantiate a connection, servers select an alternate 190 32-bit version number, and optionally an initial token extension, for 191 the next connection at random and securely derive a salt, packet 192 Length Offset, and long header packet type codepoints from those 193 values using a repeatable process. They communicate this using a 194 transport parameter extension including the version, initial token 195 extension, Initial salt, Packet Length Offset, packet type 196 codepoints, and an expiration time for that value. 198 If a client next connects to that server within the indicated 199 expiration time, it MAY use the provided version number and encrypt 200 its Initial Packets using a key derived from the provided salt. It 201 uses the provided Initial packet codepoint. It adds the Packet 202 Length Offset to the true packet length when encoding it in the long 203 header. If the server provided an Initial Token Extension, the 204 client puts it in the Initial Packet token field. If there is 205 another token the client wishes to include, it appends the Initial 206 Token Extension to that token. The server can reconstruct the salt 207 and Packet Length Offset from the requested version and token, and 208 proceed with the connection normally. 210 The Packet Length Offset provides a low-cost way for the server to 211 verify it can derive a valid salt from the inputs without trial 212 decryption. This has important security implications, as described 213 in Section 8.5. 215 When generating a salt and Packet Length Offset, servers can choose 216 between doing so randomly and storing the mapping, or using a 217 cryptographic process to transform the aliased version number and 218 token extension into the salt. The two options provide a simple 219 tradeoff between computational complexity and storage requirements. 221 Long header packets are composed identically to their standard 222 version, except that they use the provided packet type codepoint, 223 version number, and packet length offset. Initial packets 224 additionally use any provided token extension and are encrypted as 225 described below. 227 Short header packets are unchanged when using this extension. 229 2.1. Relationship to ECH and QUIC Protected Initials 231 The TLS Encrypted Client Hello [ECHO] shares some goals with this 232 document. It encodes an "inner" encrypted Client Hello in a TLS 233 extension in an "outer" Client Hello. The encryption uses asymmetric 234 keys with the server's public key distributed via an out-of-band 235 mechanism like DNS. The inner Client Hello contains any privacy- 236 sensitive information and is only readable with the server's private 237 key. 239 Significantly, unlike QUIC Version Aliasing, ECH can operate on the 240 first connection between a client and server. However, from the 241 second connection QUIC version aliasing provides additional benefits. 242 It: 244 * greases QUIC header fields and packet formats; 246 * protects all of the TLS Client Hello and Server Hello; 248 * mitigates Retry injection attacks; 250 * does not require a mechanism to distribute the public key; 252 * uses smaller Client Hello messages, which might allow a larger 253 0RTT packet in the same datagram; and 255 * relies on computationally cheap symmetric encryption. 257 If ECH is operating in "Split Mode", where a client-facing server is 258 using the SNI information to route to a backend server, the client- 259 facing server MUST have the cryptographic context relevant to version 260 aliasing at the backend server to successfully extract the SNI for 261 routing purposes. Furthermore, either all backend servers must share 262 this context, or the client-facing server must trial decrypt the 263 incoming packet with all possible derived salts. 265 Note that in the event of the server losing state, the two approaches 266 have a similar fallback: ECH uses information in the outer Client 267 Hello, and Version Aliasing requires a connection using a standard 268 version. In either case, maintaining privacy requires the outer or 269 standard version Client Hello to exclude privacy-sensitive 270 information. However, ECH will allow confidential transmission of 271 data in 1 RTT, while Version Aliasing requires 2 RTTs to resume. 272 This mechanism is also relevant to mitigation of downgrade attacks 273 (see Section 8.3). 275 Similarly, the QUIC Protected Initial [QUIC-PI] uses the ECH 276 distribution mechanism to generate secure initial keys and Retry 277 integrity tags. While still dependent on a key distribution system, 278 asymmetric encryption, and relatively large Initial packets, it 279 offers similar protection properties to Version Aliasing while still 280 not greasing the version field. 282 A maximally privacy-protecting client might use Protected Initials 283 for any connection attempts for which it does not have an unexpired 284 aliased version, and QUIC version aliasing otherwise. 286 See also section 1.1 of [QUIC-PI] for further discussion of 287 tradeoffs. 289 3. The Version Alias Transport Parameter 291 3.1. Aliased Version Number Generation 293 Servers MUST use a random process to generate version numbers. This 294 version number MUST NOT correspond to a QUIC version the server 295 advertises in QUIC Version Negotiation packets or transport 296 parameters. Servers SHOULD also exclude version numbers used in 297 known specifications or experiments to avoid confusion at clients, 298 whether or not they have plans to support those specifications. 300 Servers MAY use version numbers reserved for grease in Section 15.1 301 of [RFC9000], even though they might be advertised in Version 302 Negotiation Packets. 304 Servers MUST NOT use client-controlled information (e.g. the client 305 IP address) in the random process, see Section 8.7. 307 Servers MUST NOT advertise these versions in QUIC Version Negotiation 308 packets. 310 3.2. Initial Token Extension (ITE) Generation 312 Servers SHOULD generate an Initial Token Extension (ITE) to provide 313 additional entropy in salt generation. Two clients that receive the 314 same version number but different extensions will not be able to 315 decode each other's Initial Packets. 317 Servers MAY choose any length that will allow client Initial Packets 318 to fit within the minimum QUIC packet size of 1200 octets. A four- 319 octet extension is RECOMMENDED. The ITE MUST appear to be random to 320 observers. 322 The server MUST be able to distinguish ITEs from Resumption and Retry 323 tokens in incoming Initial Packets that contain an aliased version 324 number. As the server controls the lengths and encoding of each, 325 there are many ways to guarantee this. 327 3.3. Salt and Packet Length Offset Generation 329 The salt is an opaque 20-octet field. It is used to generate Initial 330 connection keys using the process described in [RFC9001]. 332 The Packet Length Offset is a 64-bit unsigned integer with a maximum 333 value of 2^62 - 1. 335 To reduce header overhead, servers MAY consistently use a Packet 336 Length Offset of zero if and only if it either (1) never sends Retry 337 packets, or (2) can guarantee, through the use of persistent storage 338 or other means, that it will never lose the cryptographic state 339 required to generate the salt before the promised expiration time. 340 Section 8.5 describes the implications if it uses zero without 341 meeting these conditions. 343 Servers MUST either generate a random salt and Packet Length Offset 344 and store a mapping of aliased version and ITE to salt and offset, or 345 generate the salt and offset using a cryptographic method that uses 346 the version number, ITE, and only server state that is persistent 347 across connections. 349 If the latter, servers MUST implement a method that it can repeat 350 deterministically at a later time to derive the salt and offset from 351 the incoming version number and ITE. It MUST NOT use client 352 controlled information other than the version number and ITE; for 353 example, the client's IP address and port. 355 3.4. Packet Type Generation 357 The server generates the packet type codepoint for each of the four 358 long header packet types (Initial, 0RTT, Handshake, and Retry). Each 359 of these codepoints is two bits. 361 Future versions of QUIC with 4 or fewer long header packet types can 362 specify a mapping of these fields to their types. 364 Note that the server needs to derive the type codepoints solely from 365 the version number. It cannot extract the token, and the token 366 extension, until the packet is identified as an Initial packet. 368 A straightforward implementation might take arbitrary bits from a 369 hash of the version number. The first two bits it reads are the 370 codepoint for Initial packets. The next pair of bits that is not a 371 duplicate of the first is the codepoint for 0RTT packets. The next 372 pair that does not duplicate the first two is the codepoint for 373 Handshake packets, and the remaining codepoint is the Retry packet. 375 3.5. Standard Version Number 377 Servers also specify the Standard version that the client should use 378 to guide the wire formats and behaviors of the aliased version. This 379 version MUST meet the criteria to support version aliasing, and MUST 380 either be included as a supported version in the client's 381 version_information transport parameter (see 382 [I-D.ietf-quic-version-negotiation]) or be the standard version of 383 the current connection. 385 Note that servers MUST NOT accept resumption tickets or NEW_TOKEN 386 tokens from different standard versions. Therefore, the choice of 387 standard version might impact the performance of the connection that 388 uses an aliased version. The standard version that generated tickets 389 and/or tokens is typically encoded in those tickets or tokens. 391 There are several possible techniques for the server securely 392 recovering the standard version in use for an aliased connection: 394 * the server could store a mapping of aliased versions to standard 395 version; 397 * the server could encrypt the standard version in use in the 398 aliased version number (note that the ITE cannot be extracted 399 until the standard version in use is known); 401 * the server only accepts one standard version for aliased versions; 402 or 404 * the standard version is included as an input to the parameter 405 generation algorithm, and the server tries all supported standard 406 versions and tests each resulting Packet Length Offset for 407 validity. 409 3.6. Expiration Time 411 Servers should select an expiration time in seconds, measured from 412 the instant the transport parameter is first sent. This time SHOULD 413 be less than the time until the server expects to support new QUIC 414 versions, rotate the keys used to encode information in the version 415 number, or rotate the keys used in salt generation. 417 Furthermore, the expiration time SHOULD be short enough to frustrate 418 a salt polling attack (Section 8.7) 420 Conversely, an extremely short expiration time will often force the 421 client to use standard QUIC version numbers and salts. 423 3.7. Format 425 This document defines a new transport parameter extension for QUIC 426 with provisional identifier 0x5641. The contents of the value field 427 are indicated below. 429 0 1 2 3 430 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 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Aliased Version (32) | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Standard Version (32) | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | | 437 + + 438 | | 439 + + 440 | Salt (160) | 441 + + 442 | | 443 + + 444 | | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Packet Length Offset (i) | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Expiration (i) | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 |INI|0RT|HAN|RET| Initial Token Extension (variable) | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Figure 1: Version Alias Transport Parameter value 455 The definition of the fields is described above. Note that the 456 "Expiration" field is in seconds, and its length is encoded using the 457 Variable Length Integer encoding from Section 16 of [RFC9000]. 459 The Packet Length Offset is also encoded as a Variable Length 460 Integer. 462 INI, 0RT, HAN, and RET are the codepoints for each long header packet 463 type. If any two packet types have the same codepoint, the transport 464 parameter is invalid. 466 Clients can compute the length of the Initial Token Extension by 467 subtracting known and encoded field lengths from the overall 468 transport parameter length. 470 Note that servers that support version aliasing need not send the 471 transport parameter on every connection. Therefore, a client MAY 472 attempt to connect with an unexpired aliased version, even if in its 473 most recent connection it did not receive the transport parameter. 475 Clients MAY remember the values in this transport parameter for 476 future connections. Servers MUST either store the contents of the 477 transport parameter, or preserve the state to compute the full 478 contents based on what the client provides. 480 A server that receives this transport parameter MUST close the 481 connection with a TRANSPORT_PARAMETER_ERROR. 483 3.8. Multiple Servers for One Domain 485 If multiple servers serve the same entity behind a load balancer, all 486 such servers SHOULD either have a common configuration for encoding 487 standard versions and computing salts, or share a common database of 488 mappings. They MUST NOT generate version numbers that any of them 489 would advertise in a Version Negotiation Packet or Transport 490 Parameter. 492 3.9. Multiple Entities With One Load Balancer 494 If mutually mistrustful entities share the same IP address and port, 495 incoming packets are usually routed by examining the SNI at a load 496 balancer server that routes the traffic. This use case makes 497 concealing the contents of the Client Initial especially attractive, 498 as the IP address reveals less information. There are several 499 solutions to solve this problem. 501 * All entities have a common crytographic context for deriving salts 502 and Packet Length Offsets from the version number and ITE. This 503 is straightforward but also increases the risk that the keys will 504 leak to an attacker which could then decode Initial packets from 505 point where the packets are observable. This is therefore NOT 506 RECOMMENDED. 508 * Each entity has its own cryptographic context, shared with the 509 load balancer. This requires the load balancer to trial decrypt 510 each incoming Initial with each context. As there is no standard 511 algorithm for encoding information in the Version and ITE, this 512 involves synchronizing the method, not just the key material. 514 * Each entity reports its Version Aliasing Transport Parameters to 515 the load balancer out-of-band. 517 * Each entity is assigned certain version numbers for use. This 518 assignment SHOULD NOT follow observable patterns (e.g., assigning 519 ranges to each entity), as this would allow observers to obtain 520 the target server based on the version. The scheme SHOULD assign 521 all available version numbers to maximize the entropy of the 522 encoding. 524 Note that [ECHO] and [QUIC-PI] solve this problem elegantly by only 525 holding the private key at the load balancer, which decodes the 526 sensitive information on behalf of the back-end server. 528 4. Client Behavior 530 When a client receives the Version Alias Transport Parameter, it MAY 531 cache the version number, ITE, salt, Packet Length Offset, packet 532 type codepoints, and the expiration of these values. It MAY use the 533 version number and ITE in a subsequent connection and compute the 534 initial keys using the provided salt. 536 The Client MUST NOT use the contents of a Version Alias transport 537 parameter if the handshake does not (1) later authenticate the server 538 name or (2) result in both endpoints computing the same 1-RTT keys. 539 See Section 8.1. The authenticated server name MAY be a "public 540 name" distributed as described in [ECHO] rather than the true target 541 domain. 543 Clients MUST NOT advertise aliased versions in the Version 544 Negotiation Transport Parameter unless they support a standard 545 version with the same number. Including that number signals support 546 for the standard version, not the aliased version. 548 Clients SHOULD NOT attempt to use the provided version number and 549 salt after the provided Expiration time has elapsed. 551 Clients MAY decline to use the provided version number or salt in 552 more than one connection. It SHOULD do so if its IP address has 553 changed between two connection attempts. Using a consistent version 554 number can link the client across connection attempts. 556 Clients MUST use the same standard version to format the Initial 557 Packet as the standard version used in the connection that provided 558 the aliased version. 560 Clients MUST use the provided codepoints to encode the packet type. 562 If the server provided an ITE, the client MUST append it to any 563 Initial Packet token it is including from a Retry packet or NEW_TOKEN 564 frame, if it is using the associated aliased version. If there is no 565 such token, it simply includes the ITE as the entire token. 567 When using an aliased version, the client MUST include a 568 aliasing_parameters transport parameter in its Client Hello. 570 The QUIC Token Length field MUST include the length of both any Retry 571 or NEW_TOKEN token and the ITE. 573 The Length fields of all Initial, Handshake, and 0-RTT packets in the 574 connection are set to the value described in [RFC9000] plus the 575 provided Packet Length Offset, modulo 2^62. 577 If a client receives an aliased version number that matches a 578 standard version that the client supports, it SHOULD assume the 579 server does not support the standard version and MUST use aliased 580 version behaviors in any connection with the server using that 581 version number. 583 If the response to an Initial packet using the provided version is a 584 Version Negotiation Packet, the client SHOULD assume that the server 585 no longer supports version aliasing and attempt to connect with one 586 of the advertised versions (while observing the considerations in 587 Section 8.3). 589 If the response to an Initial packet is a Bad Salt packet, the client 590 follows the procedures in Section 6. 592 4.1. The aliasing_parameters Transport Parameter 594 This transport parameter has the following format. Its provisional 595 type is 0x4150. 597 0 1 2 3 598 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 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Version (32) | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Initial Token (variable) | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 The Version field matches the one in the packet header. 607 The Initial Token field matches the Initial Token in the packet 608 header, including any Retry token, NEW_TOKEN token, and Initial Token 609 Extension. Its length is inferred from the specified length of the 610 parameter. 612 The purpose of this parameter is to validate the contents of these 613 header fields by including it in the TLS handshake transcript. 615 A client that receives this transport parameter MUST close the 616 connection with a TRANSPORT_PARAMETER_ERROR. 618 5. Server Actions on Aliased Version Numbers 620 When a server receives a packet with an unsupported version number, 621 it SHOULD send a Version Negotiation Packet if it is configured not 622 to generate that version number at random. 624 Otherwise, when a server receives the first long header packet with 625 an unsupported version number, it hashes that version number to 626 obtain the packet type mapping. If the packet is Handshake or Retry, 627 there may have been a loss of relevant server state; the server 628 discards the packet and SHOULD follow the procedure in Section 6. If 629 0RTT, the server MAY either buffer it in anticipation of a later 630 Initial, or immediately follow the procedure in Section 6. If 631 buffering, and an Initial packet never arrives, the server SHOULD 632 follow the procedure in Section 6 when discarding any 0RTT packets. 634 For an Initial packet, it extracts the ITE, if any, and either looks 635 up the corresponding salt in its database or computes it using the 636 technique originally used to derive the salt from the version number 637 and ITE. 639 The server similarly obtains the Packet Length Offset and subtracts 640 it from the provided Length field, modulo 2^62. If the resulting 641 value is larger than the entire UDP datagram, the server discards the 642 packet and SHOULD follow the procedure in Section 6. The server MAY 643 apply further checks (e.g. against the minimum QUIC packet length) to 644 further reduce the very small probability of a false positive. 646 If the server supports multiple standard versions, it uses the 647 standard version extracted by the ITE or stored in the mapping to 648 parse the decrypted packet. 650 In all packets with long headers, the server uses the aliased version 651 number and adds the Packet Length Offset to the length field. 653 In the extremely unlikely event that the Packet Length Offset 654 resulted in a legal value but the salt is incorrect, the packet may 655 fail authentication. The server should drop these packets in case 656 this is the result of packet corruption along the path. 658 To reduce linkability for the client, servers SHOULD provide a new 659 Version Alias transport parameter, with a new version number, ITE, 660 salt, and Packet Length Offset, each time a client connects. 661 However, issuing version numbers to a client SHOULD be rate-limited 662 to mitigate the salt polling attack Section 8.7 and MAY cease to 663 clients that are consistently connecting with standard versions. 665 If there is no aliasing_parameters transport parameter, or the 666 contents do not match the fields in the Initial header, the server 667 MUST terminate the connection with a TRANSPORT_PARAMETER_ERROR. 669 6. Fallback 671 If the server has lost its encryption state, it may not be able to 672 generate the correct salts from previously provided versions and 673 ITEs. The fallback mechanism provides a means of recovering from 674 this state while protecting against injection of messages by 675 attackers. 677 When the packet length computation in Section 5 fails, it signals 678 either that the packet has been corrupted in transit, or the client 679 is using a transport parameter issued before a server failure. In 680 either case, the server sends a Bad Salt packet. 682 6.1. Bad Salt Packets 684 The Bad Salt packet has a long header and a reserved version number, 685 because it must not be confused with a legitimate packet in any 686 standard version. They are not encrypted, not authenticated, and 687 have the following format: 689 Bad Salt Packet { 690 Header Form (1) = 1, 691 Unused (7), 692 Version (32) = TBD (provisional value = 0x56415641), 693 Destination Connection ID Length (8), 694 Destination Connection ID (0..2040), 695 Source Connection ID Length (8), 696 Source Connection ID (0..2040), 697 Supported Version (32) ..., 698 Integrity Tag (128), 699 } 700 Unused: The unused field is filled randomly by the sender and ignored 701 on receipt. 703 Version: The version field is reserved for use by the Bad Salt 704 packet. 706 Destination and Source Connection IDs and Lengths: These fields are 707 copied from the client packet, with the source fields from the client 708 packet written into the destination fields of the Bad Salt, and vice 709 versa. 711 Supported Version: A list of standard QUIC version numbers which the 712 server supports. The number of versions is inferred from the length 713 of the datagram. 715 Integrity Tag: To compute the integrity tag, the server creates a 716 pseudo-packet by contents of the entire client Initial UDP payload, 717 including any coalesced packets, with the Bad Salt packet: 719 Bad Salt Pseudo-Packet { 720 Client UDP Payload (9600..), 721 Header Form (1) = 1, 722 Unused (7), 723 Version (32) = TBD (provisional value = 0x56415641), 724 Destination Connection ID Length (8), 725 Destination Connection ID (0..2040), 726 Source Connection ID Length (8), 727 Source Connection ID (0..2040), 728 Supported Version (32) ..., 729 } 731 In a process similar to the Retry Integrity Tag, the Bad Salt 732 Integrity Tag is computed as the output of AEAD_AES_128_GCM with the 733 following inputs: 735 * The secret key, K, is 0xbe0c690b9f66575a1d766b54e368c84e. 737 * The nonce, N, is 0x461599d35d632bf2239825bb. 739 * The plaintext, P, is empty. 741 * The associated data, A, is the Bad Salt pseudo-packet. 743 These values are derived using HKDF-Expand-Label from the secret 744 0x767fedaff519a2aad117d8fd3ce0a04178ed205ab0d43425723e436853c4b3e2 745 and labels "quicva key" and "quicva iv". 747 The integrity tag serves to validate the integrity of both the Bad 748 Salt packet itself and the Initial packet that triggered it. 750 6.2. Client Response to Bad Salt 752 Upon receipt of a Bad Salt packet, the client SHOULD wait for a Probe 753 Timeout (PTO) to check if the Bad Salt packet was injected by an 754 attacker, and a valid response arrives from the actual server. 756 After waiting, the client checks the Integrity Tag using its record 757 of the Initial it sent. If this fails, the client SHOULD assume 758 packet corruption and resend the Initial packet. 760 If the verification succeeds, the client SHOULD attempt to connect 761 with one of the listed standard versions. It SHOULD observe the 762 privacy considerations in Section 8.2. It MUST include a 763 version_aliasing_fallback Transport Parameter in the Client Hello. 765 Once it sends this transport parameter, the client MUST NOT attempt 766 to connect with that aliased version again. 768 The original Client Initial is not part of the new connection. 769 Therefore, the Connection IDs can change, and the original client 770 hello is not part of the transcript for TLS key derivation. 772 6.3. version_aliasing_fallback Transport Parameter 774 The client sends this transport parameter in a TLS Client Hello 775 generated in response to a Bad Salt packet: 777 0 1 2 3 778 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 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Aliased Version (32) | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | | 783 + + 784 | | 785 + + 786 | Salt (160) | 787 + + 788 | | 789 + + 790 | | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | | 793 + + 794 | | 795 + Bad Salt Integrity Tag (128) + 796 | | 797 + + 798 | | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Initial Token (variable) | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 The Aliased Version, Salt, and Initial Token fields are taken from 804 the connection attempt that triggered this fallback. The length of 805 the Initial Token is inferred from the Transport Parameter's overall 806 length. 808 The Bad Salt Integrity Tag comes from is taken from the Bad Salt 809 packet that triggered this fallback. Its purpose is to include the 810 Bad Salt packet contents in the TLS handshake hash. 812 6.4. Server Response to version_aliasing_fallback Transport Parameter 814 A client version_aliasing_fallback transport parameter tells the 815 server that the client received a Bad Salt packet. The server checks 816 if using the version and ITE as inputs results in the same salt. 818 If the salt does not match, the server SHOULD continue with the 819 connection and SHOULD issue a new version_aliasing transport 820 parameter. 822 If the salt and Packet Length Offset are valid, the server MUST 823 terminate the connection with the error code INVALID_BAD_SALT. 825 Note that the client never sends this transport parameter with an 826 aliased version. A server that receives such a packet MUST terminate 827 the connection with a TRANSPORT_PARAMETER_ERROR. 829 7. Considerations for Retry Packets 831 QUIC Retry packets reduce the load on servers during periods of 832 stress by forcing the client to prove it possesses the IP address 833 before the server decrypts any Initial Packets or establishes any 834 connection state. Version aliasing substantially complicates the 835 process. 837 If a server has to send a Retry packet, the required format is 838 ambiguous without understanding which standard version to use. If 839 all supported standard versions use the same Retry format, it simply 840 uses that format with the client-provided version number. 842 If the supported standard versions use different Retry formats, the 843 server obtains the standard version via lookup or decoding and 844 formats a Retry containing the aliased version number accordingly. 846 Servers generate the Retry Integrity Tag of a Retry Packet using the 847 procedure in Section 5.8 of [RFC9001]. However, for aliased 848 versions, the secret key K uses the first 16 octets of the aliased 849 salt instead of the key provided in the specification. 851 Clients MUST ignore Retry packets that contain a QUIC version other 852 than the version it used in its Initial Packet. 854 Servers MUST NOT reply to a packet with an incorrect Length field in 855 its long header with a Retry packet; it SHOULD reply with Bad Salt as 856 described above. 858 8. Security and Privacy Considerations 860 This document intends to improve the existing security and privacy 861 properties of QUIC by dramatically improving the secrecy of QUIC 862 Initial Packets. However, there are new attacks against this 863 mechanism. 865 8.1. Endpoint Impersonation 867 An on-path attacker might respond to an Initial Packet with a 868 standard version with a Version Aliasing Transport Parameter that 869 then caused the client to reveal sensitive information in a 870 subsequent Initial. 872 As described in Section 4, clients cannot use the contents of a 873 Version Aliasing transport parameter until they have authenticated 874 the source as a trusted domain, and have verified that the 1RTT key 875 derivation is identical at both endpoints. 877 8.2. First-Connection Privacy 879 As version aliasing requires one connection over a standard QUIC 880 version to acquire initial state, this initial connection leaks some 881 information about the true target. 883 The client MAY alter its Initial Packet to sanitize sensitive 884 information and obtain another aliased version before proceeding with 885 its true request. However, the client Initial must lead to the 886 authentication of a domain name the client trusts to provide accurate 887 Version Aliasing information (possibly the public_name from an 888 Encrypted Client Hello configuration from [ECHO]). Advice for the 889 Outer ClientHello in Section 10.5 of [ECHO] applies here. 891 Endpoints are encouraged to instead use [ECHO] or [QUIC-PI] to 892 increase privacy on the first connection between a client and server. 894 8.3. Forcing Downgrade 896 An attacker can attempt to force a client to send an Initial that 897 uses a standard version by injecting a Version Negotiation packet 898 (which implies the server no longer supports aliasing) or a Bad Salt 899 packet (which implies the server has a new cryptographic context). 901 The weak form of this attack observes the Initial and injects the 902 Version Negotiation or Bad Salt packet, but cannot drop the Initial. 903 To counteract this, a client SHOULD NOT respond to these packets 904 until they have waited for Probe Timeout (PTO) for a valid server 905 Initial to arrive. 907 The strong form features an attacker that can drop Initial packets. 908 In this case, the client can either abandon the connection attempt or 909 connect with an standard version. 911 If it connects with a standard version, it should consider the 912 privacy advice in Section 8.2. 914 Furthermore, if it received a Bad Salt packet, the client sends a 915 Version Aliasing transport parameter to detect the downgrade attack, 916 and the server will terminate the connection if the Bad Salt packet 917 was an attack. 919 If the client received a Version Negotiation packet, it MUST 920 implement a downgrade detection mechanism such as 921 [I-D.ietf-quic-version-negotiation] or abandon the connection 922 attempt. If it subsequent detects a downgrade detection, or 923 discovers that the server does not support the same mechanism, it 924 terminates the connection attempt. 926 8.4. Initial Packet Injection 928 QUIC version 1 handshakes are vulnerable to DoS from observers for 929 the short interval that endpoints keep Initial keys (usually ~1.5 930 RTTS), since Initial Packets are not authenticated. With version 931 aliasing, attackers do not have the necessary keys to launch such an 932 attack. 934 8.5. Retry Injection 936 QUIC Version 1 Retry packets are spoofable, as they follow a fixed 937 format, are sent in plaintext, and the integrity protection uses a 938 widely known key. As a result, QUIC Version 1 has verification 939 mechanisms in subsequent packets of the connection to validate the 940 origin of the Retry. 942 Version aliasing largely frustrates this attack. As the integrity 943 check key is derived from the secret salt, packets from attackers 944 will fail their integrity check and the client will ignore them. 946 The Packet Length Offset is important in this framework. Without 947 this mechanism, servers would have to perform trial decryption to 948 verify the client was using the correct salt. As this does not occur 949 before sending Retry Packets, servers would not detect disagreement 950 on the salt beforehand and would send a Retry packet signed with a 951 different salt than the client expects. Therefore, a client that 952 received a Retry packet with an invalid integrity check would not be 953 able to distinguish between the following possibilities: 955 * a Retry packet corrupted in the network, which should be ignored; 957 * a Retry packet generated by an attacker, which should be ignored; 958 or 960 * a Retry packet from a server that lost its cryptographic state, 961 meaning that further communication with aliased versions is 962 impossible and the client should revert to using a standard 963 version. 965 The Packet Length Offset introduces sufficient entropy to make the 966 third possibility exceedingly unlikely. 968 8.6. Increased Linkability 970 As each version number and ITE is unique to each client, if a client 971 uses one twice, those two connections are extremely likely to be from 972 the same host. If the client has changed IP address, this is a 973 significant increase in linkability relative to QUIC with a standard 974 version numbers. 976 8.7. Salt Polling 978 Observers that wish to decode Initial Packets might open a large 979 number of connections to the server in an effort to obtain part of 980 the mapping of version numbers and ITEs to salts for a server. While 981 storage-intensive, this attack could increase the probability that at 982 least some version-aliased connections are observable. There are 983 three mitigations servers can execute against this attack: 985 * use a longer ITE to increase the entropy of the salt, 987 * rate-limit transport parameters sent to a particular client, and/ 988 or 990 * set a low expiration time to reduce the lifetime of the attacker's 991 database. 993 Segmenting the version number space based on client information, i.e. 994 using only a subset of version numbers for a certain IP address 995 range, would significantly amplify an attack. Observers will 996 generally be on the path to the client and be able to mimic having an 997 identical IP address. Segmentation in this way would dramatically 998 reduce the search space for attackers. Thus, servers are prohibited 999 from using this mechanism. 1001 8.8. Server Fingerprinting 1003 The server chooses its own ITE length, and the length of this ITE is 1004 likely to be discoverable to an observer. Therefore, the destination 1005 server of a client Initial packet might be decipherable with an ITE 1006 length along with other observables. A four-octet ITE is 1007 RECOMMENDED. Deviations from this value should be carefully 1008 considered in light of this property. 1010 Servers with acute needs for higher or lower entropy than provided by 1011 a four- octet ITE are RECOMMENDED to converge on common lengths to 1012 reduce the uniqueness of their signatures. 1014 8.9. Increased Processing of Garbage UDP Packets 1016 As QUIC shares the UDP protocol number with other UDP applications, 1017 in some deployments it may be possible for traffic intended for other 1018 UDP applications to arrive at a QUIC server endpoint. When servers 1019 support a finite set of version numbers, a valid version number field 1020 is a strong indicator the packet is, in fact, QUIC. If the version 1021 number is invalid, a QUIC Version Negotiation is a low-cost response 1022 that triggers very early in packet processing. 1024 However, a server that provides version aliasing is prepared to 1025 accept almost any version number. As a result, many more 1026 sufficiently sized UDP payloads with the first bit set to '1' are 1027 potential QUIC Initial Packets that require computation of a salt and 1028 Packet Length Offset. 1030 Note that a nonzero Packet Length Offset will allow the server to 1031 drop all but approximately 1 in every 2^49 packets, so trial 1032 decryption is unnecessary. 1034 While not a more potent attack then simply sending valid Initial 1035 Packets, servers may have to provision additional resources to 1036 address this possibility. 1038 8.10. Increased Retry Overhead 1040 This document requires two small cryptographic operations to build a 1041 Retry packet instead of one, placing more load on servers when 1042 already under load. 1044 8.11. Request Forgery 1046 Section 21.4 of [RFC9000] describes the request forgery attack, where 1047 a QUIC endpoint can cause its peer to deliver packets to a victim 1048 with specific content. 1050 Version aliasing allows the server to specify the contents of the 1051 version field and part of the token field in Initial packets sent by 1052 the client, potentially increasing the potency of this attack. 1054 9. IANA Considerations 1056 9.1. QUIC Version Registry 1058 This document request that IANA add the following entry to the QUIC 1059 version registry: 1061 Value: TBD 1062 Status: permanent 1064 Specification: This document 1066 Change Controller: IETF 1068 Contact: QUIC WG 1070 9.2. QUIC Transport Parameter Registry 1072 This document requests that IANA add the following entries to the 1073 QUIC Transport Parameters Registry: 1075 +=======+===========================+===============+ 1076 | Value | Parameter Name | Specification | 1077 +=======+===========================+===============+ 1078 | TBD | version_aliasing | This Document | 1079 +-------+---------------------------+---------------+ 1080 | TBD | aliasing_parameters | This Document | 1081 +-------+---------------------------+---------------+ 1082 | TBD | version_aliasing_fallback | This Document | 1083 +-------+---------------------------+---------------+ 1085 Table 1 1087 9.3. QUIC Transport Error Codes Registry 1089 This document requests that IANA add the following entry to the QUIC 1090 Transport Error Codes registry: 1092 Value: TBD (provisional: 0x4942) 1094 Code: INVALID_BAD_SALT 1096 10. References 1098 10.1. Normative References 1100 [I-D.ietf-quic-version-negotiation] 1101 Schinazi, D. and E. Rescorla, "Compatible Version 1102 Negotiation for QUIC", Work in Progress, Internet-Draft, 1103 draft-ietf-quic-version-negotiation-07, 5 April 2022, 1104 . 1107 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1108 Multiplexed and Secure Transport", RFC 9000, 1109 DOI 10.17487/RFC9000, May 2021, 1110 . 1112 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 1113 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 1114 . 1116 10.2. Informative References 1118 [ECHO] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 1119 Encrypted Client Hello", Work in Progress, Internet-Draft, 1120 draft-ietf-tls-esni-14, 13 February 2022, 1121 . 1124 [QUIC-PI] Duke, M. and D. Schinazi, "Protected QUIC Initial 1125 Packets", Work in Progress, Internet-Draft, draft-duke- 1126 quic-protected-initial-04, 27 April 2022, 1127 . 1130 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1131 Requirement Levels", BCP 14, RFC 2119, 1132 DOI 10.17487/RFC2119, March 1997, 1133 . 1135 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1136 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1137 . 1139 Appendix A. Acknowledgments 1141 Marten Seemann was the original creator of the version aliasing 1142 approach. 1144 Appendix B. Change Log 1146 *RFC Editor's Note:* Please remove this section prior to 1147 publication of a final version of this document. 1149 B.1. since draft-duke-quic-version-aliasing-07 1151 * Added the Bad Salt Integrity Tag to the transport parameter 1153 * Greased packet types 1154 * Allowed the server to specify the standard version to connect with 1156 B.2. since draft-duke-quic-version-aliasing-05 1158 * Revised security considerations 1160 * Discussed multiple SNIs behind one load balancer 1162 * Removed VN from the fallback mechanism 1164 B.3. since draft-duke-quic-version-aliasing-04 1166 * Relationship with Encrypted Client Hello (ECH) and QUIC Protected 1167 Initials 1169 * Corrected statement about version negotiation 1171 B.4. since draft-duke-quic-version-aliasing-03 1173 * Discussed request forgery attacks 1175 B.5. since draft-duke-quic-version-aliasing-02 1177 * Specified 0RTT status of the transport parameter 1179 B.6. since draft-duke-quic-version-aliasing-01 1181 * Fixed all references to "seed" where I meant "salt." 1183 * Added the Packet Length Offset, which eliminates Retry Injection 1184 Attacks 1186 B.7. since draft-duke-quic-version-aliasing-00 1188 * Added "Initial Token Extensions" to increase salt entropy and make 1189 salt polling attacks impractical. 1191 * Allowed servers to store a mapping of version number and ITE to 1192 salt instead. 1194 * Made standard version encoding mandatory. This dramatically 1195 simplifies the new Retry logic and changes the security model. 1197 * Added references to Version Negotiation Transport Parameters. 1199 * Extensive readability edit. 1201 Author's Address 1203 Martin Duke 1204 Google 1205 Email: martin.h.duke@gmail.com