| RFC 9540 | Oblivious Services in SVCB | February 2024 |
| Pauly & Reddy.K | Standards Track | [Page] |
This document defines a parameter that can be included in Service Binding (SVCB) and HTTPSDNS resource records to denote that a service is accessible using ObliviousHTTP, by offering an Oblivious Gateway Resource through which to access thetarget. This document also defines a mechanism for learning the key configurationof the discovered Oblivious Gateway Resource.¶
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 athttps://www.rfc-editor.org/info/rfc9540.¶
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 (https://trustee.ietf.org/license-info) 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.¶
Oblivious HTTP[OHTTP] allows clients to encryptmessages exchanged with an Oblivious Target Resource (target). The messagesare encapsulated in encrypted messages to an Oblivious Gateway Resource(gateway), which offers Oblivious HTTP access to the target. The gateway isaccessed via an Oblivious Relay Resource (relay), which proxies the encapsulatedmessages to hide the identity of the client. Overall, this architecture isdesigned 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 singletransaction.¶
Since Oblivious HTTP deployments typically involve very specific coordinationbetween clients, relays, and gateways, the key configuration is often sharedin a bespoke fashion. However, some deployments involve clientsdiscovering targets and their associated gateways more dynamically.For example, a network might operate a DNS resolver that provides more optimizedor more relevant DNS answers and is accessible using Oblivious HTTP, and mightwant to advertise support for Oblivious HTTP via mechanisms like Discovery ofDesignated Resolvers[DDR] andDiscovery of Network-designated Resolvers[DNR].Clients can access these gateways through trusted relays.¶
This document defines a way to use DNS resource records (RRs) to advertise that an HTTPservice supports Oblivious HTTP. This advertisement is a parameter that can be included inService Binding (SVCB) and HTTPS DNS RRs[SVCB] (Section 4).The presence of this parameter indicates that a service can act as a target andhas a gateway that can provide access to the target.¶
The client learns the URI to use for the gateway using a well-knownURI suffix[WELLKNOWN], "ohttp-gateway", which is accessed onthe target (Section 5). This means that for deployments thatsupport this kind of discovery, the Gateway and Target Resources need tobe located on the same host.¶
This document also defines a way to fetch a gateway's keyconfiguration from the gateway (Section 6).¶
This mechanism does not aid in the discovery of relays;relay configuration is out of scope for this document. Models in whichthis discovery mechanism is applicable are described inSection 3.¶
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[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
There are multiple models in which the discovery mechanism definedin 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 andprefers to use Oblivious HTTP if it is available. The target servicehas a gateway that it offers to allow access using ObliviousHTTP. Once the client learns about the gateway, it "upgrades"its requests from non-proxied HTTP to Oblivious HTTP to accessthe target service.¶
Discovering alternative Oblivious HTTP services. In this model,the client has a default target service that it uses. Forexample, this may be a public DNS resolver that is accessible overOblivious HTTP. The client is willing to use alternativetarget services if they are discovered, which may provide moreoptimized or more relevant responses.¶
In both of these deployment models, the client is configured witha relay that it trusts for Oblivious HTTP transactions. Thisrelay needs to provide either (1) generic access to gateways or(2) a service to clients to allow them to check which gatewaysare accessible.¶
The "ohttp" SvcParamKey is used to indicate that aservice described in a SVCB RR can be accessed as a targetusing an associated gateway. The service that is queried by the client hostsone or more Target Resources.¶
In order to access the service's Target Resources using Oblivious HTTP, the clientneeds to send encapsulated messages to the Gateway Resource and the gateway'skey configuration (both of which can be retrieved using the method described inSection 6).¶
Both the presentation and wire-format values for the "ohttp" parameterMUST be empty.¶
Services can include the "ohttp" parameter in the mandatory parameterlist if the service is only accessible using Oblivious HTTP. Markingthe "ohttp" parameter as mandatory will cause clients that do notunderstand the parameter to ignore that SVCB RR.Including the "ohttp" parameter without marking it mandatory advertisesa service that is optionally available using Oblivious HTTP. Note alsothat multiple SVCB RRs can be provided to indicate separateconfigurations.¶
The media type to use for encapsulated requests made to a target servicedepends on the scheme of the SVCB RR. This document defines theinterpretation for the "https" scheme[SVCB] and the "dns" scheme[DNS-SVCB]. Other schemes that want to use this parameterMUST define theinterpretation and meaning of the configuration.¶
For the "https" scheme, which uses the HTTPS RR type instead of SVCB,the presence of the "ohttp" parameter means that the targetbeing described is an Oblivious HTTP service that is accessible usingthe default "message/bhttp" media type[OHTTP][BINARY-HTTP].¶
For example, an HTTPS service RR for svc.example.com that supportsOblivious 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 HTTPcould look like this:¶
svc.example.com. 7200 IN HTTPS 1 . ( mandatory=ohttp ohttp )¶
For the "dns" scheme, as defined in[DNS-SVCB], the presence ofthe "ohttp" parameter means that the DNS server beingdescribed has a DNS-over-HTTPS (DoH) service[DOH] that canbe accessed using Oblivious HTTP. Requests to the resolver are sent tothe gateway using binary HTTP with the default "message/bhttp"media type[BINARY-HTTP], containing inner requests that use the"application/dns-message" media type[DOH].¶
If the "ohttp" parameter is included in a DNS server SVCB RR,the "alpn" parameterMUST include at least one HTTP value (such as "h2" or"h3").¶
In order for DoH-capable recursive resolvers to function as Oblivious HTTP targets, theirassociated gateways need to be accessible via a client-trusted relay.DoH recursive resolvers used with the discovery mechanisms describedin this section can be either publicly accessible or specific to anetwork. In general, only publicly accessible DoH recursive resolvers will workas Oblivious HTTP targets, unless there is a coordinated deploymentwith a relay to access the network-specific DoH recursive resolvers.¶
Clients can discover that a DoH recursive resolver supports Oblivious HTTP usingDDR, by either querying _dns.resolver.arpa to a locally configuredresolver or querying using the name of a resolver[DDR].¶
For example, a DoH service advertised over DDR can be annotatedas 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 inSection 4.2 of [DDR].Since the Gateway and Target Resources for discovered oblivious servicesneed to be on the same host, this means that the client needs to verifythat the certificate presented by the gateway passes the required checks.These checks can be performed when looking up the configuration on the gatewayas described inSection 6 and can be done either directlyor via the relay or another proxy to avoid exposing client IP addresses.¶
Opportunistic Discovery[DDR], where only the IP address is validated,SHOULD NOT be used in general with Oblivious HTTP, since this modeprimarily exists to support resolvers that use private or local IPaddresses, which will usually not be accessible when using arelay. If a configuration occurs where the resolver is accessible butcannot use certificate-based validation, the clientMUST ensurethat the relay only accesses the gateway and target usingthe unencrypted resolver's original IP address.¶
For the case of DoH recursive resolvers, clients also need to ensure that they are notbeing targeted with unique DoH paths that would reveal their identity. SeeSection 7 for more discussion.¶
The SvcParamKey defined in this document also can be used with Discoveryof Network-designated Resolvers[DNR]. In thiscase, the oblivious configuration and path parameters can be includedin DHCP and Router Advertisement messages.¶
While DNR does not require the same kind of verification as DDR, clientsthat learn about DoH recursive resolvers still need to ensure that they are not beingtargeted with unique DoH paths that would reveal their identity. SeeSection 7for more discussion.¶
Once a client has discovered that a service supports Oblivious HTTPvia the "ohttp" parameter in a SVCB or HTTPS RR, it needs to beable to send requests via a relay to the correct gateway location.¶
This document defines a well-known resource[WELLKNOWN],"/.well-known/ohttp-gateway", which is an Oblivious Gateway Resourceavailable 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(Section 15.4 of [HTTP]) to direct clients and relays to the correctlocation of the gateway. Such redirects would apply to both (1) requestsmade to fetch key configurations (as defined inSection 6) and(2) encapsulated requests made via a relay.¶
If a client receives a redirect when fetching the key configuration from thewell-known Gateway Resource, itMUST NOT communicate the redirectedgateway URI to the relay as the location of the gateway to use.Doing so would allow the gateway to target clients by encodingunique or client-identifying values in the redirected URI. Instead,relays being used with dynamically discovered gatewaysMUST use thewell-known Gateway Resource and follow any redirects independently ofredirects that clients received. The relay can remember such redirectsacross oblivious requests for all clients in order to avoid added latency.¶
Clients also need to know the key configuration of a gateway before encapsulatingand sending requests to the relay.¶
If a client fetches the key configuration directly from the gateway, itwill expose identifiers like a client IP address to the gateway. Theprivacy and security implications of fetching the key configuration arediscussed more inSection 7. Clients can use an HTTP proxy tohide their IP addresses when fetching key configurations. Clients canalso perform consistency checks to validate that they are not receivingunique key configurations, as discussed inSection 7.1.¶
In order to fetch the key configuration of a gateway discoveredin the manner described inSection 5, the client issues a GET request(either through a proxy or directly) to the URI of the gateway specifyingthe "application/ohttp-keys" media type[OHTTP] 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 thekey configuration with the following request:¶
GET /.well-known/ohttp-gateway HTTP/1.1Host: svc.example.comAccept: application/ohttp-keys¶
Gateways that coordinate with targets that advertise Oblivious HTTPsupportSHOULD support GET requests for their key configuration in thismanner, unless there is another out-of-band configuration model that isusable by clients. Gateways respond with their key configuration in theresponse body, with a content type of "application/ohttp-keys".¶
Attackers on a network can remove SVCB information from cleartext DNSanswers that are not protected by DNSSEC[DNSSEC]. Thiscan effectively downgrade clients. However, since SVCB indicationsfor Oblivious HTTP support are just hints, a client can mitigate this byalways checking for a gateway configuration (Section 6)on the well-known gateway location (Section 5).Using encrypted DNS along with DNSSEC can also provide such a mitigation.¶
When clients fetch a gateway's configuration (Section 6),they can expose their identity in the form of an IP address if they do notconnect via a proxy or some other IP-hiding mechanism. In some circumstances,this might not be a privacy concern, since revealing that a particularclient IP address is preparing to use an Oblivious HTTP service can beexpected. However, if a client is otherwise trying to hide its IPaddress or location (and not merely decouple its specific requests from itsIP address), or if revealing its IP address facilitates key targeting attacks(if a gateway service uses IP addresses to associate specific configurationswith specific clients), a proxy or similar mechanism can be used to fetchthe gateway's configuration.¶
When discovering designated oblivious DoH recursive resolvers using this mechanism,clients need to ensure that the designation is trusted in lieu ofbeing able to directly check the contents of the gateway server's TLScertificate. SeeSection 4.2.1 for more discussion, as well as Section 8 ("Security Considerations") of[DNS-SVCB].¶
As discussed in[OHTTP], client requests using Oblivious HTTPcan only be linked by recognizing the key configuration. In order toprevent unwanted linkability and tracking, clients using any keyconfiguration discovery mechanism need to be concerned with attacksthat target a specific user or population with a unique key configuration.¶
There are several approaches clients can use to mitigate key targetingattacks.[CONSISTENCY] provides an overviewof the options for ensuring that the key configurations are consistent betweendifferent clients. ClientsSHOULD employ some technique to mitigate keytargeting attacks, such as the option of confirming the key with a sharedproxy as described in[CONSISTENCY]. If a client detects that a gatewayis using per-client targeted key configuration, the client can stop usingthe gateway and, potentially, report the targeting attack so that otherclients can avoid using this gateway in the future.¶
For oblivious DoH servers, an attacker could use unique"dohpath" valuesto target or identify specific clients. This attack is very similar tothe 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}" oranother pre-known value. If the client allows arbitrary"dohpath"values, itSHOULD mitigate targeting attacks with a consistency check,such as using one of the mechanisms described in[CONSISTENCY] to validate the"dohpath" value with another source. Clients might choose to onlyemploy a consistency check on a percentage of discovery events,depending on the capacity of consistency check options and theirdeployment threat model.¶
This document adds the following entry to the "Service Parameter Keys (SvcParamKeys)" registry[SVCB]. This parameter is defined inSection 4.¶
| Number | Name | Meaning | Change Controller | Reference |
|---|---|---|---|---|
| 8 | ohttp | Denotes that a service operates an Oblivious HTTP target | IETF | RFC 9540,Section 4 |