Apple Inc.

tpauly@apple.com

Nokia

kondtir@gmail.com

sec ohai DNS Oblivious HTTP SVCB This document defines a parameter that can be included in Service Binding (SVCB) and HTTPS DNS resource records to denote that a service is accessible using Oblivious HTTP, by offering an Oblivious Gateway Resource through which to access the target. This document also defines a mechanism for learning the key configuration of the discovered Oblivious Gateway Resource.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
• .  Conventions and Definitions
• .  Applicability
• .  The "ohttp" SvcParamKey
  • .  Use in HTTPS Service RRs
  • .  Use in DNS Server SVCB RRs
    • .  Use with DDR
    • .  Use with DNR
• .  Gateway Location
• .  Key Configuration Fetching
• .  Security and Privacy Considerations
  • .  Key Targeting Attacks
  • .  dohpath Targeting Attacks
• .  IANA Considerations
  • .  SVCB Service Parameter
  • .  Well-Known URI
• .  References
  • .  Normative References
  • .  Informative References
• Authors' Addresses

Introduction Oblivious HTTP allows clients to encrypt messages exchanged with an Oblivious Target Resource (target). The messages are encapsulated in encrypted messages to an Oblivious Gateway Resource (gateway), which offers Oblivious HTTP access to the target. The gateway is accessed via an Oblivious Relay Resource (relay), which proxies the encapsulated messages to hide the identity of the client. Overall, this architecture is designed in such a way that the relay cannot inspect the contents of messages, and the gateway and target cannot learn the client's identity from a single transaction. Since Oblivious HTTP deployments typically involve very specific coordination between clients, relays, and gateways, the key configuration is often shared in a bespoke fashion. However, some deployments involve clients discovering targets and their associated gateways more dynamically. For example, a network might operate a DNS resolver that provides more optimized or more relevant DNS answers and is accessible using Oblivious HTTP, and might want to advertise support for Oblivious HTTP via mechanisms like Discovery of Designated Resolvers and Discovery of Network-designated Resolvers . Clients can access these gateways through trusted relays. This document defines a way to use DNS resource records (RRs) to advertise that an HTTP service supports Oblivious HTTP. This advertisement is a parameter that can be included in Service Binding (SVCB) and HTTPS DNS RRs (). The presence of this parameter indicates that a service can act as a target and has a gateway that can provide access to the target. The client learns the URI to use for the gateway using a well-known URI suffix , "ohttp-gateway", which is accessed on the target (). This means that for deployments that support this kind of discovery, the Gateway and Target Resources need to be located on the same host. This document also defines a way to fetch a gateway's key configuration from the gateway (). This mechanism does not aid in the discovery of relays; relay configuration is out of scope for this document. Models in which this discovery mechanism is applicable are described in .

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.

Applicability There are multiple models in which the discovery mechanism defined in this document can be used. These include:

• Upgrading regular (non-proxied) HTTP to Oblivious HTTP. In this model, the client intends to communicate with a specific target service and prefers to use Oblivious HTTP if it is available. The target service has a gateway that it offers to allow access using Oblivious HTTP. Once the client learns about the gateway, it "upgrades" its requests from non-proxied HTTP to Oblivious HTTP to access the target service.
• Discovering alternative Oblivious HTTP services. In this model, the client has a default target service that it uses. For example, this may be a public DNS resolver that is accessible over Oblivious HTTP. The client is willing to use alternative target services if they are discovered, which may provide more optimized or more relevant responses.

In both of these deployment models, the client is configured with a relay that it trusts for Oblivious HTTP transactions. This relay needs to provide either (1) generic access to gateways or (2) a service to clients to allow them to check which gateways are accessible.

The "ohttp" SvcParamKey The "ohttp" SvcParamKey is used to indicate that a service described in a SVCB RR can be accessed as a target using an associated gateway. The service that is queried by the client hosts one or more Target Resources. In order to access the service's Target Resources using Oblivious HTTP, the client needs to send encapsulated messages to the Gateway Resource and the gateway's key configuration (both of which can be retrieved using the method described in ). Both the presentation and wire-format values for the "ohttp" parameter MUST be empty. Services can include the "ohttp" parameter in the mandatory parameter list if the service is only accessible using Oblivious HTTP. Marking the "ohttp" parameter as mandatory will cause clients that do not understand the parameter to ignore that SVCB RR. Including the "ohttp" parameter without marking it mandatory advertises a service that is optionally available using Oblivious HTTP. Note also that multiple SVCB RRs can be provided to indicate separate configurations. The media type to use for encapsulated requests made to a target service depends on the scheme of the SVCB RR. This document defines the interpretation for the "https" scheme and the "dns" scheme . Other schemes that want to use this parameter MUST define the interpretation and meaning of the configuration.

