Question and scope
A telemetry client wants the target service unable to link requests to client identity while the forwarding node cannot read request content. Design the OHTTP client, relay, gateway, and target, covering key discovery, HPKE encapsulation, error handling, replay defense, resource mapping, rate limits, and monitoring.
RFC 9458 standardizes forwarding encrypted HTTP messages: the relay sees the client connection, while the gateway decrypts and calls the target, so neither should independently learn both identity and content. OHTTP is not an anonymous network; message length, timing, relay/gateway collusion, client metadata, and application identifiers still require separate treatment.
What the interviewer is testing
- Define what Client, Relay, Gateway, and Target can see and where trust ends.
- Explain the gateway public key, HPKE request/response encapsulation, and media types.
- Design replay defense, request-size limits, timeouts, and error mapping.
- Handle one-to-one relay/gateway resource mapping, traffic analysis, and collusion risk.
- Handle key rotation, caching, retries, and client clock skew.
- Validate with acceptance, decryption-failure, replay-rejection, latency, and length-distribution metrics.
Questions to clarify first
- Is this one-way telemetry, public reads, or high-value writes? Sensitive writes need stronger authentication and replay controls.
- Are the relay and gateway operated by different parties, or can one organization own both?
- Does the target return different results by user authorization, tenant, or region?
- What are request size, batching window, latency, and loss-tolerance limits?
- May clients rediscover configuration after key expiry, and which log fields must be redacted?
A 30-second answer
I would draw four boundaries: the client connects to the relay, the relay forwards only an encapsulated message, and the gateway decrypts it before calling the target. The client discovers a gateway key configuration and uses HPKE to encapsulate binary HTTP; the response is encapsulated in the reverse direction. The gateway uses a time window, unique request identifier, or application idempotency to reject replays, while the relay limits connection and message resources. Rotate keys with overlap and monitor decryption failures, replay rejection, latency, and length distributions; do not present OHTTP as protection against collusion or traffic analysis.
Step-by-step deep dive
1. Define the four responsibilities
The Client knows the target resource and gateway public key. The Relay knows the client network connection but should not read the encapsulated content. The Gateway decrypts and sends ordinary HTTP to the Target, which sees the gateway as its source. Separate deployment, logs, and access permissions so one party cannot trivially correlate identity and content.
2. Discover and validate key configuration
The client obtains a gateway key configuration containing a key identifier, HPKE algorithms, and a public key. It needs an authenticated source, version, and expiry; reject unsupported algorithms and stale keys. During rotation publish old and new keys together until client caches and request windows have elapsed.
3. Encapsulate request and response
The client encodes a binary HTTP request and encapsulates it with HPKE as a message/ohttp-req payload. The gateway decapsulates and validates method, target resource, size, and content type. It encapsulates the response as message/ohttp-res. The relay should not parse inner HTTP or route based on plaintext status.
Client -- TLS --> Relay -- opaque OHTTP --> Gateway -- HTTP --> Target
Client <-- opaque response -- Relay <-- OHTTP response -- Gateway4. Handle authentication, replay, and idempotency
OHTTP hides network identity; it does not authenticate a business user. For writes, use an application signature, one-time nonce, time window, or idempotency key. The gateway keeps minimal replay-detection state and rejects repeated encapsulated messages. Telemetry batches can carry idempotent event IDs so retries do not double-count.
5. Handle errors and resource mapping
If decapsulation fails, the gateway returns a structured key or encapsulation error without exposing private key details. Target business errors travel back inside an OHTTP response. Relay-to-gateway resource mapping should be fixed and verifiable so a message cannot reach the wrong target. Apply separate limits for timeouts, size, and overload at each layer.
6. Evaluate privacy leakage and traffic analysis
Encryption does not stop the relay seeing client IP, timing, and message lengths, or the gateway seeing request frequency and decrypted application fields. Padding, batching, rate limits, and separated logs can reduce correlation at latency and cost. Do not claim that OHTTP defeats relay/gateway collusion.
7. Canary, monitor, and fall back
Start with a small client cohort and dedicated relay/gateway resources. Track configuration hits, decapsulation success, replay rejection, target 5xx, p95 latency, message-size buckets, and fallback rate. During an incident disable OHTTP narrowly by target or client version; ordinary HTTPS fallback needs a privacy review. Keep configuration IDs, error classes, and request hashes, not inner identity fields.
High-quality sample answer
I would separate client, relay, gateway, and target into four responsibility domains. The client obtains and validates the gateway HPKE key configuration, encapsulates binary HTTP, and sends it to the relay. The relay forwards opaque bytes. The gateway decapsulates, checks size and resource mapping, and calls the target with its own identity; the response is encapsulated on the way back.
OHTTP does not provide business authentication or defeat relay/gateway collusion. Writes therefore need application signatures, nonces, or idempotency keys, with a gateway time-window replay check. Rotate keys with an overlap window and constrain relay connections and message resources. Canary on decapsulation failures, replay rejection, latency, size distribution, and business errors; permit ordinary HTTPS fallback only after an explicit privacy review.
Common mistakes
- Treating the relay as a decrypting proxy → the privacy boundary disappears → let it handle only the outer connection and opaque message.
- Assuming OHTTP authenticates users → the target cannot identify a legitimate business principal → add an application signature or authorization token.
- Ignoring message length and timing → traffic analysis can still correlate requests → use padding and batching while measuring latency cost.
- Retrying writes without idempotency → telemetry double-counts or side effects repeat → use nonces, event IDs, and replay windows.
- Sharing linkable relay and gateway logs → one party can recover identity and content → separate operators, fields, and access permissions.
Follow-up questions and answers
Can OHTTP prevent relay and gateway collusion?
No. The protocol relies on limited trust and operational separation. Colluding parties may correlate connection identity with decrypted content, so organizations, logs, and access controls must remain independent.
How does the gateway prevent replay?
Use a time window, nonce, idempotent event ID, or application signature for writes; keep minimal detection state and reject repeated encapsulated messages. TLS on each connection alone does not prevent cross-connection replay.
Why is resource mapping needed?
A relay should forward an encapsulated request to the intended gateway/target resource. Fixed mapping makes key, policy, rate-limit, and audit boundaries verifiable and prevents delivery to an incompatible gateway.
How do you rotate a gateway public key?
Publish a versioned, expiring new configuration while retaining the old key through cache, batching, and retry windows. Observe hits and decapsulation failures by key ID, then retire the old private key.
Is OHTTP suitable for high-value writes?
Only with caution. It hides network identity but does not replace authentication, authorization, idempotency, or audit. Prove the application principal and replay boundary before accepting its latency and privacy trade-off.
What should monitoring record?
Record configuration ID, relay/gateway resource, error class, request-size bucket, replay rejection, and end-to-end latency. Do not default to logging inner domains, user identifiers, or raw encapsulated content.