QUIC Version 2

QUIC Version 2 Google LLC

martin.h.duke@gmail.com

Transport QUIC This document specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details. Its purpose is to combat various ossification vectors and exercise the version negotiation framework. It also serves as a template for the minimum changes in any future version of QUIC. Note that "version 2" is an informal name for this proposal that indicates it is the second version of QUIC to be published as a Standards Track document. The protocol specified here uses a version number other than 2 in the wire image, in order to minimize ossification risks.

Introduction QUIC version 1 has numerous extension points, including the version number that occupies the second through fifth bytes of every long header (see ). If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version bytes that are usually 0x00000001. In QUIC version 1, Initial packets are encrypted with the version-specific salt, as described in . Protecting Initial packets in this way allows observers to inspect their contents, which includes the TLS Client Hello or Server Hello messages. Again, there is the potential for middleboxes to ossify on the version 1 key derivation and packet formats. Finally, describes two mechanisms endpoints can use to negotiate which QUIC version to select. The "incompatible" version negotiation method can support switching from any QUIC version to any other version with full generality, at the cost of an additional round trip at the start of the connection. "Compatible" version negotiation eliminates the round-trip penalty but levies some restrictions on how much the two versions can differ semantically. QUIC version 2 is meant to mitigate ossification concerns and exercise the version negotiation mechanisms. The changes provide an example of the minimum set of changes necessary to specify a new QUIC version. However, note that the choice of the version number on the wire is randomly chosen instead of "2", and the two bits that identify each Long Header packet type are different from version 1; both of these properties are meant to combat ossification and are not strictly required of a new QUIC version. Any endpoint that supports two versions needs to implement version negotiation to protect against downgrade attacks.

Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Differences with QUIC Version 1 Except for a few differences, QUIC version 2 endpoints MUST implement the QUIC version 1 specification as described in , , and . The remainder of this section lists the differences.

Version Field The Version field of long headers is 0x6b3343cf. This was generated by taking the first four bytes of the sha256sum of "QUICv2 version number".

Long Header Packet Types All version 2 Long Header packet types are different. The Type field values are:

Initial: 0b01
0-RTT: 0b10
Handshake: 0b11
Retry: 0b00

Cryptography Changes

Initial Salt The salt used to derive Initial keys in changes to: This is the first 20 bytes of the sha256sum of "QUICv2 salt".

HMAC-based Key Derivation Function (HKDF) Labels The labels used in to derive packet protection keys (Section ), header protection keys (Section ), Retry Integrity Tag keys (Section ), and key updates (Section ) change from "quic key" to "quicv2 key", from "quic iv" to "quicv2 iv", from "quic hp" to "quicv2 hp", and from "quic ku" to "quicv2 ku" to meet the guidance for new versions in Section of that document.

Retry Integrity Tag The key and nonce used for the Retry Integrity Tag () change to: The secret is the sha256sum of "QUICv2 retry secret". The key and nonce are derived from this secret with the labels "quicv2 key" and "quicv2 iv", respectively.

Version Negotiation Considerations QUIC version 2 is not intended to deprecate version 1. Endpoints that support version 2 might continue support for version 1 to maximize compatibility with other endpoints. In particular, HTTP clients often use Alt-Svc to discover QUIC support. As this mechanism does not currently distinguish between QUIC versions, HTTP servers SHOULD support multiple versions to reduce the probability of incompatibility and the cost associated with QUIC version negotiation or TCP fallback. For example, an origin advertising support for "h3" in Alt-Svc should support QUIC version 1, as it was the original QUIC version used by HTTP/3; therefore, some clients will only support that version. Any QUIC endpoint that supports QUIC version 2 MUST send, process, and validate the version_information transport parameter specified in to prevent version downgrade attacks. Note that version 2 meets the definition in of a compatible version with version 1, and version 1 is compatible with version 2. Therefore, servers can use compatible negotiation to switch a connection between the two versions. Endpoints that support both versions SHOULD support compatible version negotiation to avoid a round trip.

Compatible Negotiation Requirements Compatible version negotiation between versions 1 and 2 follows the same requirements in either direction. This section uses the terms "original version" and "negotiated version" from . If the server sends a Retry packet, it MUST use the original version. The client ignores Retry packets using other versions. The client MUST NOT use a different version in the subsequent Initial packet that contains the Retry token. The server MAY encode the QUIC version in its Retry token to validate that the client did not switch versions, and drop the packet if it switched, to enforce client compliance. QUIC version 2 uses the same transport parameters to authenticate the Retry as QUIC version 1. After switching to a negotiated version after a Retry, the server MUST include the relevant transport parameters to validate that the server sent the Retry and the connection IDs used in the exchange, as described in . The server cannot send CRYPTO frames until it has processed the client's transport parameters. The server MUST send all CRYPTO frames using the negotiated version. The client learns the negotiated version by observing the first long header Version field that differs from the original version. If the client receives a CRYPTO frame from the server in the original version, it indicates that the negotiated version is equal to the original version. Before the server is able to process transport parameters from the client, it might need to respond to Initial packets from the client. For these packets, the server uses the original version. Once the client has learned the negotiated version, it SHOULD send subsequent Initial packets using that version. The server MUST NOT discard its original version Initial receive keys until it successfully processes a Handshake packet with the negotiated version. Both endpoints MUST send Handshake and 1-RTT packets using the negotiated version. An endpoint MUST drop packets using any other version. Endpoints have no need to generate the keying material that would allow them to decrypt or authenticate such packets. The client MUST NOT send 0-RTT packets using the negotiated version, even after processing a packet of that version from the server. Servers can accept 0-RTT and then process 0-RTT packets from the original version.

