idnits 2.17.1 draft-duke-quic-protected-initial-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 (7 May 2021) is 1085 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-10 == Outdated reference: A later version (-12) exists of draft-irtf-cfrg-hpke-08 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-hpke (ref. 'HPKE') -- Duplicate reference: draft-ietf-quic-tls, mentioned in 'QUIC-TLS', was also mentioned in 'I-D.ietf-quic-tls'. == Outdated reference: A later version (-14) exists of draft-ietf-quic-version-negotiation-03 == Outdated reference: A later version (-10) exists of draft-duke-quic-version-aliasing-04 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 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: Standards Track 7 May 2021 5 Expires: 8 November 2021 7 Protected QUIC Initial Packets 8 draft-duke-quic-protected-initial-01 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 of this work is encouraged to happen on the QUIC IETF 20 mailing list quic@ietf.org or on the GitHub repository which contains 21 the draft: https://github.com/martinduke/quic-version-aliasing. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 8 November 2021. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Relationship to ECH and Version Aliasing . . . . . . . . 3 58 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Key Configuration . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Version Number . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Key Derivation Labels . . . . . . . . . . . . . . . . . . . . 5 62 6. Initial Packet Header . . . . . . . . . . . . . . . . . . . . 5 63 6.1. Encryption Context . . . . . . . . . . . . . . . . . . . 6 64 7. Client Packet Protection Procedure . . . . . . . . . . . . . 6 65 8. Server Packet Protection Procedure . . . . . . . . . . . . . 7 66 9. Retry Integrity Tag . . . . . . . . . . . . . . . . . . . . . 8 67 10. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 11. New Transport Parameters . . . . . . . . . . . . . . . . . . 9 69 11.1. public_key_failed . . . . . . . . . . . . . . . . . . . 9 70 11.2. ECHConfig . . . . . . . . . . . . . . . . . . . . . . . 10 71 12. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 10 72 12.1. Client-Facing Server . . . . . . . . . . . . . . . . . . 10 73 12.2. Back-End Server . . . . . . . . . . . . . . . . . . . . 11 74 13. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 11 75 14. Security and Privacy Considerations . . . . . . . . . . . . . 11 76 14.1. Key Loss and Version Downgrade . . . . . . . . . . . . . 11 77 14.2. Initial Packet Injection . . . . . . . . . . . . . . . . 13 78 14.3. Retry Injection . . . . . . . . . . . . . . . . . . . . 13 79 14.4. Less Trial Decryption . . . . . . . . . . . . . . . . . 14 80 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 15.1. QUIC Version Registry . . . . . . . . . . . . . . . . . 14 82 15.2. QUIC Transport Parameter Registry . . . . . . . . . . . 14 83 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 16.1. Normative References . . . . . . . . . . . . . . . . . . 15 85 16.2. Informative References . . . . . . . . . . . . . . . . . 15 86 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16 87 A.1. since draft-duke-quic-protected-initials-00 . . . . . . . 16 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 90 1. Introduction 92 DISCLAIMER: This draft is a preliminary proposal with insufficient 93 security analysis. It should not be used in production systems. 95 The QUIC Initial Packet [QUIC-TRANSPORT] is encrypted using a key 96 derived from the Destination Connection ID in the packet cleartext 97 and a well-known salt (see Section 5.2 of [QUIC-TLS]). Section 7 of 98 that draft describes security vulnerabilities resulting from the 99 resulting lack of authentication. 101 This also has privacy implications, as observers can decrypt the 102 packet and inspect the contents, which contain the TLS Client Hello 103 and Server Hello Messages ([RFC8446]). The former contains QUIC 104 Transport Parameters, which reveal even more information about the 105 traffic. 107 Furthermore, packets vulnerable to deep inspection create an 108 ossification vector. Intermediaries that expect the contents of 109 these messages to match a certain format and template might drop 110 packets that do not, preventing the use of new protocol extensions or 111 improved security protocols. 113 This document proposes a new version of QUIC where the client obtains 114 a public key generated by the server and uses it to encrypt a shared 115 secret, sent in the Initial packet header, that both endpoints can 116 then use to protect Initial packets. 118 This mechanism leverages the public key that would be distributed via 119 DNS (or other out-of-band mechanism) to support Encrypted Client 120 Hello [ECHO]. That design uses Hybrid Public Key Exchange (HPKE) 121 ([HPKE] to authenticate some HPKE configuration information and the 122 "outer client hello" that is in plaintext, while encrypting the 123 "inner client hello" that contains privacy-sensitive information. 124 This document uses the widespread configuration that will exist if 125 ECHO is widely deployed, but only sends the subset of information 126 necessary to seed the QUIC key generation process. 128 The version of QUIC described in this specification is identical to 129 QUIC version 1 [QUIC-TRANSPORT] except where described in this 130 document. 132 1.1. Relationship to ECH and Version Aliasing 134 Encrypted Client Hello [ECHO] and QUIC Version Aliasing 135 [VERSION-ALIASING] also exist in the solution space of concealing 136 parts of the Initial packet exchange from observers. The following 137 table summarizes the advantages and disadvantages of each. 139 +===================+==============+=============+=============+ 140 | Property | ECH | Protected | Version | 141 | | | Initials | Aliasing | 142 +===================+==============+=============+=============+ 143 | Fields Protected | Some of | All Initial | All Initial | 144 | | Client Hello | Payloads | Payloads | 145 +-------------------+--------------+-------------+-------------+ 146 | Delay when server | 1 RTT | 2 RTT | 2 RTT | 147 | loses its keys | | | | 148 +-------------------+--------------+-------------+-------------+ 149 | Works with TLS | Yes | No | No | 150 | over TCP | | | | 151 +-------------------+--------------+-------------+-------------+ 152 | First-connection | Yes | Yes | No | 153 | protection | | | | 154 +-------------------+--------------+-------------+-------------+ 155 | No trial | No | Yes | Yes | 156 | decryption | | | | 157 +-------------------+--------------+-------------+-------------+ 158 | Prevents Initial | No | Yes | Yes | 159 | packet injection | | | | 160 | attacks | | | | 161 +-------------------+--------------+-------------+-------------+ 162 | Symmetric | No | No | Yes | 163 | Encryption Only | | | | 164 +-------------------+--------------+-------------+-------------+ 165 | Greases the | No | No | Yes | 166 | Version Field | | | | 167 +-------------------+--------------+-------------+-------------+ 168 | Prevents Retry | No | No | Yes | 169 | injection attacks | | | | 170 +-------------------+--------------+-------------+-------------+ 172 Table 1 174 The more complex properties in the table are discussed in Section 14. 176 Both ECH and Protected Initials are complimentary with Version 177 Aliasing: they provide a computationally expensive way to protect 178 parts of the Initial packet during the first connection between 179 client and server, after which Version Aliasing can protect future 180 exchanges with several additional desirable properties. 182 2. Conventions 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in RFC 2119 [RFC2119]. 188 3. Key Configuration 190 The client obtains the Encrypted ClientHello Configuration 191 (ECHConfig) described in Section 4 of [ECHO], which provides the 192 context that allows protection of Initial packets. The ECHConfig is 193 available via a DNS record or other out-of- band system. 195 4. Version Number 197 The version field in long headers is TBD. Note: for interoperability 198 exercises, use the provisional value 0xff454900. 200 5. Key Derivation Labels 202 The labels used to derive keying material in [QUIC-TLS] change from 203 "quic key", "quic iv", "quic hp", and "quic ku" to "quicpi key", 204 "quicpi iv", "quicpi hp", and "quicpi ku", respectively. 206 6. Initial Packet Header 208 The figure below is presented in the format from [QUIC-TRANSPORT], 209 and adds a variable-length Encryption Context preceded by a length 210 field: 212 Initial Packet { 213 Header From (1) = 1, 214 Fixed Big (1) = 1, 215 Long Packet Type (2) = 0, 216 Reserved Bits (2), 217 Packet Number Length (2), 218 Version (32), 219 Destination Connection ID Length (8), 220 Destination Connection ID (0..160), 221 Source Connection ID Length (8), 222 Source Connection ID (0..160), 223 Encryption Context Length (8), 224 Encryption Context (..), 225 Token Length (i), 226 Token (..), 227 Length (i), 228 Packet Number (8..32), 229 } 231 Encryption Context Length: A variable-length integer specifying the 232 length of the encryption context, in bytes. Servers MUST set this 233 field to zero; a client that receives a non-zero length MUST either 234 discard the packet or generate a connection error of type 235 PROTOCOL_VIOLATION. 237 If a client has received a valid Server Initial packet, it SHOULD set 238 this field to zero. Until then, clients MUST use a nonzero value. 239 If a client Initial packet has a zero Encryption Context Length, and 240 the server has not sent an Initial Packet, the server MUST either 241 discard the packet or generate a connection error of type 242 PROTOCOL_VIOLATION. 244 6.1. Encryption Context 246 The encryption context, if nonzero length, has the following format: 248 Encryption Context { 249 Config ID (8), 250 SCKDF (16), 251 SCAEADID (16), 252 Encapsulated Secret (..), 253 } 255 Config ID: An 8-bit integer identifying the configuration parameters, 256 obtained from the ECHConfig. This ID implicitly identifies the 257 public key, Key Encapsulation Mechanism, and the set of symmetric 258 suites from which the following fields are selected. 260 SCKDF: Symmetric Cipher Key Derivation Function. The client selects 261 this from the cipher suites listed in the ECHConfig. This is the 262 cipher used to encrypt the Initial Packet. The values are listed in 263 Section 7.2 of [HPKE]. All endpoints MUST support HKDF-SHA256 264 (0x0001), which is used for QUIC Version 1 Initial packets. 266 SCAEADID: Symmetric Cipher Key Derivation Function. The client 267 selects this from the cipher suites listed in the ECHConfig. This is 268 the cipher used to encrypt the Initial Packet. The values are listed 269 in Section 7.3 of [HPKE]. all endpoints MUST support AES-128-GCM 270 (0x0001), which is used for QUIC Version 1 Initial packets. 272 The Encapsulated Secret is HPKE encapsulated. Its length is inferred 273 from the Encryption Context Length field. 275 7. Client Packet Protection Procedure 277 An client extracts the public key pkR and uses it to generate a 278 shared_secret: 280 pkR = Deserialize(ECHConfig.contents.public_key) 281 shared_secret, enc = Encap(pkR) 282 initial_secret = HKDF-Extract(shared_secret, 283 client_dst_connection_id || ECHConfig) 285 enc is the Encapsulated Secret, and is written into that subfield of 286 the Encryption Context Field. 288 The initial_secret above is used to generate client_initial_secret 289 and server_initial_secret as described in Section 5.2 of [QUIC-TLS]. 291 When applying header protection, the Context Length and Encryption 292 Context are not Protected. 294 Additionally, the client bitwise-XORs the first eight octets of the 295 Destination Connection ID with the first eight octets of the public 296 key to form a 64 bit unsigned integer. This integer is added to the 297 packet length, modulo 2^62, and written into the packet length field 298 instead of the actual packet length. 300 This derivation is performed once per connection. Subsequent Initial 301 Packets use the same keys and the same offset to the packet number, 302 regardless of additional Encryption Context fields or changed 303 connection IDs. 305 8. Server Packet Protection Procedure 307 The server reads the Config ID and Encapsulated Secret (enc) from the 308 Initial Packet. It looks up its private key (skR) associated with 309 the Config ID. 311 Prior to any other operations, including sending any Retry packet, 312 the server bitwise-XORs the first eight octets of its public key and 313 the destination connection ID and subtracts this from the value in 314 the packet length field, modulo 2^62, to find the true packet length. 316 Any result that exceeds the size of the received datagram indicates 317 with high assurance that the client's received ECHConfig does not 318 match the server's state, possibly due to a misconfiguration. The 319 probability this test results in a false negative, when an incorrect 320 key generates a result less than the datagram size, is typically less 321 than 1 in 2^51. The server MUST discard the packet and SHOULD send a 322 Version Negotiation packet (see Section 10). 324 Otherwise, the server generates the Initial secrets: 326 shared_secret = Decap(enc, skR) 327 initial_secret = HKDF-Extract(shared_secret, 328 client_dst_connection_id || ECHConfig) 330 The server now has sufficient context to send a Retry packet and MAY 331 choose to do so at this point (see Section 9). If not, it decrypts 332 the Initial packet. 334 The remainder is identical to the client procedure. All server- 335 generated Initial packets use the keys generated in this process. 337 9. Retry Integrity Tag 339 The Retry packet is identical to QUIC version 1, except that the key 340 and nonce used for the Retry Integrity Tag (Sec 5.8 of 341 [I-D.ietf-quic-tls] change to: 343 secret = 0xe453a2e22377289f08a4458ee1c9a90a4e39696e026372ffc33190b8de5a0123 344 key = 0xbe0c690b9f66575a1d766b54e368c84e 345 nonce = 0x461599d35d632bf2239825bb 347 10. Fallback 349 Endpoints that support QUIC Protected Initials MUST support at least 350 one other version of QUIC (in case the endpoints cannot agree on the 351 ECHConfig), and therefore MUST also support [QUIC-VN]. 353 Note that QUIC version 1 is not compatible with QUIC Protected 354 Initials, as it does not contain the information necessary to 355 generate subsequent Initial packets correctly. Conversely, QUIC 356 Protected Initials are compatible with QUIC version 1. However, 357 since the versions have identical properties after the Initial packet 358 exchange, there is little value in such a transition. 360 When decoding a client Initial packet length, the server may conclude 361 that the client does not have the server's correct configuration (see 362 Section 8). In this case, it SHOULD send a Version Negotiation 363 packet and that packet MUST include the version the client attempted 364 to connect with. This contradicts the usual semantics in Section 5 365 of [QUIC-VN], and clients that support Protected Initials MUST accept 366 these packets, as well as further transport parameters that advertise 367 support for Protected Initials. 369 Because of the vulnerabilities described in Section 14.1, additional 370 measures are required to protect against an attacker forcing version 371 downgrade. If the client chooses to attempt a reconnection, it MUST 372 choose a version listed in the Version Negotiation packet that does 373 not include Protected Initials. 375 When connecting with that version, the client MUST include the 376 public_key_failed transport parameter with the Config ID and public 377 key it attempted to use. 379 The server checks the Config ID and public key to see if it should 380 successfully process a Protected Initial with these parameters. If 381 it would have, it MUST terminate the connection with a 382 VERSION_NEGOTIATION_ERROR to indicate that there has been a downgrade 383 attack. 385 If the server would not have successfully decoded the packet with 386 those parameters, it MUST send its own public_key_failed transport 387 parameter to acknowledge the parameter was successfully processed. 388 It MAY also send a ECHConfig transport parameter to allow use of 389 Protected Initials in subsequent connections, a Version Aliasing 390 transport parameter (see [VERSION-ALIASING]) to enable a different 391 means of Initial Protection, both, or neither. 393 If the client does not receive a public_key_failed transport 394 parameter in response to sending a public_key_failed transport 395 parameter, it MUST terminate the connection with a 396 TRANSPORT_PARAMETER_ERROR. 398 11. New Transport Parameters 400 11.1. public_key_failed 402 The system to detect version downgrade in [QUIC-VN] is insufficient 403 to do so for Protection Initials (see Section 14.1). The 404 public_key_failed transport parameter solves this problem. For 405 details on use, see Section 10. 407 Its provisional type is 0x706b66. 409 When sent by a client, the content of the transport parameter is as 410 follows: 412 { 413 Config ID (8), 414 Public Key (..), 415 } 417 These fields are populated using the ECHConfig that the client 418 attempted to use. The length of the Public Key is inferred from the 419 length field of the transport parameter. 421 When sent by a server, the transport parameter has no value field. 423 Endpoints MUST respond to a malformed transport parameter by closing 424 the connection with a TRANSPORT_PARAMETER_ERROR. 426 Note that this transport parameter is always sent as a result of a 427 fallback from a Protected Initial, and therefore in a connection of a 428 different version. Therefore, if received in a Protected Initial 429 connection, the receiving endpoint MUST terminate the connection with 430 a TRANSPORT_PARAMETER_ERROR. 432 11.2. ECHConfig 434 The ECHConfig transport parameter allows servers to directly provide 435 clients a valid configuration. 437 Its provisional type is 0x454348. 439 Its format is equivalent to ECHConfigList, as defined in Section 4 of 440 [ECHO]. 442 Note that, like public_key_failed, this transport parameter is sent 443 in response to a failed attempt to use Protected Initials, and 444 therefore only occurs in other versions of QUIC. 446 If this transport parameter does not match this format, is received 447 by a server, or is received in a connection that uses Protected 448 Initials, the receiver MUST terminate the connection with a 449 TRANSPORT_PARAMETER_ERROR. 451 12. Intermediaries 453 In the topology proposed in Section 3.1 of [ECHO], where a client- 454 facing server has its own public name and potentially fronts a number 455 of independent domains, only the client-facing server has the private 456 keys. Thus, it modifies incoming Initial Packets before forwarding 457 to the back-end server. The back-end server uses a modified 458 technique for decrypting Initial packets. 460 A common use case of this topology is a load balancer fronting 461 multiple domains using the same IP address, which makes routing 462 decisions based on the SNI in the Client Hello. 464 12.1. Client-Facing Server 466 If an incoming client Initial has a non-zero length Encryption 467 Context field, the client-facing server MUST rewrite the Config ID 468 field as zero, replaces the Encapsulated Secret with the shared 469 secret in plaintext, and updates the Encryption Context Length 470 accordingly. 472 To avoid authentication failure, the client-facing server MUST re- 473 encrypt the Initial packet with the new header as associated data. 475 Non-Initial packets, as well as Initial packets that have a zero- 476 length Encryption Context, pass unmodified through the client-facing 477 server. 479 Note that client-facing servers cannot inspect any packet payloads 480 except for Initial packets. 482 12.2. Back-End Server 484 Back-end servers use the plaintext shared secret to generate Initial 485 keys. 487 Back-end servers MUST have an up-to-date copy of the ECHConfigList 488 the client- facing server is using, though it need not hold the 489 private key, in order to properly process the relevant transport 490 parameters. 492 In all other respects they operate as Protected Initial servers. 494 13. Applicability 496 This version of QUIC provides no change from QUIC version 1 relating 497 to the capabilities available to applications. Therefore, all 498 Application Layer Protocol Negotiation (ALPN) ([RFC7301]) codepoints 499 specified to operate over QUICv1 can also operate over this version 500 of QUIC. 502 14. Security and Privacy Considerations 504 Sections 10.2, 10.3, 10.4, and 10.6 of [ECHO] apply to QUIC Protected 505 Initials as well. 507 Section 7.8 of [VERSION-ALIASING] is also applicable. 509 14.1. Key Loss and Version Downgrade 511 ECH and Protected Initials both rely on shared cryptographic 512 configuration state between client and server, delivered by an out- 513 of-band method, usually DNS. 515 In the event this synchronization fails in ECH, the client-facing 516 server can complete the handshake, authenticate itself against the 517 "public name" in the unprotected part of the Client Hello, and 518 provide updated configuration state, allowing a resumed attempt after 519 1 RTT. 521 With Protected Initials, when decryption fails there is not enough 522 context to complete any sort of authentication to update the crypto 523 context. Instead, the server sends a Version Negotiation Packet that 524 causes the client to fall back to a version of QUIC with unprotected 525 Initials, in which it could connect to the public name and only then 526 acquire the updated crypto context. Note that this incurs an 527 additional 1-RTT penalty over ECH, although loss of key 528 synchronization is hopefully a rare occurrence. 530 Furthermore, Version Negotiation Packets are not authenticated, which 531 opens up the possibility of Version Downgrade attacks. 533 The weak form of this attack simply observes the Client Initial and 534 delivers a Version Negotiation Packet before the client responds. 535 Clients SHOULD wait for an interval (roughly the QUIC Probe Timeout, 536 see [I-D.ietf-quic-recovery]) before acting on a Version Negotiation 537 Packet that indicates a lack of support for Protected Initials when a 538 DNS record indicating such support exists, to allow a later valid 539 server response to arrive. If it does, the client MUST ignore the 540 Version Negotiation packet. 542 The strong form of this attack requires the attacker to drop either 543 the Client Initial or the Server Initial. In this case, the client 544 has no recourse but to connect with an unprotected Initial. As 545 described above, the client can obtain an updated context from the 546 public name and then assume subsequent Version Negotiation packets 547 are invalid with high probability. Regardless, an attacker with 548 these capabilities can always block a secured handshake of any kind, 549 and can force the client choose between an insecure handshake and not 550 communicating at all. However, QUIC is designed to fail the 551 connection if an attacker forces a downgrade. 553 Unfortunately, the existing detection mechanism in [QUIC-VN] is 554 insufficient to detect these in the case of Protected Initials. 556 Because some clients may have the correct configuration and others 557 not, servers might send Version Negotiation to a subset of clients 558 that attempt to use Protected Initials. To validate if it would have 559 accepted a "Previously Attempted Version," the server would have to 560 track the clients to which it recently sent Version Negotiation 561 packets. 563 However, even this is insufficient. An attacker can simply drop a 564 Protected Initial Packet, send Version Negotiation, and then send an 565 improperly encrypted Initial Packet to the server using the client's 566 IP to trigger a Version Negotiation. As servers do not authenticate 567 client Initials before sending Version Negotiation, the server has to 568 actually understand the crypto context the client was attempting to 569 use. This is the reason for the public_key_failed transport 570 parameter. 572 14.2. Initial Packet Injection 574 QUIC version 1 handshakes are vulnerable to DoS from observers for 575 the short interval that endpoints keep Initial keys (usually ~1.5 576 RTTS), since Initial Packets are not authenticated. With version 577 aliasing, attackers do not have the necessary keys to launch such an 578 attack. 580 QUIC version 1 can use a fixed symmetric cipher for its Initial 581 Packets because the encryption is not providing true security. As 582 this design aspires to stonger guarantees, the Encryption Context 583 field of the Initial header provides the codepoints to enable use of 584 other symmetric ciphers should AES-128-GCM be compromised in the 585 future. This is to provide cryptographic agility in accordance with 586 [RFC7696]. 588 14.3. Retry Injection 590 This version of QUIC does not improve the security of Retry packets 591 with respect to QUIC version 1. The Retry Integrity Tag uses a well- 592 known key and relies on data in the Initial that triggered the Retry. 593 It therefore protects against transmission errors and injection of 594 Retry packets by off-path attackers that cannot observe the Initial. 595 To detect Retry packets injected by observers, it relies on the 596 subsequent exchange of transport parameters. 598 An attacker that consistently injects Retry packets in front of a 599 server that also consistently sends Retry can result in a Denial of 600 Service, as clients cannot accept two Retries in the same connection. 602 An alternate design would use the shared secret derived from the 603 Client Initial Packet to generate keys for the Retry Integrity Tag, 604 which would allow the client to immediately discard Retries injected 605 by other parties. Unfortunately, this would require servers to 606 perform an asymmetric crypto operation to send a Retry packet, when 607 in a state where it is likely computationally limited. 609 It is possible to enhance the security of Retry by assuming this 610 added computational cost. Such a design could also eliminate the 611 complexity associated with adding an arbitrary value to the Packet 612 Length field. The purpose of this addition is to avoid trial 613 decryption to verify the configuration is correct, but this cost is 614 negligible compared to extracting the shared secret. 616 14.4. Less Trial Decryption 618 Unlike ECH, Protected Initials can use the Packet Length Offset 619 mechanism to detect key mismatches without trial decryption, saving 620 resources in the case of genuine misconfiguration. However, an 621 attacker attempting to force trial decryption can easily force a 622 decryption that will ultimately result in the packet being silently 623 dropped. 625 15. IANA Considerations 627 15.1. QUIC Version Registry 629 This document request that IANA add the following entry to the QUIC 630 version registry: 632 Value: TBD 634 Status: permanent 636 Specification: This document 638 Change Controller: IETF 640 Contact: QUIC WG 642 15.2. QUIC Transport Parameter Registry 644 This document request that IANA add the following two entries to the 645 QUIC Transport Parameters registry: 647 +=======+===================+===============+ 648 | Value | Parameter Name | Specification | 649 +=======+===================+===============+ 650 | TBD | public_key_failed | This document | 651 +-------+-------------------+---------------+ 652 | TBD | ECHConfig | This document | 653 +-------+-------------------+---------------+ 655 Table 2 657 16. References 659 16.1. Normative References 661 [ECHO] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 662 Encrypted Client Hello", Work in Progress, Internet-Draft, 663 draft-ietf-tls-esni-10, 8 March 2021, 664 . 667 [HPKE] Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 668 "Hybrid Public Key Encryption", Work in Progress, 669 Internet-Draft, draft-irtf-cfrg-hpke-08, 15 February 2021, 670 . 673 [I-D.ietf-quic-recovery] 674 Iyengar, J. and I. Swett, "QUIC Loss Detection and 675 Congestion Control", Work in Progress, Internet-Draft, 676 draft-ietf-quic-recovery-34, 14 January 2021, 677 . 680 [I-D.ietf-quic-tls] 681 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 682 Work in Progress, Internet-Draft, draft-ietf-quic-tls-34, 683 14 January 2021, . 686 [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 687 Work in Progress, Internet-Draft, draft-ietf-quic-tls-34, 688 14 January 2021, . 691 [QUIC-TRANSPORT] 692 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 693 and Secure Transport", Work in Progress, Internet-Draft, 694 draft-ietf-quic-transport-34, 14 January 2021, 695 . 698 [QUIC-VN] Schinazi, D. and E. Rescorla, "Compatible Version 699 Negotiation for QUIC", Work in Progress, Internet-Draft, 700 draft-ietf-quic-version-negotiation-03, 4 February 2021, 701 . 704 16.2. Informative References 706 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 707 Requirement Levels", BCP 14, RFC 2119, 708 DOI 10.17487/RFC2119, March 1997, 709 . 711 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 712 "Transport Layer Security (TLS) Application-Layer Protocol 713 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 714 July 2014, . 716 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 717 Agility and Selecting Mandatory-to-Implement Algorithms", 718 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 719 . 721 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 722 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 723 . 725 [VERSION-ALIASING] 726 Duke, M., "QUIC Version Aliasing", Work in Progress, 727 Internet-Draft, draft-duke-quic-version-aliasing-04, 30 728 October 2020, . 731 Appendix A. Change Log 733 *RFC Editor's Note:* Please remove this section prior to 734 publication of a final version of this document. 736 A.1. since draft-duke-quic-protected-initials-00 738 * Additional text comparing ECH, Version Aliasing 740 * Adapted to foreground the split-mode use case 742 * Clarified server initials are encrypted 744 * Retry keys are no longer generated from the shared secret 746 * Complete Rewrite of Fallback 748 * New transport parameters 750 * Added crypto agility 752 Author's Address 753 Martin Duke 754 F5 Networks, Inc. 756 Email: martin.h.duke@gmail.com