[dtn] Re: Comments on draft-ietf-dtn-bpsec-cose-15 Section 5.11: a related cascade-ordering hazard

["Sipos, Brian J." <[e-mail]>]

Rick,

I agree that there are many possible situations for using AAD Scope which do not make operational sense. I would rather that the document explain the consequences of doing something ‘bad’ rather than try to examine all the possible ways that ‘bad’ can manifest. But for specific easy-to-check cases like this I see the value in explaining and excluding them separately.

 

I am going to manage your feedback (in the earlier email also) as separate issues/PRs on the draft repository, eventually viewable in [1]. There are already some changes not yet in the datatracker, visible in [2], which include the addition of a new “Operational Considerations” section 5 which could be updated to address some of these issues.

 

Brian S.

 

[1] https://briansipos.github.io/dtn-bpsec-cose/draft-ietf-dtn-bpsec-cose.html

[2] https://author-tools.ietf.org/diff?doc_1=draft-ietf-dtn-bpsec-cose <https://author-tools.ietf.org/diff?doc_1=draft-ietf-dtn-bpsec-cose&url_2=https://briansipos.github.io/dtn-bpsec-cose/draft-ietf-dtn-bpsec-cose.txt> &url_2=https://briansipos.github.io/dtn-bpsec-cose/draft-ietf-dtn-bpsec-cose.txt

 

 

From: Rick Taylor <[e-mail]> 
Sent: Saturday, May 23, 2026 9:04 AM
To: [e-mail]
Cc: [e-mail]
Subject: [EXT] [dtn] Re: Comments on draft-ietf-dtn-bpsec-cose-15 Section 5.11: a related cascade-ordering hazard

 


APL external email warning: Verify sender [e-mail] <mailto:[e-mail]>  before clicking links or attachments

 

Hi all, Brian,

 

A related issue to my earlier mail on Section 5.11 -- it surfaced while

working through the cascading-block-delete path in Hardy. This one

feels like a foot-gun for any implementation doing cascading edits to

BIBs or BCBs, which is more or less every meaningful BPA.

 

 

The hazard

 

Section 2.2.2 allows AAD Scope to reference any block in the bundle via

positive integer keys, including other security blocks (BIB or BCB).

Step 3b of the AAD construction in Section 2.5.1 then pulls in the referenced

block's BTSD when the AAD-btsd flag is set.

 

If one security block's AAD covers another security block's BTSD, and

the latter is re-encrypted (or re-signed) for any reason -- including

the perfectly legitimate cascade-delete path where dropping a target

forces re-encryption of the covering BCB with a fresh IV -- then the

former's AAD bytes change and its verification breaks.

 

Concretely: BCB X has AAD Scope referencing BCB Y with AAD-btsd. The

cascade drops a target covered by BCB Y, which forces re-encryption of

BCB Y (fresh IV -> new BTSD). BCB X is now broken downstream, even

though we have not touched X directly.

 

For implementations doing cascading edits, this creates an ordering

constraint with no obvious way to satisfy it short of building a

dependency graph from AAD Scope references, topologically sorting, and

re-encrypting in dependency order -- with cycle detection and an error

path for ill-formed bundles. That is a lot of machinery for a feature

whose use case is not obvious to me.

 

 

Use case unclear

 

I cannot think of a legitimate reason for one security block to

AAD-cover another security block's BTSD. The metadata case is

different -- binding to the presence and identity of another security

block via AAD-metadata is plausible and is also safe, since metadata

is stable across security operation regeneration. It is specifically

the BTSD case that creates the ordering hazard.

 

If anyone on the list has a use case in mind I am keen to hear it;

otherwise the simplest fix is to disallow it.

 

 

Relationship to existing Section 5.11 text

 

Section 5.11's second SHALL NOT prohibits AAD-btsd references to blocks

"expected to be modified by intermediate nodes during the lifetime of

the containing security operation." This implicitly covers blocks like

Hop Count and Bundle Age -- blocks designed to be modified in transit.

 

Security blocks are not in that category. They are not designed to be

modified in transit. But their BTSD nonetheless changes as a side

effect of normal BPA operations (cascade-delete re-encryption,

re-signing following target-set changes). The existing text doesn't

quite catch this, because the cascade-induced change isn't

"modification in transit" in the conventional sense -- it's an

endogenous consequence of forwarding decisions.

 

A small additional rule makes the prohibition explicit.

 

 

Suggested text, alongside the additions in my earlier mail to Section 5.11:

 

   The AAD Scope parameter SHALL NOT reference any BIB or BCB

   block via a positive integer key with the AAD-btsd flag set.

   References to other security blocks with the AAD-metadata flag

   only are permitted, as block metadata is stable across security

   operation regeneration (whereas BTSD content changes whenever

   the referenced block is re-signed or re-encrypted, including as

   a side effect of cascading block delete).

 

   A security verifier or acceptor that detects an AAD Scope

   reference to a BIB or BCB block with the AAD-btsd flag set

   SHOULD log the violation, and MAY refuse the bundle in

   accordance with local policy.

 

 

For what it's worth on the implementation side: Hardy will enforce

this as part of the same defensive-check pass discussed in the

previous mail. The cascade machinery becomes substantially simpler if

security-block-to-security-block BTSD AAD coverage is ruled out -- no

dependency graph, no topological sort, no cycle detection, and BIBs

and BCBs can be re-encrypted in any order.

 

Cheers,

Rick