]> F5 Networks, Inc.

martin.h.duke@gmail.com

Google LLC

1600 Amphitheatre Parkway Mountain View, California 94043 United States of America dschinazi.ietf@gmail.com

Transport quic QUIC encrypts its Initial Packets using keys derived from well-known constants, meaning that observers can inspect the contents of these packets and successfully spoof them. This document proposes a new version of QUIC that encrypts Initial Packets more securely by leveraging a Public Key distributed via the Domain Name System (DNS) or other out-of-band system. Discussion Venues Discussion of this document takes place on the mailing list (quic@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

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.

Relationship to ECH and Version Aliasing Encrypted Client Hello and QUIC Version Aliasing also exist in the solution space of concealing parts of the Initial packet exchange from observers. The following table summarizes the advantages and disadvantages of each.

Property	ECH	Protected Initials	Version Aliasing
Fields Protected	Some of Client Hello	All Initial Payloads	All Initial Payloads
Delay when server loses its keys	1 RTT	2 RTT	2 RTT
Works with TLS over TCP	Yes	No	No
First-connection protection	Yes	Yes	No
Prevents Initial packet injection attacks	No	Yes	Yes
Symmetric Encryption Only	No	No	Yes
Greases the Version Field	No	No	Yes
Prevents Retry injection attacks	No	No	Yes
No trial decryption	No	No	Yes

The more complex properties in the table are discussed in . Both ECH and Protected Initials are complimentary with Version Aliasing: they provide a computationally expensive way to protect parts of the Initial packet during the first connection between client and server, after which Version Aliasing can protect future exchanges with several additional desirable properties.

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 .

Differences with QUIC Version 1 The version of QUIC described in this specification is identical to QUIC version 1 except where described in this document.

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

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.

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. Clients MUST include a nonzero Encryption Context Length in all Initial packets, unless executing fallback procedures (see ). When the client includes a non-zero-length Encryption Context, it MUST include an initial_encryption_context in its Client Hello, so that this header field is included in the TLS handshake transcript.

Encryption Context The encryption context, if nonzero length, has the following format: Config ID: An 8-bit integer identifying the configuration parameters, obtained from the ECHConfig. This ID implicitly identifies the public key, Key Encapsulation Mechanism, and the set of symmetric suites from which the following fields are selected. SCKDF: Symmetric Cipher Key Derivation Function. The client selects this from the cipher suites listed in the ECHConfig. This is the cipher used to encrypt the Initial Packet. The values are listed in Section 7.2 of . All endpoints MUST support HKDF-SHA256 (0x0001), which is used for QUIC Version 1 Initial packets. SCAEADID: Symmetric Cipher Key Derivation Function. The client selects this from the cipher suites listed in the ECHConfig. This is the cipher used to encrypt the Initial Packet. The values are listed in Section 7.3 of . All endpoints MUST support AES-128-GCM (0x0001), which is used for QUIC Version 1 Initial packets. 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. 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. Otherwise, the server generates the Initial secrets: The remainder is identical to the client procedure. All server-generated Initial packets use the keys generated in this process. If packet decryption fails, see . The server terminates the connection with a TRANSPORT_PARAMETER_ERROR under the following conditions:

• There is a zero-length Encryption Context field, but the initial_encryption_context transport parameter is present
• There is a non-zero-length Encryption Context field, but the initial_encryption_context transport parameter is absent or does not match the header.

However, see for exceptions to this transport parameter processing rule.

Retry Integrity Tag The Retry packet is identical to QUIC version 1, except that the key and nonce used for the Retry Integrity Tag (Sec 5.8 of change to: This key and nonce are also used in Fallback packets ().

Fallback If decryption fails, the client may not have the server's correct configuration. In this case, the server replies with a Fallback packet (see ), and discards the Initial. The client checks the Integrity Tag in the packet against the received Fallback Packet and its own record of the Initial Packet. If they do not match, the packet may have been corrupted, and the client SHOULD treat the packet as lost. If they do match, the client MUST assume that it does not have the correct ECHConfig. When it has the incorrect config, the client composes a new Client Hello. It MUST include the public_key_failed transport parameter with the Config ID and public key it attempted to use. It MUST use an Encryption Context Length of zero, and encrypt it with keys derived from the "fallback salt" 0xbd62319ad6eeb17a9ed0d3bf75e37e4a8e7e6ac7, instead of the shared secret that the server cannot decode. The Client Hello also MUST include any Retry Token the previous Initial contained and MAY include a token from a NEW_TOKEN frame. This new Initial packet is part of the same connection and MUST use the same Connection IDs and packet number space. Note that the fallback salt does not provide confidentiality to the client, and the client SHOULD NOT include privacy-sensitive information there. See for further discussion of this. A server interprets a client Initial with a zero-length Encryption Context as an Initial encrypted with keys derived from the fallback salt and decrypts it accordingly. The server checks the Config ID and public key from the public_key_failed transport parameter to see if it should successfully process a Protected Initial with these parameters. If it would have, it MUST terminate the connection with an INVALID_PROTECTED_INITIAL_DOWNGRADE error to indicate that there has been an attack. If the server would not have successfully decoded the packet with those parameters, it MUST send its own public_key_failed transport parameter to acknowledge the parameter was successfully processed. It MAY also send a ECHConfig transport parameter to allow use of Protected Initials in subsequent connections, a Version Aliasing transport parameter (see ) to enable a different means of Initial Protection, both, or neither. If the client does not receive a public_key_failed transport parameter in response to sending a public_key_failed transport parameter, it MUST terminate the connection with a TRANSPORT_PARAMETER_ERROR. The client MUST NOT include the original client hello in its TLS transcript hash for key computation, as the server has no access to this message. However, the client hello is an input to the Integrity tag in the public_key_failed transport parameter, which will be in the transcript.

The Fallback Packet The Fallback packet uses the 0x1 packet type code, which it shares with 0-RTT. Since 0-RTT is only sent by clients and Fallback is only sent by servers, these two types are distinguished by the endpoint's role in the handshake. The Fallback packet has the following format: The server computes the Integrity Tag by prepending the entire UDP payload that contained the client Initial to the Fallback packet contents (minus the tag itself, of course) to form a pseudo-packet. The server then computes the Integrity Tag as the output of AEAD_AES_128_GCM with the key and nonce from , no plaintext, and the pseudo-packet as the Additional Data. This thus confirms the integrity of both packets in the exchange.

New Transport Parameters

public_key_failed The public_key_failed transport parameter allows detection of an attacker injecting messages to force use of the fallback salt. For details on use, see . Its provisional type is 0x706b66. When sent by a client, the content of the transport parameter is as follows: The Integrity Tag is copied from the Fallback packet. The other fields are populated using the ECHConfig that the client attempted to use. The length of the Public Key is inferred from the length field of the transport parameter. When sent by a server, the transport parameter has no value field. Endpoints MUST respond to a malformed transport parameter by closing the connection with a TRANSPORT_PARAMETER_ERROR. Note that this transport parameter is always sent as a result of a fallback from a Protected Initial, and therefore with a zero-length Encryption Context in the packet header. Therefore, if received with non-zero-length Encryption Context, the receiving endpoint MUST terminate the connection with a TRANSPORT_PARAMETER_ERROR.

ECHConfig The ECHConfig transport parameter allows servers to directly provide clients a valid configuration. Its provisional type is 0x454348. Its format is equivalent to ECHConfigList, as defined in Section 4 of . If this transport parameter does not match this format, is received by a server, or is received in a connection where the client's most recent Initial had a non-zero-length Encryption Context, the receiver MUST terminate the connection with a TRANSPORT_PARAMETER_ERROR.

initial_encryption_context The format of this transport parameter is identical to the Encryption Context described in . Its provisional type is 0x696563.

Intermediaries In the topology proposed in Section 3.1 of , where a client-facing server has its own public name and potentially fronts a number of independent domains, only the client-facing server has the private keys. Thus, it modifies incoming Initial Packets before forwarding to the back-end server. A common use case of this topology is a load balancer fronting multiple domains using the same IP address, which makes routing decisions based on the SNI in the Client Hello.

Client-Facing Server The client-facing server is responsible for verifying the Initial packet is decryptable, sending a Fallback packet (and dropping the Initial) if it is not, and otherwise forwarding the packet encrypted with a different key. If an incoming Initial packet is not decryptable, the client-facing server sends a Fallback packet and drops the Initial. If an incoming client Initial has a non-zero length Encryption Context field, the client-facing server MUST delete the Encryption Context field. When forwarding to the back-end server, it encrypts the plaintext version of this modified packet with keys derived from the fallback salt. Thus, between client-facing server and back-end server the packet is inspectable by observers. Similarly, if the client is using the shared secret, the client-facing server MUST decrypt server Initial packets encrypted with keys derived from the fallback secret, and re-encrypt them with keys derived from the shared secret. The client-facing server MUST enforce correct use of the initial_encryption_context parameter, as described in , and terminate the connection if necessary. Non-Initial packets pass unmodified through the client-facing server. Note that client-facing servers cannot inspect any packet payloads except for Initial packets.

Back-End Server Back-end servers MUST have an up-to-date copy of the ECHConfigList the client- facing server is using, though it need not hold the private key, in order to properly process and generate the relevant transport parameters. Back-end servers MUST NOT take any action based on the presence or contents of the initial_encryption_context transport parameter, as the client-facing server has likely stripped the Encryption Context out of the header. In all other respects, they operate as Protected Initial servers.

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. Section 7.8 of is also applicable.

Forcing Downgrade An attacker attempts to force a client to send an Initial that uses unprotected Initials by injecting a Version Negotiation packet (which implies the server no longer supports Protected Initials) or a Fallback packet (which implies the server has a new cryptographic context). The weak form of this attack observes the Initial and injects the Version Negotiation or Fallback packet, but cannot drop the Initial. To counteract this, a client SHOULD NOT respond to these packets until they have waited for Probe Timeout (PTO) for a valid server Initial to arrive. The strong form features an attacker that can drop Initial packets. In this case, the client can either abandon the connection attempt or connect with a unprotected Initial: using the fallback salt in response to a Fallback packet, or a different version in response to Version Negotiation. If connecting with an unprotected Initial, the client MAY alter it to sanitize sensitive information and obtain either a correct ECHConfig or an aliased version before proceeding with its true connection attempt. However, the client Initial MUST lead to the authentication of a domain name the client trusts to provide accurate cryptographic information (usually the public_name from the ECHConfig). Advice for the Outer ClientHello in Section 10.5 of applies here. Furthermore, if it received a Fallback packet, the client sends a public_key_failed transport parameter to detect the downgrade attack, and the server will terminate the connection if the Fallback packet was an attack. If the client received a Version Negotiation packet, it MUST implement a downgrade detection mechanism such as or abandon the connection attempt. If it subsequently detects a downgrade detection, or discovers that the server does not support the same mechanism, it terminates the connection attempt. Note that ECH is able to retrieve an up-to-date cryptographic context in 1 RTT, because the client hello has enough plaintext information to begin a handshake with the public_name. Protected Initials require reconnection with the public name, incurring a 2 RTT penalty to achieve the same result.

Initial Packet Injection QUIC version 1 handshakes are vulnerable to DoS from observers for the short interval that endpoints keep Initial keys (usually ~1.5 RTTS), since Initial Packets are not authenticated. With version aliasing, attackers do not have the necessary keys to launch such an attack. QUIC version 1 can use a fixed symmetric cipher for its Initial Packets because the encryption is not providing true security. As this design aspires to stonger guarantees, the Encryption Context field of the Initial header provides the codepoints to enable use of other symmetric ciphers should AES-128-GCM be compromised in the future. This is to provide cryptographic agility in accordance with .

Retry Injection This version of QUIC does not improve the security of Retry packets with respect to QUIC version 1. The Retry Integrity Tag uses a well-known key and relies on data in the Initial that triggered the Retry. It therefore protects against transmission errors and injection of Retry packets by off-path attackers that cannot observe the Initial. To detect Retry packets injected by observers, it relies on the subsequent exchange of transport parameters. An attacker that consistently injects Retry packets in front of a server that also consistently sends Retry can result in a Denial of Service, as clients cannot accept two Retries in the same connection. An alternate design would use the shared secret derived from the Client Initial Packet to generate keys for the Retry Integrity Tag, which would allow the client to immediately discard Retries injected by other parties. Unfortunately, this would require servers to perform an asymmetric crypto operation to send a Retry packet, when in a state where it is likely computationally limited. It is possible to enhance the security of Retry by assuming this added computational cost. Such a design could also eliminate the complexity associated with adding an arbitrary value to the Packet Length field. The purpose of this addition is to avoid trial decryption to verify the configuration is correct, but this cost is negligible compared to extracting the shared secret.

IANA Considerations

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

QUIC Transport Parameter Registry This document requests that IANA add the following three entries to the QUIC Transport Parameters registry:

Value	Parameter Name	Specification
TBD	public_key_failed	This document
TBD	ECHConfig	This document
TBD	initial_encryption_context	This document

QUIC Transport Error Codes Registry This document requests that IANA add the following entry to the QUIC Transport Error Codes registry: Value: TBD Code: INVALID_PROTECTED_INITIAL_DOWNGRADE Description: Attacker is forcing insecure Initial Specification: This document

References Normative References This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document describes how Transport Layer Security (TLS) is used to secure QUIC. RTFM, Inc. Fastly Cloudflare Cloudflare This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni). Cisco Inria Inria Cloudflare This document describes a scheme for hybrid public-key encryption (HPKE). This scheme provides a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one which authenticates possession of a pre-shared key, and two optional ones which authenticate possession of a KEM private key. HPKE works for any combination of an asymmetric key encapsulation mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman key agreement, HKDF, and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Google LLC Mozilla QUIC does not provide a complete version negotiation mechanism but instead only provides a way for the server to indicate that the version the client offered is unacceptable. This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version. Optionally, if the original and negotiated version share a compatible first flight format, the negotiation can take place without incurring an extra round trip. Informative References This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. F5 Networks, Inc. The QUIC transport protocol preserves its future extensibility partly by specifying its version number. There will be a relatively small number of published version numbers for the foreseeable future. This document provides a method for clients and servers to negotiate the use of other version numbers in subsequent connections and encrypts Initial Packets using secret keys instead of standard ones. If a sizeable subset of QUIC connections use this mechanism, this should prevent middlebox ossification around the current set of published version numbers and the contents of QUIC Initial packets, as well as improving the protocol's privacy properties. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly. This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time.

Change Log

• RFC Editor's Note: Please remove this section prior to publication of a final version of this document.

since draft-duke-quic-protected-initials-01

• Redesigned fallback again without Version Negotiation
• Added the initial_encryption_context transport parameter

since draft-duke-quic-protected-initials-00

• Additional text comparing ECH, Version Aliasing
• Adapted to foreground the split-mode use case
• Clarified server initials are encrypted
• Retry keys are no longer generated from the shared secret
• Complete Rewrite of Fallback
• New transport parameters
• Added crypto agility