]> Apple Inc.

tpauly@apple.com

Akamai

kondtir@gmail.com

Security Oblivious HTTP Application Intermediation Internet-Draft This document defines a parameter that can be included in SVCB and HTTPS DNS resource records to denote that a service is accessible as an Oblivious HTTP target, along with one or more oblivious key configurations. About This Document Status information for this document may be found at . Discussion of this document takes place on the Oblivious HTTP Application Intermediation Working Group mailing list (), which is archived at .

Introduction Oblivious HTTP allows clients to encrypt messages exchanged with an HTTP server accessed via a proxy, in such a way that the proxy cannot inspect the contents of the message and the target HTTP server does not discover the client's identity. In order to use Oblivious HTTP, clients need to possess a key configuration to use to encrypt messages to the oblivious target. Since Oblivious HTTP deployments will often involve very specific coordination between clients, proxies, and targets, the key configuration can often be shared in a bespoke fashion. However, some deployments involve clients discovering oblivious targets more dynamically. For example, a network may want to advertise a DNS resolver that is accessible over Oblivious HTTP and applies local network resolution policies via mechanisms like Discovery of Designated Resolvers (. Clients can work with trusted proxies to access these target servers. This document defines a mechanism to distribute Oblivious HTTP key configurations in DNS records, as a parameter that can be included in SVCB and HTTPS DNS resource records . The presence of this parameter indicates that a service is an oblivious target; see for a description of oblivious targets. This mechanism does not aid in the discovery of proxies to use to access oblivious targets; the configurations of proxies is out of scope for this document.

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.

The ohttp-configs and ohttp-path SvcParamKeys The "ohttp-configs" SvcParamKey is used to convey one or more key configurations that can be used by clients to issue oblivious requests to a target server described by the SVCB record. In wire format, the value of the parameter is one or more KeyConfig structures concatenated together. In presentation format, the value is the same concatenated KeyConfig structures encoded in Base64 . The meaning of the "ohttp-configs" parameter depends on the scheme of the SVCB record. This document defines the interpretation for the "https" and "dns" schemes. Other schemes that want to use this parameter MUST define the interpretation and meaning of the configuration. The "ohttp-path" SvcParamKey is used to convey the URI path of the oblivious target to which oblivious HTTP requests can sent. In both wire format and presentation format, this is a UTF-8 encoded string that contains the path segment of a URI. If this path parameter is not present, oblivious requests can be made to the root "/" path.

Use in HTTPS service records For the "https" scheme, which uses the HTTPS RR type instead of SVCB, the presence of the "ohttp-configs" parameter means that the service being described is an Oblivious HTTP service that uses the default "message/bhttp" media type . When present in an HTTPS record, the "ohttp-configs" MUST be included in the mandatory parameter list, to ensure that implementations that do not understand the key do not interpret this service as a generic HTTP service. Clients MUST validate that they can parse the value of "ohttp-configs" as a valid key configuration before attempting to use the service.

Use in DNS server SVCB records For the "dns" scheme, as defined in , the presence of the "ohttp-configs" parameter means that the DNS server being described is an Oblivious DNS over HTTP (DoH) service. The default media type expected for use in Oblivious HTTP to DNS resolvers is "application/dns-message" . The "ohttp-configs" parameter is only defined for use with DoH, so the "alpn" SvcParamKey MUST indicate support for a version of HTTP and the "dohpath" SvcParamKey MUST be present. The "ohttp-configs" MUST also be included in the mandatory parameter list, to ensure that implementations that do not understand the key do not interpret this service as a generic DoH service. Clients MUST validate that they can parse the value of "ohttp-configs" as a valid key configuration before attempting to use the service.

Use with DDR Clients can discover an oblivious DNS server configuration using DDR, by either querying _dns.resolver.arpa to a locally configured resolver or querying using the name of a resolver . In the case of oblivious DNS servers, the client might not be able to directly use the verification mechanisms described in , which rely on checking for known resolver IP addresses or hostnames in TLS certificates, since clients do not generally perform TLS with oblivious targets. A client MAY perform a direct connection to the oblivious target server to do this TLS check, however this may be impossible or undesirable if the client does not want to ever expose its IP address to the oblivious target. If the client does not use the standard DDR verification check, it MUST use some alternate mechanism to verify that it should use an oblivious target. For example, the client could have a local policy of known oblivious target names that it is allowed to use, or the client could coordinate with the oblivious proxy to either have the oblivious proxy check the properties of the target's TLS certificate or filter to only allow targets known and trusted by the proxy. Clients also need to ensure that they are not being targeted with unique key configurations that would reveal their identity. See for more discussion.

