Discovery of Oblivious Services via Service Binding Records

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 8 April 2024.¶

Copyright Notice

Copyright (c) 2023 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.¶

Table of Contents

1. Introduction

Oblivious HTTP [OHTTP] 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 ([DDR]) and Discovery 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 HTTP service supports Oblivious HTTP. This advertisement is a parameter that can be included in SVCB and HTTPS DNS RRs [SVCB] (Section 4). 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 [WELLKNOWN], "ohttp-gateway", which is accessed on the target (Section 5). 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 (Section 6).¶

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 Section 3.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Applicability

There are multiple models in which the discovery mechanism defined in this document can be used.¶

• 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 deployment models, the client is configured with a relay that it trusts for Oblivious HTTP transactions. This relay either needs to provide generic access to gateways, or provide a service to clients to allow them to check which gateways are accessible.¶

4. The ohttp SvcParamKey

The "ohttp" SvcParamKey is used to indicate that a service described in an 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 Section 6).¶

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" [SVCB] and "dns" [DNS-SVCB] schemes. Other schemes that want to use this parameter MUST define the interpretation and meaning of the configuration.¶

svc.example.com. 7200  IN HTTPS 1 . ( alpn=h2 ohttp )

svc.example.com. 7200  IN HTTPS 1 . ( mandatory=ohttp ohttp )

_dns.resolver.arpa  7200  IN SVCB 1 doh.example.net (
     alpn=h2 dohpath=/dns-query{?dns} ohttp )

5. 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 ([WELLKNOWN]), "/.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 (Section 15.4 of [HTTP]) to direct clients and relays to the correct location of the gateway. Such redirects would apply both to requests made to fetch key configurations (as defined in Section 6) and to 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.¶

6. 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 Section 7. 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 Section 7.1.¶

In order to fetch the key configuration of a gateway discovered in the manner described in Section 5, the client issues a GET request (either through a proxy or directly) to the URI of the gateway specifying the "application/ohttp-keys" ([OHTTP]) 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".¶

7. Security and Privacy Considerations

Attackers on a network can remove SVCB information from cleartext DNS answers that are not protected by DNSSEC [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 (Section 6) on the well-known gateway location (Section 5). Use of encrypted DNS along with DNSSEC can also be used as 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 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 Section 4.2.1 for more discussion, as well as the Security Considerations of [DNS-SVCB].¶

8. IANA Considerations

Authors' Addresses