idnits 2.17.1 draft-duke-quic-version-aliasing-00.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 (April 6, 2020) is 1480 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 April 6, 2020 5 Expires: October 8, 2020 7 QUIC Version Aliasing 8 draft-duke-quic-version-aliasing-00 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. If a sizeable subset of QUIC connections use this 18 mechanism, this should prevent middlebox ossification around the 19 current set of published version numbers and the contents of QUIC 20 Initial packets. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 8, 2020. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 59 3. The Version Alias Transport Parameter . . . . . . . . . . . . 4 60 3.1. Version Number Generation . . . . . . . . . . . . . . . . 4 61 3.2. Salt Generation . . . . . . . . . . . . . . . . . . . . . 4 62 3.3. Expiration Time . . . . . . . . . . . . . . . . . . . . . 5 63 3.4. Format . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Server Actions on Non-standard Version Numbers . . . . . . . 6 66 6. Considerations for Retry Packets . . . . . . . . . . . . . . 7 67 7. Security and Privacy Considerations . . . . . . . . . . . . . 8 68 7.1. Version Downgrade . . . . . . . . . . . . . . . . . . . . 8 69 7.2. Increased Linkability . . . . . . . . . . . . . . . . . . 8 70 7.3. Seed Polling Attack . . . . . . . . . . . . . . . . . . . 8 71 7.4. Increased Processing of Garbage UDP Packets . . . . . . . 9 72 7.5. Increased Retry Overhead . . . . . . . . . . . . . . . . 9 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 9.2. Informative References . . . . . . . . . . . . . . . . . 10 77 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 78 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 10 79 B.1. since draft-duke-quic-version-aliasing-00 . . . . . . . . 11 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 The QUIC version number is critical to future extensibility of the 85 protocol. Past experience with other protocols, such as TLS1.3 86 [RFC8446], shows that middleboxes might attempt to enforce that QUIC 87 packets use versions known at the time the middlebox was implemented. 88 This has a chilling effect on deploying experimental and standard 89 versions on the internet. 91 Each version of QUIC has a "salt" [QUIC-TLS] that is used to derive 92 the keys used to encrypt Initial packets. As each salt is published 93 in a standards document, any observer can decrypt these packets and 94 inspect the contents, including a TLS Client Hello. A subsidiary 95 mechanism like Encrypted SNI [ENCRYPTED-SNI] might protect some of 96 the TLS fields inside a TLS Client Hello. 98 This document proposes "QUIC Version Aliasing," a standard way of 99 servers advertising the availability of other versions inside the 100 cryptographic protection of a QUIC handshake. These versions are 101 syntactically identical to the QUIC version in which the 102 communication takes place, but use a different salt. In subsequent 103 communications, the client uses the new version number and encrypts 104 its Initial packets with a key derived from the provided salt. These 105 version numbers and salts are unique to the client. 107 If a large subset of QUIC traffic adopts his technique, middleboxes 108 will be unable to enforce particular version numbers or policy based 109 on Client Hello contents without incurring unacceptable penalties on 110 users. This would simultaneously protect the protocol against 111 ossification and improve its privacy properties. 113 1.1. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 In this document, these words will appear with that interpretation 120 only when in ALL CAPS. Lower case uses of these words are not to be 121 interpreted as carrying significance described in RFC 2119. 123 A "syntax version" is a QUIC version that would be advertised in a 124 QUIC version negotiation and conforms to a specification. Any 125 aliased version corresponds to a syntax version in all its formats 126 and behaviors, except for the version number field in long headers. 128 An "aliased version" is a version with a number generated in 129 accordance with this document. Except for the version field in long 130 headers, it conforms entirely to the specification of the syntax 131 version. 133 2. Protocol Overview 135 When they instantiate a connection, servers select an alternate 136 32-bit version number for the next connection at random and securely 137 derive a salt from that version number using a repeatable process. 138 They communicate this using a transport parameter extension including 139 the version, salt, and an expiration time for that value. 141 The next time a client connects to that server, if it is within the 142 indicated expiration time, it MAY use the provided version number and 143 encrypt its Initial Packets using a key derived from the provided 144 salt. The server can reconstruct the salt from the requested version 145 and proceed with the connection normally. 147 3. The Version Alias Transport Parameter 149 3.1. Version Number Generation 151 Servers MUST use a random process to generate version numbers. This 152 version number MUST NOT correspond to a QUIC version the server 153 advertises in QUIC Version Negotiation packets. 155 Servers MAY encode the syntax version as long as this information is 156 cryptographically protected. For example, a server advertises 157 support for QUIC version 1 and QUIC version 2 in Version Negotiation 158 packets, each corresponding to a particular packet syntax. In a 159 Version 1 connection, it might provide an aliased version in the 160 transport parameter, 0x45f3213b, that encodes the fact the syntax 161 version is 1. When the client initiates a connection using version 162 0x45f3213b, the server knows the Initial Packet is formatted in 163 accordance with QUIC version 1. A subsequent aliased version 164 provided in the transport parameters would also encode version 1, 165 even though this is sent in a connection ostensibly of version 166 0x45f3213b. 168 Servers MUST NOT use client-controlled information (e.g. the client 169 IP address) in the random process, see Section 7.3. 171 Servers MUST NOT advertise these versions in QUIC Version Negotiation 172 packets. 174 If multiple servers represent the same entity behind a load balancer, 175 all such servers SHOULD have a common configuration for how to encode 176 and extract syntax version to use. They MUST NOT generate version 177 numbers that any of them would advertise in a Version Negotiation 178 Packet. 180 3.2. Salt Generation 182 The salt is an opaque 20-octet field. It is used to generate a 183 Initial connection keys using the process described in {QUIC-TLS}. 185 Servers MUST generate the SALT using a cryptographic method that uses 186 the version number and only server state that is persistent across 187 connections. That is, servers MUST implement a method that it can 188 repeat deterministically at a later time to derive the salt from the 189 incoming version number. It MUST NOT use client controlled 190 information other than the version number; for example, the client's 191 IP address and port. 193 3.3. Expiration Time 195 Servers should select an expiration time in seconds, measured from 196 the instant the transport parameter is first sent. This time SHOULD 197 be less than the time until the server expects to support new QUIC 198 versions, rotate the keys used to encode information in the version 199 number, or rotate the keys use in salt generation. 201 Furthermore, the expiration time SHOULD be short enough to frustrate 202 a seed polling attack Section 7.3. 204 Conversely, an extremely short expiration time will often force the 205 client to use standard QUIC version numbers and salts. 207 3.4. Format 209 This document defines a new transport parameter extension for QUIC 210 with identifier 0x5641. The contents of the value field are 211 indicated below. 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Version (32) | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | | 219 + + 220 | | 221 + + 222 | Salt (160) | 223 + + 224 | | 225 + + 226 | | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Expiration (i) | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 1: Version Alias Transport Parameter value 233 The definition of the fields is described above. Note that the 234 "Expiration" field is in seconds, and its length is encoded using the 235 Variable Length Integer encoding from Section 16 of [QUIC-TRANSPORT]. 237 4. Client Behavior 239 When a client receives the Version Alias Transport Parameter, it MAY 240 cache the version number, salt, and the expiration of this value. It 241 MAY use the version number in a subsequent connection and compute the 242 initial keys using the provided salt. 244 Clients SHOULD NOT attempt to use the provided version number and 245 salt after the provided Expiration time has elapsed. 247 Clients SHOULD NOT use the provided version number or salt in more 248 than one connection, particularly if its IP address has changed 249 between two connection attempts. Using a consistent version number 250 can link the client across IP address changes. 252 Clients MUST use the same syntax version to format the Initial Packet 253 as the syntax version used in the connection that provided the 254 aliased version. 256 If the response to an Initial packet using the provided version is a 257 Version Negotiation Packet, the client SHOULD cease attempting to use 258 that version and salt to the server unless it later determines that 259 the packet was the result of a version downgrade, see Section 7.1. 261 5. Server Actions on Non-standard Version Numbers 263 When a server receives an Initial Packet with an unknown version 264 number, it SHOULD send a Version Negotiation Packet if it is 265 specifically configured not to generate that version number at 266 random. Otherwise, it derives a salt from the version number using 267 the algorithm and inputs it uses to generate salts to put in 268 transport parameters. 270 If the syntax version was encoded in the version number, the server 271 extracts it so that it can properly parse the packet. If not, it can 272 try trial parsing of the packet for each syntax version it supports. 274 If the computed seed results in a packet that fails authentication, 275 or the encoded syntax version is not supported at the server, or 276 trial parsing fails for all supported versions, the server SHOULD 277 send a Version Negotiation Packet. 279 Servers SHOULD provide a new Version Alias transport parameter, with 280 a new version number and salt, each time a client connects, to reduce 281 linkability for the client. However, issuing version numbers to a 282 client SHOULD be rate-limited to mitigate the seed polling attack 283 Section 7.3. 285 6. Considerations for Retry Packets 287 QUIC Retry packets reduce the load on servers during periods of 288 stress by forcing the client to prove it possesses the IP address 289 before the server decrypts any Initial Packets or establishing any 290 connection state. Version aliasing substantially complicates the 291 process. 293 If a server has to send a Retry packet, the required format is 294 ambiguous without understanding which syntax version to use. If all 295 supported syntax versions use the same Retry format, it simply uses 296 that format with the provided version number. 298 If the supported syntax versions use different Retry formats, the 299 server MUST either extract the syntax version from the version field 300 and format the Retry accordingly using the aliased version number, or 301 it MUST send a valid Retry packet for each supported version using 302 the syntax version number instead of the aliased version number. It 303 MUST NOT do both. 305 The Retry integrity Tag of a Retry Packet for an aliased version uses 306 the procedure in Section 5.8 of [QUIC-TLS]. However, the secret key 307 K uses the first 16 octets of the aliased salt instead of the key 308 provided in the specification. 310 Clients MUST accept Retry packets that contain either the aliased 311 version or syntax version. It MUST ignore Retry packets with other 312 syntax versions. It it receives Retry packets with both the aliased 313 version and the correct syntax version, it MUST discard the second 314 one it receives in accordance with section 17.2.5 of [QUIC-TRANSPORT] 315 unless the other one failed integrity validation. 317 After a client receives a Retry, it sends a new Initial Packet with 318 the provided Retry token. It MAY use the aliased version and salt or 319 the syntax version and salt, regardless of which type of Retry it 320 received. Note that if the server is not able to generate the 321 correct salt for an aliased version due to lost keys or other errors, 322 this might result in a Version Negotiation packet, which violates the 323 usual order of server responses (QUIC servers would normally send 324 Version Negotiation before Retry). 326 Clients that receive a Version Negotiation packet in response to an 327 Initial with a valid Retry token MAY interpret this to mean that the 328 server can no longer process the aliased version. They can retry the 329 connection with a syntax version number, but see Section 7.1. These 330 MUST include the Retry token so that the client can verify that the 331 Retry was authentic. 333 7. Security and Privacy Considerations 335 This document intends to improve the existing security and privacy 336 properties of QUIC by dramatically improving the secrecy of QUIC 337 Initial Packets. However, there are new attacks against this 338 mechanism. 340 7.1. Version Downgrade 342 A countermeasure against version aliasing is the downgrade attack. 343 Middleboxes may drop a packet containing a random version and imitate 344 the server's failure to correctly process it. Clients and servers 345 MUST implement the parts of [QUIC-VERSION-NEGOTIATION] relevant to 346 downgrade detection. 348 Note that downgrade detection only works after receiving a response 349 from the server. If a client immediately responds to a Version 350 Negotiation Packet with an Initial Packet with a syntax version 351 number, it will have exposed its request in a format readable to 352 observers before it discovers if the Version Negotiation Packet is 353 authentic. A client SHOULD wait for an interval to see if a valid 354 response comes from the server before assuming the version 355 negotiation is valid. The client MAY also alter its Initial Packet 356 (e.g., its ALPN field) to sanitize sensitive information and obtain 357 another aliased version before proceeding with its true request. 359 Servers that support version aliasing SHOULD be liberal about the 360 Initial Packet formats they receive, keeping the connection open long 361 enough to deliver their transport parameters, to support this 362 mechanism. 364 7.2. Increased Linkability 366 As each version number is theoretically unique to each client, if a 367 client uses one twice, those two connections are extremely likely to 368 be from the same host. If the client has changed IP address, this is 369 a significant increase in linkability relative to QUIC with a 370 standard version numbers. 372 7.3. Seed Polling Attack 374 Observers that wish to decode Initial Packets might open a large 375 number of connections to the server in an effort to obtain a large 376 portion of the mapping of version numbers to salts to a server. 377 While storage-intensive, this attack could increase the probability 378 that at least some version-aliased connections are observable. There 379 are two mitigations servers can execute against this attack: 381 o rate-limit transport parameters sent to a particular client; and/ 382 or 384 o set a low expiration time to reduce the lifetime of the attacker's 385 database. 387 Segmenting the version number space based on client information, i.e. 388 using only a subset of version numbers for a certain IP address 389 range, would significantly amplify an attack. Observers will 390 generally be on the path to the client and be able to mimic having an 391 identical IP address. Segmentation in this way would dramatically 392 reduce the search space for attackers. Thus, servers are prohibited 393 from using these mechanisms. 395 7.4. Increased Processing of Garbage UDP Packets 397 As QUIC shares the UDP protocol number with other UDP applications, 398 in some deployments it may be possible for traffic intended for other 399 UDP applications to arrive at a QUIC server endpoint. When servers 400 support a finite set of version numbers, a valid version number field 401 is a strong indicator the packet is, in fact, QUIC. If the version 402 number is invalid, a QUIC Version Negotiation is a low-cost response 403 that triggers very early in packet processing. 405 However, a server that provides version aliasing is prepared to 406 accept almost any version number. As a result, many more 407 sufficiently sized UDP payloads with the first bit set to '1' are 408 potential QUIC Initial Packets that require generation of a salt, 409 some initial connection state, and a decryption operation. 411 While not a more potent attack then simply sending valid Initial 412 Packets, servers may have to provision additional resources to 413 address this possibility. 415 7.5. Increased Retry Overhead 417 This document requires two small cryptographic operations to build a 418 Retry packet instead of one, placing more load on servers when 419 already under load. 421 8. IANA Considerations 423 This draft chooses a transport parameter (0x5641) to minimize the 424 risk of collision. IANA should assign a permanent value from the 425 QUIC Transport Parameter Registry. 427 9. References 429 9.1. Normative References 431 [QUIC-TLS] 432 Thomson, M., Ed. and S. Turner, Ed., "Using Transport 433 Layer Security (TLS) to Secure QUIC", draft-ietf-quic-tls- 434 latest (work in progress). 436 [QUIC-TRANSPORT] 437 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 438 Multiplexed and Secure Transport", draft-ietf-quic- 439 transport (work in progress). 441 [QUIC-VERSION-NEGOTIATION] 442 Schinazi, D., Ed. and E. Rescorla, Ed., "Compatible 443 Version Negotiation for QUIC", draft-ietf-quic-version- 444 negotiation-latest (work in progress). 446 9.2. Informative References 448 [ENCRYPTED-SNI] 449 Rescorla, E., Ed., Oku, K., Ed., Sullivan, N., Ed., and C. 450 Wood, Ed., "Encrypted Server Name Indication for TLS 1.3", 451 draft-ietf-tls-esni-latest (work in progress). 453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, 455 DOI 10.17487/RFC2119, March 1997, 456 . 458 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 459 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 460 . 462 Appendix A. Acknowledgments 464 Marten Seemann was the original progenitor of the version aliasing 465 approach. 467 Appendix B. Change Log 469 *RFC Editor's Note:* Please remove this section prior to 470 publication of a final version of this document. 472 B.1. since draft-duke-quic-version-aliasing-00 474 o Changed SNI Encryption to an Informative Reference 476 Author's Address 478 Martin Duke 479 F5 Networks, Inc. 481 Email: martin.h.duke@gmail.com