]> Google LLC

bemasc@google.com

Transport Multiplexed Application Substrate over QUIC Encryption Internet-Draft HTTP proxies can operate several different kinds of access services. This specification provides a format for identifying a collection of such services. About This Document Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction In HTTP/1.1, forward proxy service was originally defined in two ways: absolute-uri request form (encrypted at most hop-by-hop), and HTTP CONNECT (potentially encrypted end-to-end). Both of these services were effectively origin-scoped: the access service was a property of the origin, not associated with any particular path. Recently, a variety of new standardized proxy-like services have emerged for HTTP. These new services are defined by a URI template or path, allowing distinct instances of the same service type to be served by a single origin. These services include:

• DNS over HTTPS
• CONNECT-UDP
• CONNECT-IP
• Oblivious HTTP

This specification provides a unified format for describing a collection of such access services, and a mechanism for reaching such services when the initial information contains only an HTTP origin.

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.

Format An access service collection is defined by a JSON dictionary containing keys specified in the corresponding registry (). Inclusion of each key is OPTIONAL. The "dns", "udp", and "ip" keys are each defined to hold a JSON dictionary containing the key "template" with a value that is a URI template suitable for configuring DNS over HTTPS, CONNECT-UDP, or CONNECT-IP, respectively. The "ohttp" key contains a dictionary with either or both of these keys:

• "proxy", containing a dictionary with a "template" key indicating the Oblivious Proxy's resource mapping. The template MUST contain a "request_uri" variable indicating the Oblivious Request Resource.
• "request", containing a dictionary with a "uri" key indicating the Oblivious Request Resource and a "key" key conveying its KeyConfig in base64.

If the Access Description is for a general-purpose proxy, all Oblivious Request Resources and Targets (respectively) are presumed to be supported; otherwise the supported Resources and Targets must be understood from context (but see ).

Examples

A proxy with UDP, IP, DNS, and Oblivious HTTP support

An Oblivious DNS over HTTPS service

Discovery from an Origin In cases where the HTTP access service is identified only by an origin (e.g. when configured as a Secure Web Proxy), operators can publish an associated access service collection at the path "/.well-known/access-services", with the Content-Type "application/json". When the "ohttp.request" URI appears in an Access Description at this location, all URIs on this origin (except the Oblivious Request URI) are presumed to be reachable as Oblivious Request Targets. Clients MAY fetch this Access Description and use the indicated services (in addition to any origin-scoped services) automatically. Clients SHOULD use the description only while it is fresh according to its HTTP cache lifetime, refreshing it as needed.

Security Considerations TODO Security

IANA Considerations IANA is requested to open a Specification Required registry entitled "HTTP Access Service Descriptors", with the following initial contents:

Key	Specification
dns	(This document)
udp	(This document)
ip	(This document)
ohttp	(This document)

IANA is requested to add the following entry to the "Well-Known URIs" registry

URI Suffix	Change Controller	Reference	Status	Related Information
access-services	IETF	(This document)	provisional	Sub-registry at (link)

Normative References This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. Google LLC This document describes how to proxy UDP over HTTP. Similar to how the CONNECT method allows proxying TCP over HTTP, this document defines a new mechanism to proxy UDP. It is built using HTTP Extended CONNECT. Apple Inc. Google LLC Google LLC Ericsson Ericsson This document describes a method of proxying IP packets over HTTP. This protocol is similar to CONNECT-UDP, but allows transmitting arbitrary IP packets, without being limited to just TCP like CONNECT or UDP like CONNECT-UDP. Mozilla Cloudflare This document describes a system for the forwarding of encrypted HTTP messages. This allows a client to make multiple requests of a server without the server being able to link those requests to the client or to identify the requests as having come from the same client. 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.

Acknowledgments TODO acknowledge.