Your receiver dedupes on an unsigned request-id header while the signature covers only the body — what replay is still possible?

## The defect in one line *Whatever the freshness decision reads must be inside what the signature covers.* A deduplication key outside the signed region is a value the replayer chooses, and a value the replayer chooses can never make the receiver refuse them. ## Walking the attack The receiver's logic looks correct in review: it keeps a set of recently seen request identifiers, refuses a repeat, and verifies the signature before acting. Both checks exist. But they read different bytes. A party holding a copy of the message — and in a partner integration the sender's own operations tooling holds every copy — does the following: keeps the body and its signature exactly as they are, generates a new value for the request-id header, and sends. Verification is computed over the body, so it succeeds. The deduplication lookup is computed over the header, so it misses. Both gates open. The instruction executes a second time, and there is nothing anomalous about the traffic at all: valid key, valid content, valid connection, a request identifier nobody has seen before because it was invented one second ago. Nothing was forged, and nothing was decrypted. The signature was never attacked — it was simply bypassed by moving the part of the message it did not cover. ## The general rule: bind everything the decision depends on A message that must be safe to receive exactly once carries, inside the signed content: - **A unique identifier** for the logical instruction — the value the receiver's memory is keyed on. - **A timestamp or counter** — whichever the receiver enforces, so that age or ordering cannot be edited. - **The intended recipient** — an audience or endpoint identifier. - **The material terms**, obviously: amount, account, action. The recipient field is the one most often missed and it produces a distinct replay. If a signing key is trusted by more than one system — a production and a staging receiver, two regional services, a settlement service and a reporting service — an instruction authorised for one can be presented to the other, and the second receiver's memory contains nothing about it. It refuses nothing because it has never seen this message; it was simply never the addressee. Binding the audience inside the signed content turns that into a verification failure rather than a second execution. The same field is what makes traffic captured from one environment useless in another. ## Why the identifier must identify the instruction, not the transmission There is a second, quieter failure. Suppose the identifier *is* inside the signed content, but the sender generates a fresh one on every transmission attempt. Now the receiver's memory works perfectly and protects nothing, because the sender's own legitimate retry produces a message the receiver has never seen and duly executes. The identifier must be derived from, or fixed to, the logical instruction — one payment, one identifier, however many times it is transmitted. That property is what lets the receiver's memory distinguish *this instruction again* from *a different instruction that happens to look similar*, and it is also what makes a legitimate retry safe rather than doubling the payment. Note the boundary here: how a client chooses and re-uses that value across retries, and the HTTP semantics of retrying safely, is an API design subject in its own right. What belongs to the replay question is narrower and sharper — the value the receiver refuses on must be under the signature, and it must name the instruction rather than the attempt. ## Reviewing an envelope quickly Given a message format, the review is three questions: 1. Draw a line around the bytes the signature covers. Is the deduplication key inside it? 2. Is the freshness input — timestamp or counter — inside it? 3. Is the intended receiver inside it? Any "no" is a replay, and each one has a different flavour: a mutable key means unlimited replay to the same receiver; a mutable timestamp means unlimited lifetime; a missing audience means replay to a *different* receiver that trusts the same key. ## The counter-argument you will hear "But the header is inside TLS, so nobody can change it." That answer confuses the channel with the party. The header is protected against modification *by a third party in transit*; it is entirely under the control of whoever composes the request — and the party replaying already composes requests, legitimately, with a valid client certificate and a valid signature over a body they already hold. Confidentiality of the path does not constrain the endpoints.