Summary

  • RFC 9540 places an empty ohttp parameter in SVCB or HTTPS records, points clients to a same-host /.well-known/ohttp-gateway, and defines how to fetch the gateway’s key configuration.
  • That discovery chain does not select or certify a relay, and each successful step—DNS advertisement, endpoint validation, key retrieval and request completion—proves less than a privacy outcome.
  • A gateway or resolver can issue one client a unique key configuration, redirect or dohpath; consistency evidence must therefore be treated as a separate operational receipt.

The two test devices appeared identical in the deployment dashboard. Both learned that the resolver supported Oblivious HTTP. Both reached the advertised gateway. Both fetched a valid public-key configuration, sent an encrypted query through a relay and received an answer.

Only the captures disagreed. One device had been given a key configuration no other observer could find. The other had received the common configuration. The encryption worked in both cases. The first device was still distinguishable.

That is the most consequential lesson in RFC 9540. The specification, published in February 2024, makes Oblivious HTTP services discoverable through DNS Service Binding records and describes a standard route to gateway key material. It does not pretend that discovery itself creates privacy. Instead, its security sections identify the exact places where an apparently successful rollout can reintroduce identity.

The empty value moves a surprising amount of authority

The new ohttp SvcParamKey has no payload. Its presentation and wire-format values must be empty. Its presence means that the service named by a SVCB or HTTPS record can act as an OHTTP target through an associated gateway.

Empty does not mean trivial. That bit can change which service a client considers usable and how it constructs the next request. If ohttp appears in the record’s mandatory list, a client that does not understand the parameter must ignore that record. If it appears without being mandatory, OHTTP is an optional access path. A publisher can also provide several SVCB records for different configurations.

The receipt is narrow: this DNS answer advertised OHTTP support under these selection rules. It does not prove that OHTTP was used, that the gateway is reachable, that its key is shared with other clients, or that a relay is trustworthy. Cleartext DNS adds another boundary. An on-path attacker can remove SVCB information when DNSSEC does not protect it, producing a downgrade without forging a working OHTTP service. RFC 9540 notes that a client can probe the well-known gateway path and that encrypted DNS combined with DNSSEC can reduce this risk. Neither turns the advertisement into evidence of later behaviour.

Discovery finds the target and gateway, not the relay

OHTTP divides knowledge among three roles. A relay sees the client’s network identity and the gateway destination but should not see the protected message. A gateway removes the OHTTP protection and sees the message, but a properly separated deployment prevents it and the target from learning the client identity from a single transaction. The target supplies the application response.

RFC 9540 helps a client discover a target and its associated gateway. It explicitly leaves relay discovery out of scope. Its applicability models assume that the client already has a relay it trusts—one able either to reach arbitrary gateways or to tell clients which gateways it can reach.

This omission is not a defect to conceal. It is an authority boundary. A product team can implement every byte of RFC 9540 and still lack a defensible answer to who selected the relay, what it logs, which gateways it permits, how its jurisdiction affects disclosure, and whether the relay and gateway have a common operator or incentive to correlate records. “Discovered OHTTP” cannot be allowed to swallow those unanswered questions.

One well-known path creates two independent journeys

After seeing ohttp, the client uses /.well-known/ohttp-gateway on the same host as the target. The same-host rule makes the discovery model predictable. It does not require the gateway logic to remain at that literal URI: the server may redirect both configuration fetches and encapsulated requests.

The redirect rule is unusually instructive. If the client receives a redirect while fetching the key configuration, it must not give that redirected URI to the relay. A gateway could otherwise place a unique value in the client’s redirect and recover that identifier when the relay later uses it. Instead, the relay must start from the well-known URI and follow redirects independently. It may remember a redirect shared across clients to avoid repeated latency.

The correct evidence record therefore has two paths. It records what the client observed while obtaining configuration and what the relay independently observed while sending the protected request. Collapsing them into one “final gateway URL” removes the very comparison the protocol uses to resist targeting.

The key fetch occurs before the protected exchange

The client cannot encapsulate a request until it has a gateway key configuration. RFC 9540 defines an HTTP GET to the gateway with Accept: application/ohttp-keys; a participating gateway returns the configuration using that media type.

If the client performs this GET directly, the gateway sees its IP address. That may be acceptable when the goal is merely to separate individual queries from an already known subscriber address. It is not acceptable when the promise includes hiding location or when the observed address lets the gateway choose a client-specific key. A proxy can hide the address during configuration retrieval, but this introduces another actor and another log surface.

More importantly, a valid key is not necessarily a common key. OHTTP traffic can be linked by recognising the configuration under which it was created. A gateway that supplies Alice with key A and everyone else with key B has not broken the cryptography. It has created a cohort of one. RFC 9540 therefore recommends a consistency technique, such as confirming the key through a shared proxy. A client that detects targeted material can leave the gateway and report it.

Consistency is not a cosmetic hardening control. It is the evidence that changes “I received a usable key” into “I have reason to believe this key did not single me out.” Operations must define the comparison population, observation window, acceptable rotation, independent vantage points and response to divergence. Without those parameters, a dashboard label such as key consistent is only another unbounded claim.

A DoH path can be an identifier even when the key is common

For oblivious DNS-over-HTTPS, the configuration includes another targeting surface. A resolver can supply a unique dohpath to a client. The protected request may then be perfectly encrypted while the path acts as a stable name.

RFC 9540 offers two approaches. A client can accept only one pre-known value, such as /dns-query{?dns}, or it can validate arbitrary values against another source using a consistency mechanism. The document allows deployments to sample those checks according to capacity and threat model. Sampling, however, produces sampled evidence. It does not justify a universal statement about unchecked clients.

This is also where Designated Resolver Discovery and Discovery of Network-designated Resolvers must not be blurred. Under DDR, clients still perform the relevant certificate checks for the discovered oblivious DoH service. Under DNR, DHCP or Router Advertisements can carry the parameters and the designation trust model is different. Neither model eliminates the need to detect unique paths. Certificate validity answers who controls the endpoint identity; it does not answer whether that endpoint treated one client differently.

Build a receipt ladder before writing a privacy claim

An operable RFC 9540 service produces several independently useful facts:

  1. a DNS or network-designation source advertised ohttp;
  2. the client understood the parameter and its mandatory status;
  3. the DDR or DNR authority was accepted under a recorded trust model;
  4. the gateway/target endpoint passed the applicable identity checks;
  5. the gateway returned a parseable key configuration;
  6. independent observation found no client-specific key, path or redirect;
  7. an approved relay reached the gateway;
  8. the encapsulated transaction completed; and
  9. the collected evidence supports the deployment’s stated privacy property.

The ladder is deliberately non-monotonic. A higher-numbered event does not repair a missing earlier receipt. A completed request does not retroactively make a designation trustworthy. A common key does not prove relay independence. A certificate does not establish non-collusion. The privacy outcome is a bounded conclusion over several observations, not a flag emitted by the protocol parser.

This discipline makes OHTTP more deployable, not less. It lets an operator say exactly what the system has achieved, locate a failed handoff, and avoid promising anonymity when the architecture only decouples a request from an address. The service advertisement is valuable because it starts a controlled investigation. It is dangerous only when treated as the verdict.

Sources