]> 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 standards-track QUIC version. The protocol specified here uses a version number other than 2 in the wire image, in order to minimize ossification risk. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the QUIC Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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 always being 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, provides two mechanisms for endpoints to negotiate the QUIC version to use. 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".

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

This version number will not change in subsequent versions of this draft, unless there is a behavior change that breaks compatibility.

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 The values below were chosen randomly.

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

HKDF Labels

• RFC Editor's Note: Please ensure that the strings in quotes are not split up in a line break in this section.

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, and 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 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 follow 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, that 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, or vice versa. 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 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 either reasonably certain the server supports it, or 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 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 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 This document requests that IANA add the following entry to the QUIC version registry maintained at <>.

Value:

0x6b3343cf

Status:

permanent

Specification:

This Document

Change Controller:

IETF

Contact:

QUIC WG

Value:

0x709a50c4

Status:

provisional

Specification:

This Document

Change Controller:

IETF

Contact:

QUIC WG

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. 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 chose is unacceptable. This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version. Optionally, if the client's chosen version and the negotiated version share a compatible first flight format, the negotiation can take place without incurring an extra round trip. This document updates RFC 8999. 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. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes loss detection and congestion control mechanisms for QUIC. Informative References The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. This document defines the properties of the QUIC transport protocol that are common to all versions of the protocol. This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration. 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. This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios.

Sample Packet Protection This section shows examples of packet protection so that implementations can be verified incrementally. Samples of Initial packets from both 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 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. This example 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 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 Christian Huitema, Lucas Pardue, Kyle Rose, Anthony Rossi, Zahed Sarker, David Schinazi, Tatsuhiro Tsujikawa, and Martin Thomson for their helpful suggestions.

Changelog

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

since draft-ietf-quic-v2-08

• Updated IANA considerations in accordance with new constants

since draft-ietf-quic-v2-07

• Generated new constants and test vectors

since draft-ietf-quic-v2-06

• Clients MUST NOT use TLS resumption tickets across versions
• Servers SHOULD support multiple versions
• Clients SHOULD check path support for QUIC independently by version
• Minor editorial changes

since draft-ietf-quic-v2-05

• Servers MUST use the negotiated version in Initials with CRYPTO frames.
• Clarified when clients "learn" the negotiated version as required in the VN draft.
• Comments from SECDIR review.

since draft-ietf-quic-v2-04

• Clarified 0-RTT handling
• Editorial comments from Zahed Sarker.

since draft-ietf-quic-v2-03

• a v2 session ticket is an indication of v2 support
• a v1-only extension is theoretically possible
• editorial fixes

since draft-ietf-quic-v2-02

• Editorial comments from Lucas Pardue

since draft-ietf-quic-v2-01

• Ban use of NEW_TOKEN tokens across versions
• version-info transport parameter required for all v2 endpoints
• Explicitly list known ALPN compatibility

since draft-ietf-quic-v2-00

• Expanded requirements for compatible version negotiation
• Added test vectors
• Greased the packet type codepoints
• Random version number
• Clarified requirement to use QUIC-VN
• Banned use of resumption tokens across versions

since draft-duke-quic-v2-02

• Converted to adopted draft
• Deleted references to QUIC improvements
• Clarified status of QUIC extensions

since draft-duke-quic-v2-01

• Made the final version number TBD.
• Added ALPN considerations

since draft-duke-quic-v2-00

• Added provisional versions for interop
• Change the v1 Retry Tag secret
• Change labels to create full key separation