TLS Resumption and NEW_TOKEN Tokens TLS session tickets and NEW_TOKEN tokens are specific to the QUIC version of the connection that provided them. Clients MUST NOT use a session ticket or token from a QUIC version 1 connection to initiate a QUIC version 2 connection, and vice versa. When a connection includes compatible version negotiation, any issued server tokens are considered to originate from the negotiated version, not the original one. Servers MUST validate the originating version of any session ticket or token and not accept one issued from a different version. A rejected ticket results in falling back to a full TLS handshake, without 0-RTT. A rejected token results in the client address remaining unverified, which limits the amount of data the server can send. After compatible version negotiation, any resulting session ticket maps to the negotiated version rather than the original one.

Ossification Considerations QUIC version 2 provides protection against some forms of ossification. Devices that assume that all long headers will encode version 1, or that the version 1 Initial key derivation formula will remain version-invariant, will not correctly process version 2 packets. However, many middleboxes, such as firewalls, focus on the first packet in a connection, which will often remain in the version 1 format due to the considerations above. Clients interested in combating middlebox ossification can initiate a connection using version 2 if they are reasonably certain the server supports it and if they are willing to suffer a round-trip penalty if they are incorrect. In particular, a server that issues a session ticket for version 2 indicates an intent to maintain version 2 support while the ticket remains valid, even if support cannot be guaranteed.

Applicability QUIC version 2 provides no change from QUIC version 1 for the capabilities available to applications. Therefore, all Application-Layer Protocol Negotiation (ALPN) codepoints specified to operate over QUIC version 1 can also operate over this version of QUIC. In particular, both the "h3" and "doq" ALPNs can operate over QUIC version 2. Unless otherwise stated, all QUIC extensions defined to work with version 1 also work with version 2.

Security Considerations QUIC version 2 introduces no changes to the security or privacy properties of QUIC version 1. The mandatory version negotiation mechanism guards against downgrade attacks, but downgrades have no security implications, as the version properties are identical. Support for QUIC version 2 can help an observer to fingerprint both client and server devices.

IANA Considerations IANA has added the following entries to the "QUIC Versions" registry maintained at .

Value:: 0x6b3343cf
Status:: permanent
Specification:: RFC 9369
Change Controller:: IETF
Contact:: QUIC WG

Value:: 0x709a50c4
Status:: provisional
Specification:: RFC 9369
Change Controller:: IETF
Contact:: QUIC WG
Notes:: QUIC v2 draft codepoint

References Normative References Compatible Version Negotiation for QUIC Google LLC Mozilla Informative References

Sample Packet Protection This section shows examples of packet protection so that implementations can be verified incrementally. Samples of Initial packets from both the client and server plus a Retry packet are defined. These packets use an 8-byte client-chosen Destination Connection ID of 0x8394c8f03e515708. Some intermediate values are included. All values are shown in hexadecimal.

Keys The labels generated during the execution of the HKDF-Expand-Label function (that is, HkdfLabel.label) and part of the value given to the HKDF-Expand function in order to produce its output are: client in: 00200f746c73313320636c69656e7420696e00 server in: 00200f746c7331332073657276657220696e00 quicv2 key: 001010746c73313320717569637632206b657900 quicv2 iv: 000c0f746c7331332071756963763220697600 quicv2 hp: 00100f746c7331332071756963763220687000 The initial secret is common: The secrets for protecting client packets are: The secrets for protecting server packets are:

Client Initial The client sends an Initial packet. The unprotected payload of this packet contains the following CRYPTO frame, plus enough PADDING frames to make a 1162-byte payload: The unprotected header indicates a length of 1182 bytes: the 4-byte packet number, 1162 bytes of frames, and the 16-byte authentication tag. The header includes the connection ID and a packet number of 2: Protecting the payload produces an output that is sampled for header protection. Because the header uses a 4-byte packet number encoding, the first 16 bytes of the protected payload is sampled and then applied to the header as follows: The resulting protected packet is:

Server Initial The server sends the following payload in response, including an ACK frame, a CRYPTO frame, and no PADDING frames: The header from the server includes a new connection ID and a 2-byte packet number encoding for a packet number of 1: As a result, after protection, the header protection sample is taken, starting from the third protected byte: The final protected packet is then:

Retry This shows a Retry packet that might be sent in response to the Initial packet in . The integrity check includes the client-chosen connection ID value of 0x8394c8f03e515708, but that value is not included in the final Retry packet:

ChaCha20-Poly1305 Short Header Packet This example shows some of the steps required to protect a packet with a short header. It uses AEAD_CHACHA20_POLY1305. In this example, TLS produces an application write secret from which a server uses HKDF-Expand-Label to produce four values: a key, an Initialization Vector (IV), a header protection key, and the secret that will be used after keys are updated (this last value is not used further in this example). The following shows the steps involved in protecting a minimal packet with an empty Destination Connection ID. This packet contains a single PING frame (that is, a payload of just 0x01) and has a packet number of 654360564. In this example, using a packet number of length 3 (that is, 49140 is encoded) avoids having to pad the payload of the packet; PADDING frames would be needed if the packet number is encoded on fewer bytes. The resulting ciphertext is the minimum size possible. One byte is skipped to produce the sample for header protection. The protected packet is the smallest possible packet size of 21 bytes.

Acknowledgments The author would like to thank , , , , , , , and for their helpful suggestions.