Use in HTTPS Service RRs For the "https" scheme, which uses the HTTPS RR type instead of SVCB, the presence of the "ohttp" parameter means that the target being described is an Oblivious HTTP service that is accessible using the default "message/bhttp" media type . For example, an HTTPS service RR for svc.example.com that supports Oblivious HTTP could look like this: svc.example.com. 7200 IN HTTPS 1 . ( alpn=h2 ohttp ) A similar RR for a service that only supports Oblivious HTTP could look like this: svc.example.com. 7200 IN HTTPS 1 . ( mandatory=ohttp ohttp )

Use in DNS Server SVCB RRs For the "dns" scheme, as defined in , the presence of the "ohttp" parameter means that the DNS server being described has a DNS-over-HTTPS (DoH) service that can be accessed using Oblivious HTTP. Requests to the resolver are sent to the gateway using binary HTTP with the default "message/bhttp" media type , containing inner requests that use the "application/dns-message" media type . If the "ohttp" parameter is included in a DNS server SVCB RR, the "alpn" parameter MUST include at least one HTTP value (such as "h2" or "h3"). In order for DoH-capable recursive resolvers to function as Oblivious HTTP targets, their associated gateways need to be accessible via a client-trusted relay. DoH recursive resolvers used with the discovery mechanisms described in this section can be either publicly accessible or specific to a network. In general, only publicly accessible DoH recursive resolvers will work as Oblivious HTTP targets, unless there is a coordinated deployment with a relay to access the network-specific DoH recursive resolvers.

Use with DDR Clients can discover that a DoH recursive resolver supports Oblivious HTTP using DDR, by either querying _dns.resolver.arpa to a locally configured resolver or querying using the name of a resolver . For example, a DoH service advertised over DDR can be annotated as supporting resolution via Oblivious HTTP using the following RR: _dns.resolver.arpa 7200 IN SVCB 1 doh.example.net ( alpn=h2 dohpath=/dns-query{?dns} ohttp ) Clients still need to perform verification of oblivious DoH servers -- specifically, the TLS certificate checks described in . Since the Gateway and Target Resources for discovered oblivious services need to be on the same host, this means that the client needs to verify that the certificate presented by the gateway passes the required checks. These checks can be performed when looking up the configuration on the gateway as described in and can be done either directly or via the relay or another proxy to avoid exposing client IP addresses. Opportunistic Discovery , where only the IP address is validated, SHOULD NOT be used in general with Oblivious HTTP, since this mode primarily exists to support resolvers that use private or local IP addresses, which will usually not be accessible when using a relay. If a configuration occurs where the resolver is accessible but cannot use certificate-based validation, the client MUST ensure that the relay only accesses the gateway and target using the unencrypted resolver's original IP address. For the case of DoH recursive resolvers, clients also need to ensure that they are not being targeted with unique DoH paths that would reveal their identity. See for more discussion.

Use with DNR The SvcParamKey defined in this document also can be used with Discovery of Network-designated Resolvers . 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 that learn about DoH recursive resolvers still need to ensure that they are not being targeted with unique DoH paths that would reveal their identity. See for more discussion.

Gateway Location Once a client has discovered that a service supports Oblivious HTTP via the "ohttp" parameter in a SVCB or HTTPS RR, it needs to be able to send requests via a relay to the correct gateway location. This document defines a well-known resource , "/.well-known/ohttp-gateway", which is an Oblivious Gateway Resource available on the same host as the Target Resource. Some servers might not want to operate the gateway on a well-known URI. In such cases, these servers can use 3xx (Redirection) responses () to direct clients and relays to the correct location of the gateway. Such redirects would apply to both (1) requests made to fetch key configurations (as defined in ) and (2) encapsulated requests made via a relay. If a client receives a redirect when fetching the key configuration from the well-known Gateway Resource, it MUST NOT communicate the redirected gateway URI to the relay as the location of the gateway to use. Doing so would allow the gateway to target clients by encoding unique or client-identifying values in the redirected URI. Instead, relays being used with dynamically discovered gateways MUST use the well-known Gateway Resource and follow any redirects independently of redirects that clients received. The relay can remember such redirects across oblivious requests for all clients in order to avoid added latency.

