Summary

  • RFC 9458 places a relay between a client and a gateway so the relay can know the client's network origin without reading the request, while the gateway can read the request without learning that origin. The privacy property requires the two roles not to be the same entity.
  • Encryption is only one part of the boundary. Cookies, stable account data, unique gateway configurations, reused HPKE contexts, replay behavior, shared logs and timing or size correlation can recreate the link between person and message.
  • Christopher A. Wood's contribution, with co-author Martin Thomson, is best read as an operationally testable separation of knowledge—not a universal anonymity certificate. A deployment must prove independent control, state minimization, key lifecycle, retry safety and a viable anonymity set.

Analysis: a request divided between two witnesses

Imagine a medical application submitting a short, sensitive statement. The access network can already observe the phone's address. The application service needs the statement in plaintext to answer it. Ordinary HTTPS protects the path but still leaves the service able to associate the connection with the content. Oblivious HTTP changes which participant can make that association.

The client first encodes a binary HTTP message and protects it for a gateway using Hybrid Public Key Encryption, or HPKE. It sends the encapsulated request over HTTPS to a relay. The relay knows the client connection and the chosen gateway, but it cannot open the protected message. It forwards the ciphertext over a second HTTPS connection. The gateway opens it and obtains the request, but sees the relay—not the client's network origin. The target receives a request from the gateway, and the response returns through the same divided path.

This is not privacy by asking a server to ignore a field it has already collected. It is privacy by denying any one compliant role the complete observation. The relay has the “who” side of the network event. The gateway has the “what” side of the application event. RFC 9458 is explicit that the relay and gateway cannot be the same entity if its privacy goals are to hold.

That sentence is the architectural centre of the document. It also creates a harder governance question than a cipher-suite selection: what counts as a different entity?

Different hostnames are not evidence of independence. Neither are two cloud accounts controlled by one administrator, two subsidiaries feeding one fraud warehouse, or two vendors whose incident contract permits unrestricted exchange of raw logs. The RFC states the non-collusion requirement; the conclusion that legal, operational and data-control separation must support it is an editorial inference. It is nevertheless the inference an auditor has to test. If origin logs and decrypted-request logs meet in one analytical system, the protocol's missing join has been rebuilt after the fact.

Wood's work is a boundary specification, not borrowed authority

RFC 9458 was published on the Standards Track in January 2024 and names Martin Thomson and Christopher A. Wood as co-authors. The IETF profile captured for this article on 1 September 2026 describes Wood as an Apple engineer working on cryptographic engineering and lists 24 RFCs under his public identity, including RFC 9458. Those are capture-dated facts. They establish neither sole invention nor control over anyone's deployment.

Wood also co-authored a 2022 Cloudflare account of a computer-aided analysis with Jonathan Hoyland. Their Tamarin model examined secrecy, binding, consistency, nonce use and a form of client unlinkability. In the model, an adversary may observe the network and compromise either the relay or gateway, but the two do not collude and client-identifying information is not passed to the gateway.

The result is useful precisely because the assumptions are visible. The analysis argues that an attacker able to connect a known query with the encrypted connection sent to the relay must have compromised both roles. It also says this is not a general proof of indistinguishability. Statistical inference and traffic analysis do not disappear merely because an algebraic trace preserves secrecy.

The public repository makes the modeled claims reproducible in a way a marketing adjective is not. Yet a proof file cannot inspect a production organization's identity system, shared administrators, subpoena path, retention policy, telemetry vendor or low-volume traffic. Formal verification can show that the specified message choreography has certain properties under a threat model. It cannot certify that a deployment actually preserves the threat model.

Wood should therefore be profiled neither as the person who “made HTTP anonymous” nor as an authority whose name transfers confidence to every OHTTP label. His more durable contribution is a standard in which privacy can be located: between two roles, in the refusal to let one observer hold both halves.

The gateway is not the target

Another limit is easy to lose in a simplified diagram. OHTTP authenticates and protects the message between the client and the gateway. It does not establish a direct authenticated channel between the client and the Target Resource. The gateway decapsulates the request, chooses how to reach the target and can dictate the response delivered back to the client.

The client therefore needs a trustworthy way to authorize a gateway for a particular target and authenticate the gateway's key configuration. Key distribution is not administrative plumbing outside the privacy design. Whoever can substitute a configuration can redirect the point at which plaintext appears. A client-specific configuration can also become a stable identifier.

This boundary makes some ordinary assumptions unavailable. A client cannot simply carry direct certificate pinning for the target through an intermediary that terminates the protected OHTTP message. Application designers must state what the gateway is authorized to do, which targets it may contact, how the target accepts gateway traffic and how configuration provenance is checked. If gateway and target are separate origins, that hop needs HTTPS too.

The practical benefit is still considerable: a target can process a request without receiving the client's network address. But the honest claim is narrower than end-to-end target authentication, and that narrowness protects users from a false sense of coverage.

Plaintext can identify its sender

Suppose the relay and gateway never exchange a byte. The request might still contain an account cookie, authorization header, device token, stable pseudonym, rare language combination or value unique to one user. The gateway no longer needs the network address because the application has supplied another name.

RFC 9458 says transport unlinkability is useful only when the application content does not carry state that links requests. That condition moves substantial privacy work to the client and application team. The team must inspect the encoded binary message, not just a higher-level API description. It must know which defaults, SDK headers, retry tokens and analytics fields cross the boundary.

Removing cookies while issuing a unique OHTTP key configuration to every device solves nothing. Every active client configuration partitions the anonymity set. A configuration seen only once behaves like a tag, even if the protected messages are cryptographically sound. Configuration distribution needs its own uniformity test: how many clients receive each key set, for how long, and under what regional or account segmentation?

