Timing residual: held-path network DID resolution exceeds the #35 rejection floor (response ≫ floor ⇒ held)

[moisesja]

Summary

Residual timing side-channel surfaced by the #35 red-team and intentionally not closed by the #35
fix (the constant-time rejection floor). Filing it as a first-class issue so it has its own lifecycle,
per PR #43 review — the mitigation guidance currently lives only in the ReceiveRejectionFloor XML doc
and the CHANGELOG, where an operator searching issues won't find it.

Category: timing side-channel / information disclosure (held-recipient-key enumeration)
Severity: High (deployment-dependent; fully mitigable with auth / rate-limiting in front of the endpoint)

What #35 closed, and what it didn't

#35 added a constant-time floor on the HTTP 400-rejection path
(DidCommReceiveOptions.ReceiveRejectionFloor, default 5 ms). A fixed floor can only mask failures that
finish under it. It closes the cheap, universal probe — garbage ciphertext to a guessed kid, where
unheld fast-fails (~180 µs) and held + AEAD-fail (~360 µs) both pad to the floor.

It does not close the held-only path that decrypts and then performs network DID resolution
(authcrypt sender authorization / FR-CONSIST-06 / from_prior), which can run longer than any sane
fixed floor. Network latency is unbounded, so no fixed floor value closes it without being absurd.

Exploit

An unauthenticated attacker who knows candidate recipient public keys (they appear in DID documents):

1. Builds an authcrypt envelope addressed to a guessed recipient kid, signed as an
   attacker-controlled did:webvh (or any method whose resolution the attacker can stall).
2. Submits it to the receive endpoint and times the response.
   • Unheld recipient kid: decryption fast-fails before any resolver call → response ≈ floor.
   • Held recipient kid: decryption succeeds → the unpack pipeline resolves the attacker-controlled
     sender DID, which the attacker makes deliberately slow (up to the resolver timeout) → response
     visibly ≫ floor, then a uniform 400 (consistency/auth fail).
3. response ≫ floor ⇒ held. The attacker enumerates which recipient private keys the agent holds, and
   amplifies the signal arbitrarily by controlling the resolver delay.

This is reachable today because the held path performs the sender-DID resolution synchronously before
the response is produced.

Why a fixed floor can't fix it

To mask a held path that takes T_resolve, the floor would have to be ≥ T_resolve for every request
(including unheld ones) — but T_resolve is attacker-controlled and unbounded. That is not a viable
default.

Mitigations / candidate fixes (for discussion)

