Summary

  • The individual Oblivious CoAP draft splits knowledge: a forward proxy can see the client but not its encrypted request, while a gateway reads the request without receiving the client address.
  • Section 7.1 says the proxy or an outside adversary can easily replay a protected request. For non-safe operations, the server can use a first-request encapsulation identifier and later per-context counters to detect repeats.

The middleman does not need to read the letter to mail it twice. That is the tension in Oblivious CoAP, a 28 October individual Internet-Draft. Its proposed relay lets a constrained device hide its identity from the destination. The same relay can copy the encrypted request and send it again. A privacy boundary has moved; the risk of doing an operation twice has not vanished.

In CoAP, small networked devices send requests and receive responses. The draft's examples include DNS over CoAP, anonymous device diagnostics and queries to a resource directory. A client encrypts the original exchange for an oblivious gateway with HPKE, then sends it through a CoAP forward proxy. The proxy sees where the client came from but not the protected content. The gateway can read the content, but the proxy does not pass the client's address along. Those roles need separate control if the split is to keep one actor from joining sender and message.

The scheme borrows the two-role pattern from Oblivious HTTP, with a CoAP-specific option that can track several related messages under one HPKE context. The new draft says a willing gateway is required; this is a proposed path for selected applications, not a universal privacy switch for every CoAP server. More important for an operator, encryption does not stop the relay or an outsider from retransmitting the ciphertext.

Section 7.1 offers two different answers. If the original request uses a genuinely safe method and the server verifies that handling it again is safe, replay can be tolerated. For a request that may change state, the server can detect a duplicate and stop processing it when appropriate. It can recognize the first request of an exchange by the HPKE encapsulated value enc, or a hash of it. For subsequent requests in the same exchange, the integrity-protected OCoAP count can be checked against a replay window associated with the receiving HPKE context. A protected Echo option can add another freshness check.

That is a state-keeping obligation, not a cryptographic flourish. A device can be anonymous to the gateway while the gateway still must remember which protected envelopes it has processed. The draft identifies the tokens for that memory but supplies no measured retention budget, restart behavior or field trial. A diagnostic report sent twice may distort a count; a state-changing request sent twice could repeat an effect. The server must decide which methods are safe, how long to keep replay state and what to do when that state is lost. Calling the transport “oblivious” does not make that operational judgement for it.

The Datatracker record lists an individual Standards Track draft at I-D Exists. The useful test is not only whether the destination fails to identify a device. Send a first encrypted request and a repeated copy through the proxy, then follow with a related request; restart the gateway between attempts. Record whether the action happened once, what replay evidence survived and which actor could still correlate the traffic.