Protected QUIC Initial Packets

Introduction DISCLAIMER: This draft is a preliminary proposal with insufficient security analysis. It should not be used in production systems. The QUIC Initial Packet is encrypted using a key derived from the Destination Connection ID in the packet cleartext and a well-known salt (see Section 5.2 of ). Section 7 of that draft describes security vulnerabilities resulting from the resulting lack of authentication. This also has privacy implications, as observers can decrypt the packet and inspect the contents, which contain the TLS Client Hello and Server Hello Messages (). The former contains QUIC Transport Parameters, which reveal even more information about the traffic. Furthermore, packets vulnerable to deep inspection create an ossification vector. Intermediaries that expect the contents of these messages to match a certain format and template might drop packets that do not, preventing the use of new protocol extensions or improved security protocols. This document proposes a new version of QUIC where the client obtains a public key generated by the server and uses it to encrypt a shared secret, sent in the Initial packet header, that both endpoints can then use to protect Initial packets. This mechanism leverages the public key that would be distributed via DNS (or other out-of-band mechanism) to support Encrypted Client Hello . That design uses Hybrid Public Key Exchange (HPKE) ( to authenticate some HPKE configuration information and the "outer client hello" that is in plaintext, while encrypting the "inner client hello" that contains privacy-sensitive information. This document uses the widespread configuration that will exist if ECHO is widely deployed, but only sends the subset of information necessary to seed the QUIC key generation process. This design is meant to be complimentary with QUIC Version Aliasing . Version Aliasing does not require coordination with DNS or costly asymmetric encryption, and also hinders ossification of the QUIC version field. However, it does not protect the first connection between the client and server, and can be difficult to coordinate with intermediaries like client-facing load balancers. This document addresses those use cases. Unlike , Protected Initial Packets protect the entire packet payloads that contain the Client Hello and Server Hello, instead of just part of the Client Hello. The version of QUIC described in this specification is identical to QUIC version 1 except where described in this document.

Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 .

Key Configuration The client obtains the Encrypted ClientHello Configuration (ECHConfig) described in Section 4 of , which provides the context that allows protection of Initial packets. The ECHConfig is available via a DNS record or other out-of- band system.

Version Number The version field in long headers is TBD. Note: for interoperability exercises, use the provisional value 0xff454900.

Key Derivation Labels The labels used to derive keying material in change from "quic key", "quic iv", "quic hp", and "quic ku" to "quicpi key", "quicpi iv", "quicpi hp", and "quicpi ku", respectively.

Initial Packet Header The figure below is presented in the format from , and adds a variable-length Encryption Context preceded by a length field: Encryption Context Length: A variable-length integer specifying the length of the encryption context, in bytes. Servers MUST set this field to zero; a client that receives a non-zero length MUST either discard the packet or generate a connection error of type PROTOCOL_VIOLATION. If a client has received a valid Server Initial packet, it SHOULD set this field to zero. Until then, clients MUST use a nonzero value. If a client Initial packet has a zero Encryption Context Length, and the server has not sent an Initial Packet, the server MUST either discard the packet or generate a connection error of type PROTOCOL_VIOLATION.

Encryption Context The encryption context, if nonzero length, has the following format: The client obtains the Config ID (an 8-bit unsigned integer) from the ECHConfig. It corresponds to a public key and Key Encapsulation Mechanism (KEM) that are not sent over the wire. The Encapsulated Secret is HPKE encapsulated. Its length is inferred from the Encryption Context Length field.

Client Packet Protection Procedure An client extracts the public key pkR and uses it to generate a shared_secret: enc is the Encapsulated Secret, and is written into that subfield of the Encryption Context Field. The initial_secret above is used to generate client_initial_secret and server_initial_secret as described in Section 5.2 of . When applying header protection, the Context Length and Encryption Context are not Protected. Additionally, the client bitwise-XORs the first eight octets of the Destination Connection ID with the first eight octets of the public key to form a 64 bit unsigned integer. This integer is added to the packet length, modulo 2^62, and written into the packet length field instead of the actual packet length. This derivation is performed once per connection. Subsequent Initial Packets use the same keys and the same offset to the packet number, regardless of additional Encryption Context fields or changed connection IDs.

Server Packet Protection Procedure The server reads the Config ID and Encapsulated Secret (enc) from the Initial Packet. It looks up its private key (skR) associated with the Config ID. Prior to any other operations, including sending any Retry packet, the server bitwise-XORs the first eight octets of its public key and the destination connection ID and subtracts this from the value in the packet length field, modulo 2^62, to find the true packet length. Any result that exceeds the size of the received datagram indicates with high assurance that the client's received ECHConfig does not match the server's state, possibly due to a misconfiguration. The probability this test results in a false negative, when an incorrect key generates a result less than the datagram size, is typically less than 1 in 2^51. The server MUST discard the packet and SHOULD send a Version Negotiation packet that does not advertise the current QUIC version, as the endpoints do not have the necessary shared state to use QUIC Protected Initials. Otherwise, the server generates the Initial secrets: The server now has sufficient context to send a Retry packet and MAY choose to do so at this point (see ). If not, it decrypts the Initial packet. The remainder is identical to the client procedure.

Retry Integrity Tag The Retry packet is identical to QUIC version 1, except that the secret key K and nonce N (see Sec 5.8 of ) are derived from the shared_secret instead of the secret provided there. Also, the labels are as described in .

Version Negotiation Endpoints that support QUIC Protected Initials MUST support at least one other version of QUIC (in case the endpoints cannot agree on the ECHConfig), and therefore MUST also support . In contrast to Section 5 of that document, clients MUST be prepared to receive a version negotiation packet that contains QUIC Protected Initial, and then receive a second version negotiation packet that does not, should the attempt to identify a common ECHConfig fail. Servers MAY continue to advertise QUIC Protected Initials in its Server Handshake Version Information, even if shared secret extraction failed, to avoid tracking state as to which clients have failed such extraction. This does not effect the Version Downgrade mechanism, which is executed by servers. Note that QUIC version 1 is not compatible with QUIC Protected Initials, as it does not contain the information necessary to generate subsequent Initial packets correctly. Conversely, QUIC Protected Initials are compatible with QUIC version 1. However, since the versions have identical properties after the Initial packet exchange, there is little value in such a trasition.

Intermediaries Intermediaries that rely on the contents of the Client Hello (e.g., a load balancer that routes between servers with the same IP address based on the SNI field in the Client Hello) MUST have access to the ECHConfig and the corresponding Private Keys, as described in Section 3.1 of , to function properly.

Applicability This version of QUIC provides no change from QUIC version 1 relating to the capabilities available to applications. Therefore, all Application Layer Protocol Negotiation (ALPN) () codepoints specified to operate over QUICv1 can also operate over this version of QUIC.

Security and Privacy Considerations Sections 10.2, 10.3, 10.4, and 10.6 of apply to QUIC Protected Initials as well. Sections 7.2, 7.3, 7.7, and 7.8 of are also applicable.

IANA Considerations This document request that IANA add the following entry to the QUIC version registry: Value: TBD Status: permanent Specification: This document Change Controller: IETF Contact: QUIC WG