Discovery of Oblivious Services via Service Binding Records
Extracted elements (22)
Relays must follow redirects independently from clients to prevent gateways from encoding unique, client-identifying values in redirect URIs. Relays may cache redirects across all clients to reduce added latency.
The gateway and target are required to be on the same host so that the well-known URI approach works for discovery without requiring additional coordination. This simplifies deployment while enabling dynamic service discovery via DNS SVCB/HTTPS records.
The "ohttp" parameter has an empty value (both presentation and wire format) because its presence alone is sufficient to signal Oblivious HTTP support; no additional configuration is carried in the DNS record itself.
For DDR-discovered oblivious DoH servers, clients must still perform TLS certificate checks as described in Section 4.2 of RFC 9462 (DDR). Since Gateway and Target Resources must be on the same host, the certificate presented by the gateway must pass the required checks.
Both the presentation and wire-format values for the "ohttp" SvcParamKey MUST be empty.
Gateways that coordinate with targets advertising Oblivious HTTP support SHOULD support GET requests for their key configuration using the "application/ohttp-keys" media type, unless another out-of-band configuration model is usable.
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 gateway location, to prevent the gateway from encoding client-identifying values in the URI.
If Opportunistic Discovery is used and the resolver cannot employ certificate-based validation, the client MUST ensure the relay only accesses the gateway and target using the unencrypted resolver's original IP address.
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").
Opportunistic Discovery (DDR mode where only the IP address is validated) SHOULD NOT be used with Oblivious HTTP in general, since local/private IP resolvers will usually not be accessible via a relay.
Relays used with dynamically discovered gateways MUST use the well-known Gateway Resource and follow any redirects independently of redirects that clients received.
When clients fetch a gateway's key configuration directly, they expose their IP address to the gateway. Clients trying to hide their IP or location, or at risk of key targeting attacks, should fetch the configuration via a proxy or other IP-hiding mechanism.
For the "dns" scheme, the "ohttp" parameter means the DNS server has a DoH service accessible via Oblivious HTTP. Requests use binary HTTP with "message/bhttp" wrapping inner requests with "application/dns-message" media type.
For the "https" scheme, the presence of the "ohttp" parameter means the target is an Oblivious HTTP service accessible using the default "message/bhttp" media type. The parameter may be listed as mandatory (causing non-understanding clients to ignore the RR) or optional.
The "ohttp" SvcParamKey is used in SVCB and HTTPS DNS resource records to indicate that a service can be accessed as an Oblivious HTTP target via an associated gateway. Both the presentation and wire-format values for the parameter MUST be empty.
The well-known resource "/.well-known/ohttp-gateway" is defined as the Oblivious Gateway Resource location, accessible on the same host as the Target Resource. Servers may use 3xx redirects to direct clients and relays to the actual gateway location.
To fetch a gateway's key configuration, the client issues a GET request to the gateway URI with an Accept header specifying "application/ohttp-keys". The gateway responds with its key configuration in the body with content type "application/ohttp-keys".
This document registers "ohttp" (number 8) in the IANA "Service Parameter Keys (SvcParamKeys)" registry, with meaning "Denotes that a service operates an Oblivious HTTP target" and IETF as change controller.
This document registers the well-known URI suffix "ohttp-gateway" in the IANA "Well-Known URIs" registry with permanent status and IETF as change controller.
Attackers on a network can strip SVCB records from unprotected DNS answers (lacking DNSSEC), effectively downgrading clients away from Oblivious HTTP. Clients can mitigate this by always checking for gateway configuration at the well-known URI; using encrypted DNS with DNSSEC also mitigates this.
For oblivious DoH servers, unique "dohpath" values can be used to target or identify specific clients (analogous to key targeting). Clients SHOULD either restrict dohpath to a known value or apply a consistency check on discovered dohpath values.
Key targeting attacks occur when a gateway serves unique key configurations to specific clients or populations, enabling linkability. Clients SHOULD employ a technique such as key consistency checks (e.g., confirming the key with a shared proxy per [CONSISTENCY]) to mitigate these attacks.