]> Cloudflare

caw@heapingbits.net

General httpbis Internet-Draft This document specifies new criteria under which HTTP/2 clients may reuse connections. It updates . Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction The HTTP/2 connection reuse policy requires is stated as follows: Connections that are made to an origin server, either directly or through a tunnel created using the CONNECT method (Section 8.3), MAY be reused for requests with multiple different URI authority components. A connection can be reused as long as the origin server is authoritative (Section 10.1). For TCP connections without TLS, this depends on the host having resolved to the same IP address. For "https" resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI. The certificate presented by the server MUST satisfy any checks that the client would perform when forming a new TLS connection for the host in the URI. Thus, HTTPS connections require that the target resource hostname resolve to an IP address that matches that of the candidate connection for coalescing. This IP address match ensures that clients connect to the same service. If a server changes IP addresses as a means of mitigating hostname-to-IP bindings, clients are less likely to reuse connections. This can have performance problems, due to requiring an extra connection setup phase, as well as privacy problems. In short, using unauthenticated IP addresses as a signal for connection reuse is fragile. This document relaxes this requirement and introduces another signal based on HTTPS RR answer contents .

Conventions and Definitions 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.

ECH-Based Coalescing Policy The HTTPS RR is a new resource record used for conveying service information about a HTTPS endpoint to clients. Some of this information includes, for example, TLS Encrypted ClientHello (ECH) public key material. The set of hosts behind the same ECH client-facing service provider that share the same ECH and TLS configuration information is referred to as the anonymity set. Client-facing servers SHOULD deploy ECH in such a way so as to maximize the size of the anonymity set where possible. This means client-facing servers should use the same ECH configuration (ECHConfig) for as many hosts as possible. This type of deployment model means that a given ECHConfig uniquely identifies a given service provider. As a result, clients can use it as a signal to determine if a given resource is hosted by the same service provider. Thus, the HTTP/2 connection reuse policy is modified to use this signal as follows:

• Connections that are made to an origin server, either directly or through a tunnel created using the CONNECT method (Section 8.3), MAY be reused for requests with multiple different URI authority components. A connection can be reused as long as the origin server is authoritative (Section 10.1). For TCP connections without TLS, this depends on the host having resolved to the same service provider. Clients may implement this check in one of two ways: (1) by comparing for equality the resolved IP address to that of the original connection, or (2) by comparing for equality the "ech" SvcParamValue in the resolved HTTPS RR answer. For the latter case, the original connection MUST have successfully used the "ech" parameter to negotiate TLS ECH.

HTTP/3 Reuse The HTTP/3 connection reuse policy does not require IP addresses to match. However, as HTTP/3 is based on UDP, some clients may fall back to HTTP/2 over TCP in networks where UDP is blocked or otherwise inoperable. Thus, the policy described in this document only applies to HTTP/2.

Security Considerations Existing coalescing policies do not require IP address authentication via DNSSEC. Thus, an adversary which can spoof A or AAAA responses can equally spoof HTTPS responses and ECHConfigList values.

IANA Considerations This document has no IANA actions.

References Normative References This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. Google Akamai Technologies Akamai Technologies This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP [HTTP]. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/MikeBishop/dns-alt-svc (https://github.com/MikeBishop/dns-alt-svc). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. 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. 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). Informative References Akamai 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. DO NOT DEPLOY THIS VERSION OF HTTP DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC. This version is still a work in progress. For trial deployments, please use earlier versions. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic. Working Group information can be found at https://github.com/quicwg; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-http.

Acknowledgments This document was improved based on feedback from David Benjamin, Tommy Pauly, and Martin Thomson.