Summary

  • A 27 October individual Internet-Draft proposes that a BPSec receiver name the authoritative security source and key for each required service on each target block. A valid block from another legitimate node cannot take that source's place.
  • Its second check binds the primary block to the payload through the payload's own integrity scope. Two separately genuine pieces can otherwise be assembled into a false whole.

A Proper Signature, the Wrong Sender

In a delay-tolerant network, a bundle may cross relays that are trusted to do real work. One of those relays can also possess a genuine security key. That makes an ugly substitution possible: replace the original source's protected content, attach a fresh integrity block under the relay's own key, and present the result to a receiver that asks only whether some legitimate participant made the block. The signature passes. The source claim has quietly changed hands.

RFC 9172 names this insider problem in Section 8.2.2. It permits security operations at different nodes and leaves a deployment's security policy to that deployment. Its suggested source-side construction protects an integrity block under a confidentiality block. Yet a receiver that accepts any authorized source for the outer protection can still be offered a replacement made by a legitimate node. The arithmetic of authentication is sound; the question asked of it is too small.

N. D. S. Gupthaa's 27 October draft moves the decisive check to the acceptor. For every service its local policy requires on a target block, the acceptor records the security source that is authoritative for that service and block, together with the key material bound to that source. A BIB checks integrity; a BCB protects confidentiality. Either block satisfies a required service only when it verifies under the key the receiver recorded for that source. Another node's perfectly valid block fails this test. The test is about this source's authority over this object, not the general reputation of a key holder.

The IETF Datatracker lists revision 00 as an individual Internet-Draft with no RFC stream or IETF endorsement. It proposes receiver rules. The record supplies no named deployment that has adopted them.

The Policy Table Is Where Authority Lives

The draft numbers its receiver conditions R1 through R5. R1 makes the expected security source and key a per-service, per-target fact. R2 refuses substitution by a different source, including a source that is legitimate elsewhere in the network. R3 makes a missing matching block a failed required service. R4 stops privilege from travelling sideways: authorization for a gateway to re-secure one flow does not make that gateway the original source for every other block it handles.

That last rule is governance in protocol clothing. Operators often talk about a relay as “trusted,” as though trust were one universal job title. A relay can be trusted to forward, to add a security service for a specified purpose, or to speak for a source under a defined delegation. Those are separate appointments. A receiver that stores only a list of good keys has built a staff directory where it needed a mandate table.

The draft also treats the Security Source field in a received security block as an untrusted lookup hint. The received object may identify who purports to have made it; it cannot appoint that party as the authority required by local policy. The acceptor has to compare the claim with its pre-existing source-and-key expectation. That order matters. If the incoming block chooses the policy entry that will judge it, verification becomes a ceremony run by the claimant.

The per-source key premise is equally important. RFC 9172's security considerations say a key shared by all nodes makes any legitimate holder effectively privileged for that key. The new draft cannot tell those holders apart with a receiver rule alone. An operator that wants source-specific authority needs distinguishable key custody before it can ask the acceptor to enforce that distinction. Configuration is not a late decorative layer over the cryptography; it determines what the cryptographic result is allowed to mean.

Two Genuine Blocks Can Make One Forgery

The draft's fifth rule concerns a different join. A BIB over a payload and a separate BIB over the bundle's primary block can both be genuine, yet the two blocks can come from different genuine bundles made by the same source. Verifying them independently establishes two isolated facts. It does not establish that this primary block belongs to this payload.

R5 therefore requires the payload's own BIB to include the primary block in its integrity scope. RFC 9173, Section 3.3.3 defines the relevant scope flags: bit 0 covers the primary block, and omitting the parameter invokes the default value 7, which includes that bit. A separate primary-block BIB does not create the missing joint proof. This is the protocol version of finding two authentic pages and assuming they were stapled together at birth.

RFC 9171 defines the bundle structure that makes the distinction operational: the primary block carries bundle-level identity and handling information, while a payload block carries the application data. Integrity is useful only when the receiver knows precisely which fields were bound together by the same protected calculation. The receiver should record the result at that scope, instead of printing one broad green “secure” label over an assembled object.

The Receiver Cannot Outsource Its Judgment to a Seal

The proposed policy has an operational cost. A receiver needs a defensible mapping from flow, target block and required service to expected source and key. Gateway exceptions must be narrow enough to survive handoffs. When the expected block is absent, the receiver must fail the required service rather than accept a nearby signature because the queue is growing and the next contact window is short. Those are configuration and incident-response decisions for the operator that bears the consequences.

The draft says its Tamarin models and configuration checker are an artifact to be published and available on request. The public revision does not contain the models or an observed deployment result. The next fact that would sharpen the operational claim is an inspectable receiver configuration and trace showing R1 through R5 applied to a substituted bundle.

The larger mistake is familiar outside spacecraft. Institutions often let the presence of an accredited participant stand in for authority over a particular decision. Here the same shortcut has bytes, blocks and keys. The relay's seal may be real. The receiving system still has to ask who was entitled to seal this parcel, and whether the parcel it received is the one that was sealed.

Sources