F5 Networks, Inc.

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. Over time, it may also serve as a vehicle for needed protocol design changes. Discussion of this work is encouraged to happen on the QUIC IETF mailing list or on the GitHub repository which contains the draft: . 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 QUIC has numerous extension points, including the version number that occupies the second through fifth octets 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 octets always being 0x00000001. Furthermore, version 1 Initial packets are encrypted with keys derived from a universally known salt, which allow observers to inspect the contents of these packets, which include the TLS Client Hello and Server Hello messages. Again, middleboxes may 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 initial 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 only change is a tweak to the inputs of some crypto derivation functions to enforce full key separation. Any endpoint that supports two versions needs to implement version negotiation to protect against downgrade attacks. This document may, over time, also serve as a vehicle for other needed changes to QUIC version 1. is a more robust, but much more complicated, proposal to address these ossification problems. By design, it requires incompatible version negotiation. QUICv2 enables exercise of compatible version negotiation mechanism.

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 .

Changes from QUIC Version 1 QUIC version 2 endpoints MUST implement the QUIC version 1 specification as described in , , and , with the following changes:

• The version field of long headers is TBD. Note: Unless this document is published as an RFC, implementations should use the provisional value 0xff010001, which might change with each edition of this document.
• The salt used to derive Initial keys in Sec 5.2 of changes to

• The labels used in to derive packet protection keys (Sec 5.1), header protection keys (Sec 5.4), Retry Integrity Tag keys (Sec 5.8), and key updates (Sec 6.1) 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 9.6 of that document.
• The key and nonce used for the Retry Integrity Tag (Sec 5.8 of ) change to:

Version Negotiation Considerations QUIC version 2 endpoints SHOULD also support QUIC version 1. Any QUIC endpoint that supports multiple versions MUST fully implement to prevent version downgrade attacks. Note that version 2 meets that document's definition of a compatible version with version 1. Therefore, v2-capable servers MUST use compatible version negotiation unless they do not support version 1. As version 1 support is more likely than version 2 support, a client SHOULD use QUIC version 1 for its original version unless it has out-of-band knowledge that the server supports version 2.

Ossification Considerations QUIC version 2 provides protection against some forms of ossification. Devices that assume that all long headers will contain 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 firewall 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.

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 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.

IANA Considerations 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

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. 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. Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub repository which contains the draft: https://github.com/quicwg/ version-negotiation/ (https://github.com/quicwg/version- negotiation/). This document describes how Transport Layer Security (TLS) is used to secure QUIC. This document describes loss detection and congestion control mechanisms for QUIC. Informative References This document defines the properties of the QUIC transport protocol that are common to all versions of the protocol. F5 Networks, Inc. The QUIC transport protocol [QUIC-TRANSPORT] 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.

Changelog

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

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