The same principle applies to failures. If an error body includes a stable diagnostic token and the client repeats it, the gateway may connect requests that the transport path otherwise keeps separate. “Stateless” must be demonstrated at the wire representation and across success, retry and error flows.

Freshness is both cryptographic and semantic

OHTTP uses HPKE, standardized in RFC 9180, to create the protection context for an exchange. RFC 9458 requires a fresh context for every request. Reuse is not a small optimization error: it can create linkage and, under relevant failure conditions, expose protected material to the relay.

The client must also treat a retry as a new protected request. A timeout does not prove that the gateway failed to process the first attempt. Automatically replaying a purchase, state change or one-time action can duplicate its effect. Servers and applications must either reject replays or make repeated execution safe. An automatic retry is justified only when the response positively establishes that the request was not processed, and the corrected request still needs fresh HPKE state.

The encapsulated key can help serve as a replay nonce. Date-based freshness can limit a replay window, but it introduces clocks, acceptance windows and retention decisions. RFC 8470 supplies related HTTP replay vocabulary; it does not relieve the OHTTP application of choosing idempotency and consequence.

Gateway keys carry a different time risk. OHTTP does not create forward secrecy across the full lifetime of a gateway key configuration. If the private key is later compromised and the adversary has the necessary recorded traffic or relay cooperation, protected exchanges under that configuration may be exposed. Rotation and deletion are not hygiene decorations. They define how much history a future compromise can unlock.

An audit therefore needs issue time, authorized targets, distribution channel, configuration population, expiry, rotation completion and evidence that old private keys were deleted. “Rotation configured” is weaker than a receipt showing the retired material is no longer recoverable from active nodes, backups and incident systems.

HTTPS cannot hide the shape of silence

Both OHTTP transport hops must use HTTPS. This blocks many direct observers from reading or changing the forwarded object. It does not make messages equal in size, simultaneous in time or abundant enough to be indistinguishable.

A client sends a large request at 09:14:03. The relay forwards one unusually large object, and the gateway receives it a moment later. In a low-volume service, an observer with a view of both sides may correlate the event without decrypting anything. Repeated sizes, burst patterns, response lengths and message boundaries add further clues.

Padding can reduce size leakage. Delays, batching or jitter can blur timing. Each measure costs latency, bandwidth and operational simplicity. A service that advertises strong unlinkability while disabling padding during congestion needs to treat that change as a privacy decision, not an invisible performance toggle.

The relay itself can influence the anonymity set. Selective blocking, prioritization or abuse treatment can isolate one client or one class of traffic. A signal shared for fraud defence may become the bridge the protocol tried to remove. Operators need to measure the active population behind each configuration and relay path, not merely the number of registered clients.

This is where an encryption dashboard fails. It can show that every request used HPKE and both hops used TLS while missing that only one person sent a particular message size in a five-minute window. Cryptographic success and anonymity health are different metrics.

The evidence package the architecture deserves

An OHTTP review should begin with a four-column ownership map: client, relay, gateway and target. For each role, record the legal controller, infrastructure account, administrators, subcontractors, locations, logs, retention periods, incident access and analytics destinations. Then mark every place two columns can be joined.

The relay receipt should show that it does not add client-identifying Via or Forwarded fields, that raw origin logs are minimized, and that forwarding or abuse decisions cannot covertly tag a request. The gateway receipt should show key ownership, target authorization, plaintext logging limits and deletion. A common security team is not automatically fatal, but its access must be designed so an incident does not casually grant the one complete view ordinary operation denies.

The client receipt should inventory content. Test cookies, credentials, account values, device identifiers, locale combinations, error tokens and library-added headers on the actual encoded request. Confirm a fresh HPKE context for first attempts and retries. Measure how configurations are shared across a population.

The application receipt should state replay semantics. Which operations are naturally idempotent? Which require a server nonce or deduplication record? Which error confirms non-processing? How long is replay state retained, and does that state itself become a persistent identifier?

Finally, the privacy report needs traffic measurements: population per configuration, request and response size distributions, padding policy, delay policy, low-volume windows, outage routing and differential treatment. Red-team exercises should test a relay compromise, gateway compromise, shared administrator, common log warehouse and external observer separately. Each obtains a different part of the picture.

The running-code primacy advanced by Heng Lu supplies the right discipline. Credit the system for the deterministic separation it actually executes, not for a symbolic statement that two boxes are “independent.” Minimum Initial Specification adds a complementary warning: a small common mechanism can invite broad adoption, but adoption is valuable only when local operators preserve the assumptions that made the mechanism coherent.

Privacy as an inability, maintained on purpose

Most control programmes inventory what systems are able to do. OHTTP requires an inventory of what each system must remain unable to do. The relay must be unable to read the message. The gateway must be unable to recover the client's network origin. The target must not receive it by an accidental header. The analytics plane must not reassemble both sides. The application must not insert a substitute identity.

That inability is fragile because every operational convenience pushes in the other direction. Shared observability promises easier debugging. Unique configurations promise targeted rollout. Stable tokens promise reliable retries. Unpadded traffic promises speed. A single provider promises simpler procurement. Each benefit may be legitimate, but each spends part of the privacy boundary.

RFC 9458 makes the trade visible. Christopher A. Wood's contribution is not a claim that encryption has solved anonymity. It is a design in which the missing join can be named, tested and defended. The strongest deployment report will not say “we use OHTTP.” It will show why no one operator can answer both questions at once: who sent this, and what did they say?

Sources