• Operational (available now, recommended): put authentication and/or a rate-limiter in front of the
  receive endpoint so unauthenticated enumeration probing is not possible / is rate-bounded. This is the
  deployment tradeoff Timing side-channel on HTTP receive enables recipient-kid enumeration (residual of #20) #35 calls out and what the ReceiveRejectionFloor doc currently points to.
• Bound the receive-path resolver: apply a small, fixed per-request resolution timeout on the
  receive path and fold it into the floor budget, so the held path cannot be stalled past a known
  ceiling. Tradeoff: breaks legitimately-slow resolvers; needs care.
• Decouple resolution from the response: acknowledge/reject before the network-dependent consistency
  checks, doing resolution-dependent validation out of band. Larger architectural change; changes
  semantics (a message that later fails consistency would already have been 202'd).
• Warm/constant-time resolver cache with a constant-time miss. Partial; doesn't help a cold cache.

References

• Timing side-channel on HTTP receive enables recipient-kid enumeration (residual of #20) #35 (the timing side-channel + the shipped constant-time rejection floor)
• Tracking: upstream constant-time JWE recipient selection (root cause of #35) #42 (upstream JweParser constant-time recipient selection — the local-crypto gap; distinct from
  this network-resolution residual)
• PR fix(security): close HTTP receive timing side-channel (#35) #43 (the Timing side-channel on HTTP receive enables recipient-kid enumeration (residual of #20) #35 fix; this residual is documented on ReceiveRejectionFloor and in the CHANGELOG)

Filed per PR #43 review (the "Finding 2" residual).

[moisesja]

Disposition: closing as not planned — documented, deployment-mitigable residual; not a library-layer defect to fix

This is a real residual and the analysis stands. It is being closed because it is not closable at the library layer without an unacceptable trade-off, and it is fully and routinely mitigable operationally — which is the accepted disposition. Closing (rather than leaving open indefinitely) keeps the record honest while preserving it as a searchable, documented reference (GitHub indexes closed issues), which was the reason #43's review asked to file it as a first-class issue in the first place.

The residual, restated

On the HTTP receive path the JWE decrypt is constant-work (held vs. unheld are indistinguishable in time and failure shape). But a successful decrypt then performs synchronous network DID resolution for sender authorization (FR-CONSIST-06 / from_prior), and the sender DID is attacker-supplied. So:

• unheld recipient kid → decrypt fast-fails → response ≈ the rejection floor;
• held recipient kid → decrypt succeeds → resolves the attacker's DID → response = decrypt + T_resolve.

An attacker authcrypts to a guessed kid signed as an attacker-run did:webvh they make arbitrarily slow, and reads response ≫ floor ⇒ held, enumerating which recipient private keys the agent holds. Because that resolution is synchronous-before-response, the same trick is a resource-exhaustion vector (the dos tag).

Why it is out of scope for a library-layer fix

1. It is inherent to live sender-authorization. Any DIDComm substrate that validates the sender against a live DID document, for a DID method whose resolution an attacker can stall (did:web/did:webvh), has this property. It is a property of "verify authorization by resolving an attacker-influenced DID," not a bug in this implementation.
2. A fixed floor cannot mask it. The Timing side-channel on HTTP receive enables recipient-kid enumeration (residual of #20) #35 rejection floor only pads failures that finish under it; T_resolve is unbounded and attacker-driven. Masking it would require a floor ≥ an absurd value applied to every request (including the success path, currently never padded) — itself a latency/DoS amplifier. Not a viable default.
3. The only full library-layer close changes receive semantics. Decoupling resolution from the response (respond on the constant-work decrypt + local checks, run network-dependent validation and gated dispatch out of band) does close the timed channel, but a 202 would no longer imply consistency/auth passed. That is a larger architectural change with its own trade-offs and is not warranted when a standard operational control neutralizes the threat.

Why operational mitigation is the right disposition

The realistic threat is an unauthenticated, unthrottled, public receive endpoint. Putting authentication and/or a rate-limiter in front of the endpoint removes the enumeration probe and bounds the DoS — the same control any public ingest endpoint needs regardless of this channel. This library is a messaging substrate; the receive endpoint's exposure is a deployment decision the operator owns. This is the guidance #35 already shipped.

What is closed (so the boundary is clear)

• Timing side-channel on HTTP receive enables recipient-kid enumeration (residual of #20) #35 — constant-time rejection floor — closes the cheap, universal probe (garbage ciphertext to a guessed kid: unheld fast-fail and held+AEAD-fail both pad to the floor).
• dataproofs#12, consumed via Opaque (non-extractable) signing & key agreement: let DIDComm crypto delegate to a keystore (HSM/KMS) instead of returning private JWKs #45 — the JWE decrypt is now constant-work, closing the local-crypto recipient-selection gap (Tracking: upstream constant-time JWE recipient selection (root cause of #35) #42), distinct from this network-resolution residual.
• WebSocket receive never had the signal (it writes nothing back — no per-message response to time).

So the only remaining vector is the deployment-dependent, attacker-amplifiable network-resolution tail on a public unauthenticated endpoint — exactly what auth / rate-limiting neutralizes.

Where it stays documented

• DidCommReceiveOptions.ReceiveRejectionFloor XML docs (the LIMITATION paragraph).
• CHANGELOG.md (the Timing side-channel on HTTP receive enables recipient-kid enumeration (residual of #20) #35 "Red-team Finding 2" entry).
• This closed issue.

Reopen criteria

Reopen if a deployment ever requires a public, unauthenticated, timing-safe receive endpoint (no auth / rate-limiter possible). The path then is the Tier-2 decouple-resolution-from-response change, accepting the 202 = received, not yet validated semantics (consistent with the one-way FR-TRN-10 reading) and a fixed receive-path resolution timeout to bound the out-of-band work.