idnits 2.17.1 draft-duke-quic-protected-initial-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (27 April 2022) is 723 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-14 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-hpke (ref. 'HPKE') == Outdated reference: A later version (-14) exists of draft-ietf-quic-version-negotiation-07 == Outdated reference: A later version (-10) exists of draft-duke-quic-version-aliasing-07 Summary: 3 errors (**), 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 D. Schinazi 4 Intended status: Standards Track Google LLC 5 Expires: 29 October 2022 27 April 2022 7 Protected QUIC Initial Packets 8 draft-duke-quic-protected-initial-04 10 Abstract 12 QUIC encrypts its Initial Packets using keys derived from well-known 13 constants, meaning that observers can inspect the contents of these 14 packets and successfully spoof them. This document proposes a new 15 version of QUIC that encrypts Initial Packets more securely by 16 leveraging a Public Key distributed via the Domain Name System (DNS) 17 or other out-of-band system. 19 Discussion Venues 21 This note is to be removed before publishing as an RFC. 23 Discussion of this document takes place on the mailing list 24 (quic@ietf.org), which is archived at 25 https://mailarchive.ietf.org/arch/browse/quic/. 27 Source for this draft and an issue tracker can be found at 28 https://github.com/martinduke/quic-version-aliasing. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 29 October 2022. 47 Copyright Notice 49 Copyright (c) 2022 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Relationship to ECH and Version Aliasing . . . . . . . . 4 65 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Differences with QUIC Version 1 . . . . . . . . . . . . . . . 5 67 3.1. Version Number . . . . . . . . . . . . . . . . . . . . . 5 68 3.2. Key Configuration . . . . . . . . . . . . . . . . . . . . 5 69 3.3. Key Derivation Labels . . . . . . . . . . . . . . . . . . 5 70 3.4. Initial Packet Header . . . . . . . . . . . . . . . . . . 5 71 3.4.1. Encryption Context . . . . . . . . . . . . . . . . . 6 72 3.5. Client Packet Protection Procedure . . . . . . . . . . . 7 73 3.6. Server Packet Protection Procedure . . . . . . . . . . . 7 74 3.7. Retry Integrity Tag . . . . . . . . . . . . . . . . . . . 8 75 3.8. Fallback . . . . . . . . . . . . . . . . . . . . . . . . 8 76 3.9. The Fallback Packet . . . . . . . . . . . . . . . . . . . 10 77 3.10. New Transport Parameters . . . . . . . . . . . . . . . . 10 78 3.10.1. public_key_failed . . . . . . . . . . . . . . . . . 10 79 3.10.2. ECHConfig . . . . . . . . . . . . . . . . . . . . . 11 80 3.10.3. initial_encryption_context . . . . . . . . . . . . . 11 81 4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 12 82 4.1. Client-Facing Server . . . . . . . . . . . . . . . . . . 12 83 4.2. Back-End Server . . . . . . . . . . . . . . . . . . . . . 12 84 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13 85 6. Security and Privacy Considerations . . . . . . . . . . . . . 13 86 6.1. Forcing Downgrade . . . . . . . . . . . . . . . . . . . . 13 87 6.2. Initial Packet Injection . . . . . . . . . . . . . . . . 14 88 6.3. Retry Injection . . . . . . . . . . . . . . . . . . . . . 15 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 90 7.1. QUIC Version Registry . . . . . . . . . . . . . . . . . . 15 91 7.2. QUIC Transport Parameter Registry . . . . . . . . . . . . 16 92 7.3. QUIC Transport Error Codes Registry . . . . . . . . . . . 16 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 95 8.2. Informative References . . . . . . . . . . . . . . . . . 17 96 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 97 A.1. since draft-duke-quic-protected-initials-01 . . . . . . . 18 98 A.2. since draft-duke-quic-protected-initials-00 . . . . . . . 18 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 101 1. Introduction 103 DISCLAIMER: This draft is a preliminary proposal with insufficient 104 security analysis. It should not be used in production systems. 106 The QUIC Initial Packet [RFC9000] is encrypted using a key derived 107 from the Destination Connection ID in the packet cleartext and a 108 well-known salt (see Section 5.2 of [RFC9001]). Section 7 of that 109 draft describes security vulnerabilities resulting from the resulting 110 lack of authentication. 112 This also has privacy implications, as observers can decrypt the 113 packet and inspect the contents, which contain the TLS Client Hello 114 and Server Hello Messages ([RFC8446]). The former contains QUIC 115 Transport Parameters, which reveal even more information about the 116 traffic. 118 Furthermore, packets vulnerable to deep inspection create an 119 ossification vector. Intermediaries that expect the contents of 120 these messages to match a certain format and template might drop 121 packets that do not, preventing the use of new protocol extensions or 122 improved security protocols. 124 This document proposes a new version of QUIC where the client obtains 125 a public key generated by the server and uses it to encrypt a shared 126 secret, sent in the Initial packet header, that both endpoints can 127 then use to protect Initial packets. 129 This mechanism leverages the public key that would be distributed via 130 DNS (or other out-of-band mechanism) to support Encrypted Client 131 Hello [ECHO]. That design uses Hybrid Public Key Exchange (HPKE) 132 [HPKE] to authenticate some HPKE configuration information and the 133 "outer client hello" that is in plaintext, while encrypting the 134 "inner client hello" that contains privacy-sensitive information. 135 This document uses the widespread configuration that will exist if 136 ECHO is widely deployed, but only sends the subset of information 137 necessary to seed the QUIC key generation process. 139 1.1. Relationship to ECH and Version Aliasing 141 Encrypted Client Hello [ECHO] and QUIC Version Aliasing 142 [VERSION-ALIASING] also exist in the solution space of concealing 143 parts of the Initial packet exchange from observers. The following 144 table summarizes the advantages and disadvantages of each. 146 +===================+==============+=============+=============+ 147 | Property | ECH | Protected | Version | 148 | | | Initials | Aliasing | 149 +===================+==============+=============+=============+ 150 | Fields Protected | Some of | All Initial | All Initial | 151 | | Client Hello | Payloads | Payloads | 152 +-------------------+--------------+-------------+-------------+ 153 | Delay when server | 1 RTT | 2 RTT | 2 RTT | 154 | loses its keys | | | | 155 +-------------------+--------------+-------------+-------------+ 156 | Works with TLS | Yes | No | No | 157 | over TCP | | | | 158 +-------------------+--------------+-------------+-------------+ 159 | First-connection | Yes | Yes | No | 160 | protection | | | | 161 +-------------------+--------------+-------------+-------------+ 162 | Prevents Initial | No | Yes | Yes | 163 | packet injection | | | | 164 | attacks | | | | 165 +-------------------+--------------+-------------+-------------+ 166 | Symmetric | No | No | Yes | 167 | Encryption Only | | | | 168 +-------------------+--------------+-------------+-------------+ 169 | Greases the | No | No | Yes | 170 | Version Field | | | | 171 +-------------------+--------------+-------------+-------------+ 172 | Prevents Retry | No | No | Yes | 173 | injection attacks | | | | 174 +-------------------+--------------+-------------+-------------+ 175 | No trial | No | No | Yes | 176 | decryption | | | | 177 +-------------------+--------------+-------------+-------------+ 179 Table 1 181 The more complex properties in the table are discussed in Section 6. 183 Both ECH and Protected Initials are complimentary with Version 184 Aliasing: they provide a computationally expensive way to protect 185 parts of the Initial packet during the first connection between 186 client and server, after which Version Aliasing can protect future 187 exchanges with several additional desirable properties. 189 2. Conventions 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in RFC 2119 [RFC2119]. 195 3. Differences with QUIC Version 1 197 The version of QUIC described in this specification is identical to 198 QUIC version 1 [RFC9000] except where described in this document. 200 3.1. Version Number 202 The version field in long headers is TBD. Note: for interoperability 203 exercises, use the provisional value 0xff454900. 205 3.2. Key Configuration 207 The client obtains the Encrypted ClientHello Configuration 208 (ECHConfig) described in Section 4 of [ECHO], which provides the 209 context that allows protection of Initial packets. The ECHConfig is 210 available via a DNS record or other out-of- band system. 212 3.3. Key Derivation Labels 214 The labels used to derive keying material in [RFC9001] change from 215 "quic key", "quic iv", "quic hp", and "quic ku" to "quicpi key", 216 "quicpi iv", "quicpi hp", and "quicpi ku", respectively. 218 3.4. Initial Packet Header 220 The figure below is presented in the format from [RFC9000], and adds 221 a variable-length Encryption Context preceded by a length field: 223 Initial Packet { 224 Header From (1) = 1, 225 Fixed Big (1) = 1, 226 Long Packet Type (2) = 0, 227 Reserved Bits (2), 228 Packet Number Length (2), 229 Version (32), 230 Destination Connection ID Length (8), 231 Destination Connection ID (0..160), 232 Source Connection ID Length (8), 233 Source Connection ID (0..160), 234 Token Length (i), 235 Token (..), 236 Encryption Context Length (8), 237 Encryption Context (..), 238 Length (i), 239 Packet Number (8..32), 240 } 242 Encryption Context Length: A variable-length integer specifying the 243 length of the encryption context, in bytes. Servers MUST set this 244 field to zero; a client that receives a non-zero length MUST either 245 discard the packet or generate a connection error of type 246 PROTOCOL_VIOLATION. 248 Clients MUST include a nonzero Encryption Context Length in all 249 Initial packets, unless executing fallback procedures (see 250 Section 3.8). 252 When the client includes a non-zero-length Encryption Context, it 253 MUST include an initial_encryption_context in its Client Hello, so 254 that this header field is included in the TLS handshake transcript. 256 3.4.1. Encryption Context 258 The encryption context, if nonzero length, has the following format: 260 Encryption Context { 261 Config ID (8), 262 SCKDF (16), 263 SCAEADID (16), 264 Encapsulated Secret (..), 265 } 267 Config ID: An 8-bit integer identifying the configuration parameters, 268 obtained from the ECHConfig. This ID implicitly identifies the 269 public key, Key Encapsulation Mechanism, and the set of symmetric 270 suites from which the following fields are selected. 272 SCKDF: Symmetric Cipher Key Derivation Function. The client selects 273 this from the cipher suites listed in the ECHConfig. This is the 274 cipher used to encrypt the Initial Packet. The values are listed in 275 Section 7.2 of [HPKE]. All endpoints MUST support HKDF-SHA256 276 (0x0001), which is used for QUIC Version 1 Initial packets. 278 SCAEADID: Symmetric Cipher Key Derivation Function. The client 279 selects this from the cipher suites listed in the ECHConfig. This is 280 the cipher used to encrypt the Initial Packet. The values are listed 281 in Section 7.3 of [HPKE]. All endpoints MUST support AES-128-GCM 282 (0x0001), which is used for QUIC Version 1 Initial packets. 284 The Encapsulated Secret is HPKE encapsulated. Its length is inferred 285 from the Encryption Context Length field. 287 3.5. Client Packet Protection Procedure 289 An client extracts the public key pkR and uses it to generate a 290 shared_secret: 292 pkR = Deserialize(ECHConfig.contents.public_key) 293 shared_secret, enc = Encap(pkR) 294 initial_secret = HKDF-Extract(shared_secret, 295 client_dst_connection_id || ECHConfig) 297 enc is the Encapsulated Secret, and is written into that subfield of 298 the Encryption Context Field. 300 The initial_secret above is used to generate client_initial_secret 301 and server_initial_secret as described in Section 5.2 of [RFC9001]. 303 When applying header protection, the Context Length and Encryption 304 Context are not Protected. 306 This derivation is performed once per connection. Subsequent Initial 307 Packets use the same keys and the same offset to the packet number, 308 regardless of additional Encryption Context fields or changed 309 connection IDs. 311 3.6. Server Packet Protection Procedure 313 The server reads the Config ID and Encapsulated Secret (enc) from the 314 Initial Packet. It looks up its private key (skR) associated with 315 the Config ID. 317 Otherwise, the server generates the Initial secrets: 319 shared_secret = Decap(enc, skR) 320 initial_secret = HKDF-Extract(shared_secret, 321 client_dst_connection_id || ECHConfig) 323 The remainder is identical to the client procedure. All server- 324 generated Initial packets use the keys generated in this process. 326 If packet decryption fails, see Section 3.8. 328 The server terminates the connection with a TRANSPORT_PARAMETER_ERROR 329 under the following conditions: 331 * There is a zero-length Encryption Context field, but the 332 initial_encryption_context transport parameter is present 334 * There is a non-zero-length Encryption Context field, but the 335 initial_encryption_context transport parameter is absent or does 336 not match the header. 338 However, see Section 4 for exceptions to this transport parameter 339 processing rule. 341 3.7. Retry Integrity Tag 343 The Retry packet is identical to QUIC version 1, except that the key 344 and nonce used for the Retry Integrity Tag (Sec 5.8 of [RFC9001] 345 change to: 347 secret = 0xe453a2e22377289f08a4458ee1c9a90a4e39696e026372ffc33190b8de5a0123 348 key = 0xbe0c690b9f66575a1d766b54e368c84e 349 nonce = 0x461599d35d632bf2239825bb 351 This key and nonce are also used in Fallback packets (Section 3.9). 353 3.8. Fallback 355 If decryption fails, the client may not have the server's correct 356 configuration. In this case, the server replies with a Fallback 357 packet (see Section 3.9), and discards the Initial. 359 The client checks the Integrity Tag in the packet against the 360 received Fallback Packet and its own record of the Initial Packet. 361 If they do not match, the packet may have been corrupted, and the 362 client SHOULD treat the packet as lost. If they do match, the client 363 MUST assume that it does not have the correct ECHConfig. 365 When it has the incorrect config, the client composes a new Client 366 Hello. It MUST include the public_key_failed transport parameter 367 with the Config ID and public key it attempted to use. It MUST use 368 an Encryption Context Length of zero, and encrypt it with keys 369 derived from the "fallback salt" 370 0xbd62319ad6eeb17a9ed0d3bf75e37e4a8e7e6ac7, instead of the shared 371 secret that the server cannot decode. The Client Hello also MUST 372 include any Retry Token the previous Initial contained and MAY 373 include a token from a NEW_TOKEN frame. 375 This new Initial packet is part of the same connection and MUST use 376 the same Connection IDs and packet number space. 378 Note that the fallback salt does not provide confidentiality to the 379 client, and the client SHOULD NOT include privacy-sensitive 380 information there. See Section 6.1 for further discussion of this. 382 A server interprets a client Initial with a zero-length Encryption 383 Context as an Initial encrypted with keys derived from the fallback 384 salt and decrypts it accordingly. 386 The server checks the Config ID and public key from the 387 public_key_failed transport parameter to see if it should 388 successfully process a Protected Initial with these parameters. If 389 it would have, it MUST terminate the connection with an 390 INVALID_PROTECTED_INITIAL_DOWNGRADE error to indicate that there has 391 been an attack. 393 If the server would not have successfully decoded the packet with 394 those parameters, it MUST send its own public_key_failed transport 395 parameter to acknowledge the parameter was successfully processed. 396 It MAY also send a ECHConfig transport parameter to allow use of 397 Protected Initials in subsequent connections, a Version Aliasing 398 transport parameter (see [VERSION-ALIASING]) to enable a different 399 means of Initial Protection, both, or neither. 401 If the client does not receive a public_key_failed transport 402 parameter in response to sending a public_key_failed transport 403 parameter, it MUST terminate the connection with a 404 TRANSPORT_PARAMETER_ERROR. 406 The client MUST NOT include the original client hello in its TLS 407 transcript hash for key computation, as the server has no access to 408 this message. However, the client hello is an input to the Integrity 409 tag in the public_key_failed transport parameter, which will be in 410 the transcript. 412 If any part of the client hello changes (e.g the SNI or ALPN), the 413 client MUST NOT include a resumption ticket or send 0-RTT packets. 415 3.9. The Fallback Packet 417 The Fallback packet uses the 0x1 packet type code, which it shares 418 with 0-RTT. Since 0-RTT is only sent by clients and Fallback is only 419 sent by servers, these two types are distinguished by the endpoint's 420 role in the handshake. 422 The Fallback packet has the following format: 424 Fallback Packet { 425 Header Form (1) = 1, 426 Fixed Bit (1) = 1, 427 Long Packet Type (2) = 1, 428 Unused (4), 429 Version (32), 430 Destination Connection ID Length (8), 431 Destination Connection ID (0..160), 432 Source Connection ID Length (8), 433 Source Connection ID (0..160), 434 Integrity Tag (128), 435 } 437 The server computes the Integrity Tag by prepending the entire UDP 438 payload that contained the client Initial to the Fallback packet 439 contents (minus the tag itself, of course) to form a pseudo-packet. 440 The server then computes the Integrity Tag as the output of 441 AEAD_AES_128_GCM with the key and nonce from Section 3.7, no 442 plaintext, and the pseudo-packet as the Additional Data. This thus 443 confirms the integrity of both packets in the exchange. 445 3.10. New Transport Parameters 447 3.10.1. public_key_failed 449 The public_key_failed transport parameter allows detection of an 450 attacker injecting messages to force use of the fallback salt. For 451 details on use, see Section 3.8. 453 Its provisional type is 0x706b66. 455 When sent by a client, the content of the transport parameter is as 456 follows: 458 { 459 Integrity Tag (128), 460 Config ID (8), 461 Public Key (..), 462 } 464 The Integrity Tag is copied from the Fallback packet. 466 The other fields are populated using the ECHConfig that the client 467 attempted to use. The length of the Public Key is inferred from the 468 length field of the transport parameter. 470 When sent by a server, the transport parameter has no value field. 472 Endpoints MUST respond to a malformed transport parameter by closing 473 the connection with a TRANSPORT_PARAMETER_ERROR. 475 Note that this transport parameter is always sent as a result of a 476 fallback from a Protected Initial, and therefore with a zero-length 477 Encryption Context in the packet header. Therefore, if received with 478 non-zero-length Encryption Context, the receiving endpoint MUST 479 terminate the connection with a TRANSPORT_PARAMETER_ERROR. 481 3.10.2. ECHConfig 483 The ECHConfig transport parameter allows servers to directly provide 484 clients a valid configuration. 486 Its provisional type is 0x454348. 488 Its format is equivalent to ECHConfigList, as defined in Section 4 of 489 [ECHO]. 491 If this transport parameter does not match this format, is received 492 by a server, or is received in a connection where the client's most 493 recent Initial had a non-zero-length Encryption Context, the receiver 494 MUST terminate the connection with a TRANSPORT_PARAMETER_ERROR. 496 3.10.3. initial_encryption_context 498 The format of this transport parameter is identical to the Encryption 499 Context described in Section 3.4.1. 501 Its provisional type is 0x696563. 503 4. Intermediaries 505 In the topology proposed in Section 3.1 of [ECHO], where a client- 506 facing server has its own public name and potentially fronts a number 507 of independent domains, only the client-facing server has the private 508 keys. Thus, it modifies incoming Initial Packets before forwarding 509 to the back-end server. 511 A common use case of this topology is a load balancer fronting 512 multiple domains using the same IP address, which makes routing 513 decisions based on the SNI in the Client Hello. 515 4.1. Client-Facing Server 517 The client-facing server is responsible for verifying the Initial 518 packet is decryptable, sending a Fallback packet (and dropping the 519 Initial) if it is not, and otherwise forwarding the packet encrypted 520 with a different key. 522 If an incoming Initial packet is not decryptable, the client-facing 523 server sends a Fallback packet and drops the Initial. 525 If an incoming client Initial has a non-zero length Encryption 526 Context field, the client-facing server MUST delete the Encryption 527 Context field. When forwarding to the back-end server, it encrypts 528 the plaintext version of this modified packet with keys derived from 529 the fallback salt. Thus, between client-facing server and back-end 530 server the packet is inspectable by observers. 532 Similarly, if the client is using the shared secret, the client- 533 facing server MUST decrypt server Initial packets encrypted with keys 534 derived from the fallback secret, and re-encrypt them with keys 535 derived from the shared secret. 537 The client-facing server MUST enforce correct use of the 538 initial_encryption_context parameter, as described in Section 3.6, 539 and terminate the connection if necessary. 541 Non-Initial packets pass unmodified through the client-facing server. 542 Note that client-facing servers cannot inspect any packet payloads 543 except for Initial packets. 545 4.2. Back-End Server 547 Back-end servers MUST have an up-to-date copy of the ECHConfigList 548 the client- facing server is using, though it need not hold the 549 private key, in order to properly process and generate the relevant 550 transport parameters. 552 Back-end servers MUST NOT take any action based on the presence or 553 contents of the initial_encryption_context transport parameter, as 554 the client-facing server has likely stripped the Encryption Context 555 out of the header. 557 In all other respects, they operate as Protected Initial servers. 559 5. Applicability 561 This version of QUIC provides no change from QUIC version 1 relating 562 to the capabilities available to applications. Therefore, all 563 Application Layer Protocol Negotiation (ALPN) ([RFC7301]) codepoints 564 specified to operate over QUICv1 can also operate over this version 565 of QUIC. 567 6. Security and Privacy Considerations 569 Sections 10.2, 10.3, 10.4, and 10.6 of [ECHO] apply to QUIC Protected 570 Initials as well. 572 Section 7.8 of [VERSION-ALIASING] is also applicable. 574 6.1. Forcing Downgrade 576 An attacker attempts to force a client to send an Initial that uses 577 unprotected Initials by injecting a Version Negotiation packet (which 578 implies the server no longer supports Protected Initials) or a 579 Fallback packet (which implies the server has a new cryptographic 580 context). 582 The weak form of this attack observes the Initial and injects the 583 Version Negotiation or Fallback packet, but cannot drop the Initial. 584 To counteract this, a client SHOULD NOT respond to these packets 585 until they have waited for Probe Timeout (PTO) for a valid server 586 Initial to arrive. 588 The strong form features an attacker that can drop Initial packets. 589 In this case, the client can either abandon the connection attempt or 590 connect with a unprotected Initial: using the fallback salt in 591 response to a Fallback packet, or a different version in response to 592 Version Negotiation. 594 If connecting with an unprotected Initial, the client MAY alter it to 595 sanitize sensitive information and obtain either a correct ECHConfig 596 or an aliased version before proceeding with its true connection 597 attempt. However, the client Initial MUST lead to the authentication 598 of a domain name the client trusts to provide accurate cryptographic 599 information (usually the public_name from the ECHConfig). Advice for 600 the Outer ClientHello in Section 10.5 of [ECHO] applies here. 602 Furthermore, if it received a Fallback packet, the client sends a 603 public_key_failed transport parameter to detect the downgrade attack, 604 and the server will terminate the connection if the Fallback packet 605 was an attack. 607 If the client received a Version Negotiation packet, it MUST 608 implement a downgrade detection mechanism such as 609 [I-D.ietf-quic-version-negotiation] or abandon the connection 610 attempt. If it subsequently detects a downgrade detection, or 611 discovers that the server does not support the same mechanism, it 612 terminates the connection attempt. 614 Note that ECH is able to retrieve an up-to-date cryptographic context 615 in 1 RTT, because the client hello has enough plaintext information 616 to begin a handshake with the public_name. Protected Initials 617 require reconnection with the public name, incurring a 2 RTT penalty 618 to achieve the same result. 620 6.2. Initial Packet Injection 622 QUIC version 1 handshakes are vulnerable to DoS from observers for 623 the short interval that endpoints keep Initial keys (usually ~1.5 624 RTTS), since Initial Packets are not authenticated. With version 625 aliasing, attackers do not have the necessary keys to launch such an 626 attack. 628 QUIC version 1 can use a fixed symmetric cipher for its Initial 629 Packets because the encryption is not providing true security. As 630 this design aspires to stonger guarantees, the Encryption Context 631 field of the Initial header provides the codepoints to enable use of 632 other symmetric ciphers should AES-128-GCM be compromised in the 633 future. This is to provide cryptographic agility in accordance with 634 [RFC7696]. 636 6.3. Retry Injection 638 This version of QUIC does not improve the security of Retry packets 639 with respect to QUIC version 1. The Retry Integrity Tag uses a well- 640 known key and relies on data in the Initial that triggered the Retry. 641 It therefore protects against transmission errors and injection of 642 Retry packets by off-path attackers that cannot observe the Initial. 643 To detect Retry packets injected by observers, it relies on the 644 subsequent exchange of transport parameters. 646 An attacker that consistently injects Retry packets in front of a 647 server that also consistently sends Retry can result in a Denial of 648 Service, as clients cannot accept two Retries in the same connection. 650 An alternate design would use the shared secret derived from the 651 Client Initial Packet to generate keys for the Retry Integrity Tag, 652 which would allow the client to immediately discard Retries injected 653 by other parties. Unfortunately, this would require servers to 654 perform an asymmetric crypto operation to send a Retry packet, when 655 in a state where it is likely computationally limited. 657 It is possible to enhance the security of Retry by assuming this 658 added computational cost. Such a design could also eliminate the 659 complexity associated with adding an arbitrary value to the Packet 660 Length field. The purpose of this addition is to avoid trial 661 decryption to verify the configuration is correct, but this cost is 662 negligible compared to extracting the shared secret. 664 7. IANA Considerations 666 7.1. QUIC Version Registry 668 This document requests that IANA add the following entry to the QUIC 669 version registry: 671 Value: TBD 673 Status: permanent 675 Specification: This document 677 Change Controller: IETF 679 Contact: QUIC WG 681 7.2. QUIC Transport Parameter Registry 683 This document requests that IANA add the following three entries to 684 the QUIC Transport Parameters registry: 686 +=======+============================+===============+ 687 | Value | Parameter Name | Specification | 688 +=======+============================+===============+ 689 | TBD | public_key_failed | This document | 690 +-------+----------------------------+---------------+ 691 | TBD | ECHConfig | This document | 692 +-------+----------------------------+---------------+ 693 | TBD | initial_encryption_context | This document | 694 +-------+----------------------------+---------------+ 696 Table 2 698 7.3. QUIC Transport Error Codes Registry 700 This document requests that IANA add the following entry to the QUIC 701 Transport Error Codes registry: 703 Value: TBD 705 Code: INVALID_PROTECTED_INITIAL_DOWNGRADE 707 Description: Attacker is forcing insecure Initial 709 Specification: This document 711 8. References 713 8.1. Normative References 715 [ECHO] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 716 Encrypted Client Hello", Work in Progress, Internet-Draft, 717 draft-ietf-tls-esni-14, 13 February 2022, 718 . 721 [HPKE] Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 722 "Hybrid Public Key Encryption", Work in Progress, 723 Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021, 724 . 727 [I-D.ietf-quic-version-negotiation] 728 Schinazi, D. and E. Rescorla, "Compatible Version 729 Negotiation for QUIC", Work in Progress, Internet-Draft, 730 draft-ietf-quic-version-negotiation-07, 5 April 2022, 731 . 734 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 735 Multiplexed and Secure Transport", RFC 9000, 736 DOI 10.17487/RFC9000, May 2021, 737 . 739 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 740 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 741 . 743 8.2. Informative References 745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 746 Requirement Levels", BCP 14, RFC 2119, 747 DOI 10.17487/RFC2119, March 1997, 748 . 750 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 751 "Transport Layer Security (TLS) Application-Layer Protocol 752 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 753 July 2014, . 755 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 756 Agility and Selecting Mandatory-to-Implement Algorithms", 757 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 758 . 760 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 761 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 762 . 764 [VERSION-ALIASING] 765 Duke, M., "QUIC Version Aliasing", Work in Progress, 766 Internet-Draft, draft-duke-quic-version-aliasing-07, 25 767 October 2021, . 770 Appendix A. Change Log 772 *RFC Editor's Note:* Please remove this section prior to 773 publication of a final version of this document. 775 A.1. since draft-duke-quic-protected-initials-01 777 * Redesigned fallback again without Version Negotiation 779 * Added the initial_encryption_context transport parameter 781 A.2. since draft-duke-quic-protected-initials-00 783 * Additional text comparing ECH, Version Aliasing 785 * Adapted to foreground the split-mode use case 787 * Clarified server initials are encrypted 789 * Retry keys are no longer generated from the shared secret 791 * Complete Rewrite of Fallback 793 * New transport parameters 795 * Added crypto agility 797 Authors' Addresses 799 Martin Duke 800 Google LLC 801 Email: martin.h.duke@gmail.com 803 David Schinazi 804 Google LLC 805 1600 Amphitheatre Parkway 806 Mountain View, California 94043, 807 United States of America 808 Email: dschinazi.ietf@gmail.com