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.
Summary of QUIC Version 2 RFC (RFC 9369)
0:00Purpose: QUIC version 2 (V2) was created to combat the ossification of QUIC version 1 (V1) features by middleboxes and to exercise the QUIC version negotiation framework. It also serves as a template for minimal changes required for future QUIC versions.
0:00Functional Identity: Functionally, V2 is identical to V1; it offers no new capabilities to applications compared to V1.
0:00Differences from V1: The differences are minimal and primarily target ossification prevention. These include a different version number in the wire image (0x6b3343cf, not '2'), different bit patterns for Long Header packet types, a different Initial salt for key derivation, changed HKDF labels (e.g., "quicv2 key"), and different key/nonce values for the Retry Integrity Tag.
0:00Version Negotiation: Endpoints supporting V2 MUST implement mandatory version negotiation as defined in [QUIC-VN] to prevent downgrade attacks.
0:00Compatibility: V1 and V2 are defined as compatible versions, allowing for compatible version negotiation (avoiding an extra round trip) between endpoints supporting both.
0:00Negotiation Details: During compatible negotiation, Retry packets use the original version, Handshake and 1-RTT packets MUST use the negotiated version, and 0-RTT packets MUST NOT use the negotiated version.
0:00TLS Resumption/Tokens: TLS session tickets and NEW_TOKEN tokens are version-specific; a token from a V1 connection cannot be used to initiate a V2 connection, and vice versa. Servers MUST validate the originating version of tokens.
0:00Applicability: Existing Application-Layer Protocol Negotiation (ALPN) codepoints (like "h3" for HTTP/3, "doq" for DNS over QUIC) and QUIC extensions specified for V1 also work over V2.
0:00Deployment: V2 is not intended to deprecate V1. Endpoints, particularly servers advertising services like HTTP/3 (which originated on V1), SHOULD support both V1 and V2 for maximum compatibility.
0:00Security: V2 introduces no changes to the security or privacy properties of V1.
Glossary:
Ossification: In the context of network protocols, this refers to the phenomenon where intermediaries (like firewalls or middleboxes) become rigid ("ossify") by expecting specific byte patterns, version numbers, or behaviors of an existing protocol version (like QUICv1), making it difficult or impossible to deploy future versions or extensions with different characteristics.
Version Negotiation: A mechanism defined for QUIC where a client and server, receiving packets with version numbers they don't support, exchange information (via Version Negotiation packets or the version_information transport parameter) to find a mutually supported QUIC version for the connection.
Middlebox: A network device (e.g., firewall, NAT, load balancer) positioned between communicating endpoints that processes, inspects, modifies, or otherwise interacts with network traffic, sometimes interfering with or becoming dependent on protocol specifics.
Wire Image: The literal sequence of bytes representing a network packet as it is transmitted "on the wire."
Long Header/Short Header: QUIC packets use different header formats. Long Headers are used during the handshake phase and for initial packets, containing fields like version number and connection IDs. Short Headers are used after the handshake is complete for sending data and acknowledgments.
Initial Packet: The first type of long header packet sent by the client to initiate a QUIC connection. It carries the first part of the TLS handshake message.
0-RTT (Zero Round-Trip Time): Data sent by a client in the first packet flight of a new connection based on cryptographic state learned from a previous connection with the same server. It aims to reduce connection setup latency.
Handshake Packet: Long header packets used during the QUIC handshake phase to exchange TLS handshake messages after the Initial packets.
Retry Packet: A type of long header packet sent by a server in response to an Initial packet to validate the client's address using a token.
Salt: A random value used as an input to a cryptographic function, often in key derivation, to ensure that even if the source key is the same, the output key is different for different contexts or versions.
HKDF (HMAC-based Key Derivation Function): A specific cryptographic algorithm (defined in RFC 5869) used to derive one or more cryptographically strong keys from a source keying material. It's used in QUIC (and TLS) to derive packet protection keys from the TLS secrets.
Integrity Tag: A cryptographic value (often an authentication tag like from AES-GCM or ChaCha20-Poly1305) appended to data to allow the recipient to verify that the data has not been tampered with and potentially also authenticate the sender.
Transport Parameter: Configuration values and capabilities exchanged by QUIC endpoints during the handshake phase to configure the connection (e.g., maximum stream ID, maximum packet size).
Compatible Version Negotiation: A specific method of version negotiation defined in [QUIC-VN] that allows switching to a different QUIC version without adding an extra round trip, provided the versions meet certain compatibility requirements.
TLS Resumption: A feature in TLS that allows a client and server that have previously established a session to resume it, typically using a session ticket, enabling an abbreviated handshake and reduced latency.
NEW_TOKEN Token: A token sent by a server to a client in a NEW_TOKEN frame. The client can use this token in a future connection attempt from a potentially different IP address to prove ownership of the original address, helping the server to validate the client's address without a Retry packet.
ALPN (Application-Layer Protocol Negotiation): A TLS extension that allows the application layer to negotiate which protocol will be used over the secure connection (e.g., HTTP/1.1, HTTP/2, HTTP/3).