Key Configuration Fetching Clients also need to know the key configuration of a gateway before encapsulating and sending requests to the relay. If a client fetches the key configuration directly from the gateway, it will expose identifiers like a client IP address to the gateway. The privacy and security implications of fetching the key configuration are discussed more in . Clients can use an HTTP proxy to hide their IP addresses when fetching key configurations. Clients can also perform consistency checks to validate that they are not receiving unique key configurations, as discussed in . In order to fetch the key configuration of a gateway discovered in the manner described in , the client issues a GET request (either through a proxy or directly) to the URI of the gateway specifying the "application/ohttp-keys" media type in the Accept header. For example, if the client knows an Oblivious Gateway URI, https://svc.example.com/.well-known/ohttp-gateway, it could fetch the key configuration with the following request: GET /.well-known/ohttp-gateway HTTP/1.1 Host: svc.example.com Accept: application/ohttp-keys Gateways that coordinate with targets that advertise Oblivious HTTP support SHOULD support GET requests for their key configuration in this manner, unless there is another out-of-band configuration model that is usable by clients. Gateways respond with their key configuration in the response body, with a content type of "application/ohttp-keys".

Security and Privacy Considerations Attackers on a network can remove SVCB information from cleartext DNS answers that are not protected by DNSSEC . This can effectively downgrade clients. However, since SVCB indications for Oblivious HTTP support are just hints, a client can mitigate this by always checking for a gateway configuration () on the well-known gateway location (). Using encrypted DNS along with DNSSEC can also provide such a mitigation. When clients fetch a gateway's configuration (), they can expose their identity in the form of an IP address if they do not connect via a proxy or some other IP-hiding mechanism. In some circumstances, this might not be a privacy concern, since revealing that a particular client IP address is preparing to use an Oblivious HTTP service can be expected. However, if a client is otherwise trying to hide its IP address or location (and not merely decouple its specific requests from its IP address), or if revealing its IP address facilitates key targeting attacks (if a gateway service uses IP addresses to associate specific configurations with specific clients), a proxy or similar mechanism can be used to fetch the gateway's configuration. When discovering designated oblivious DoH recursive resolvers using this mechanism, clients need to ensure that the designation is trusted in lieu of being able to directly check the contents of the gateway server's TLS certificate. See for more discussion, as well as Section "Security Considerations" of .

Key Targeting Attacks 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 targeting attacks. provides an overview of the options for ensuring that the key configurations are consistent between different clients. Clients SHOULD employ some technique to mitigate key targeting attacks, such as the option of confirming the key with a shared proxy as described in . If a client detects that a gateway is using per-client targeted key configuration, the client can stop using the gateway and, potentially, report the targeting attack so that other clients can avoid using this gateway in the future.

dohpath Targeting Attacks For oblivious DoH servers, an attacker could use unique "dohpath" values to target or identify specific clients. This attack is very similar to the generic OHTTP key targeting attack described above. A client can avoid these targeting attacks by only allowing a single "dohpath" value, such as the commonly used "/dns-query{?dns}" or another pre-known value. If the client allows arbitrary "dohpath" values, it SHOULD mitigate targeting attacks with a consistency check, such as using one of the mechanisms described in to validate the "dohpath" value with another source. Clients might choose to only employ a consistency check on a percentage of discovery events, depending on the capacity of consistency check options and their deployment threat model.

IANA Considerations

SVCB Service Parameter This document adds the following entry to the "Service Parameter Keys (SvcParamKeys)" registry . This parameter is defined in .

Number	Name	Meaning	Change Controller	Reference
8	ohttp	Denotes that a service operates an Oblivious HTTP target	IETF	RFC 9540,

Well-Known URI IANA has added one entry in the "Well-Known URIs" registry .

URI Suffix:

ohttp-gateway

Change Controller:

IETF

Reference:

RFC 9540

Status:

permanent

Related Information:

N/A

References Normative References This document defines a binary format for representing HTTP messages. This document defines Discovery of Designated Resolvers (DDR), a set of mechanisms for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An Encrypted DNS Resolver discovered in this manner is referred to as a "Designated Resolver". These mechanisms can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. These mechanisms are designed to be limited to cases where Unencrypted DNS 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 DNS Resolver is known. This document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS, and DNS over QUIC). Particularly, it allows a host to learn an Authentication Domain Name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers. The SVCB DNS resource 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 encrypted transport protocols. 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. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages. Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages. 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 specifies the "SVCB" ("Service Binding") 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 are extensible to support future uses (such as 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 (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. Informative References Brave Software The Tor Project Mozilla Cloudflare This document describes the consistency requirements of protocols such as Privacy Pass, Oblivious DoH, and Oblivious HTTP for user privacy. It presents definitions for consistency and then surveys mechanisms for providing consistency in varying threat models. In concludes with discussion of open problems in this area. Work in Progress 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]

Authors' Addresses Apple Inc.

tpauly@apple.com

Nokia

kondtir@gmail.com