Use with DNR The SvcParamKeys defined in this document also can be used with Discovery of Network-designated Resolvers (DNR) . In this case, the oblivious configuration and path parameters can be included in DHCP and Router Advertisement messages. While DNR does not require the same kind of verification as DDR, clients still need to ensure that they are not being targeted with unique key configurations that would reveal their identity. See for more discussion.

Handling Oblivious DoH Configurations Oblivious DoH was originally defined in . This version of Oblivious DoH uses a different key configuration format than generic Oblivious HTTP. SVCB records using the "dns" scheme can include one or more ObliviousDoHConfig structures using the "odoh-configs" parameter. In wire format, the value of the "odoh-configs" parameter is one or more ObliviousDoHConfigs structures concatenated together. In presentation format, the value is the same structures encoded in Base64 . All other requirements for "ohttp-configs" in this document apply to "odoh-configs".

Deployment Considerations Deployments that add the "ohttp-configs" SvcParamKey need to be careful to add this only to services meant to be accessed using Oblivious HTTP. Information in a single SVCB record that contains "ohttp-configs" only applies to the oblivious service, not other HTTP services. If a service offers both traditional HTTP and oblivious HTTP, these can be represented by separate SVCB or HTTPS records, both with and without the "ohttp-configs" SvcParamKey.

Security and Privacy Considerations When discovering designated oblivious DNS servers using this mechanism, clients need to ensure that the designation is trusted in lieu of being able to directly check the contents of the target server's TLS certificate. See for more discussion. As discussed in , client requests using Oblivious HTTP can only be linked by recognizing the key configuration. In order to prevent unwanted linkability and tracking, clients using any key configuration discovery mechanism need to be concerned with attacks that target a specific user or population with a unique key configuration. There are several approaches clients can use to mitigate key targetting attacks. provides an analysis of the options for ensuring the key configurations are consistent between different clients. Clients SHOULD employ some technique to mitigate key targetting attack. One mitigation specific to this mechanism is validating that SVCB or HTTPS records including the "oblivious-configs" are protected by DNSSEC . This prevents attacks where a unique response is generated for each client of a resolver.

IANA Considerations IANA is requested to add the following entry to the SVCB Service Parameters registry ().

Number	Name	Meaning	Reference
TBD	ohttp-configs	Oblivious HTTP key configurations	(This document)
TBD	ohttp-path	Oblivious HTTP request path	(This document)
TBD	odoh-configs	Oblivious DoH key configurations	(This document)

References Normative References 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. Apple Inc. Apple Inc. Cloudflare Fastly Microsoft This document defines Discovery of Designated Resolvers (DDR), a mechanism for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. This mechanism can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. This mechanism is designed to be limited to cases where unencrypted resolvers and their designated resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an encrypted resolver is known. 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. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Google LLC The SVCB DNS record type expresses a bound collection of endpoint metadata, for use when establishing a connection to a named service. DNS itself can be such a service, when the server is identified by a domain name. This document provides the SVCB mapping for named DNS servers, allowing them to indicate support for new transport protocols. Mozilla Cloudflare This document defines a binary format for representing HTTP messages. 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. Orange Akamai Citrix Systems, Inc. Open-Xchange Microsoft The document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS servers (e.g., DNS-over-HTTPS, DNS-over- TLS, DNS-over-QUIC). Particularly, it allows to learn an authentication domain name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS servers. Informative References Apple Inc. Fastly Apple Inc. Cloudflare Cloudflare This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH) messages. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers. This experimental protocol is developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation. Brave Software The Tor Project Mozilla Cloudflare This document describes the key consistency and correctness requirements of protocols such as Privacy Pass, Oblivious DoH, and Oblivious HTTP for user privacy. It discusses several mechanisms and proposals for enabling user privacy in varying threat models. In concludes with discussion of open problems in this area. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]