Subject: [dtn] BPSec interop-sc AAD/IPPT

From: Brian Sipos <[email-masked]>
Date: Wed, 23 Dec 2020 18:53:02 +0000

Ed,
I have a couple of points that I came across while comparing the last interoperability context definitions [1] to updates to the COSE context [2]:

  1.  The way the scope of the two contexts in [1] are defined, they really indicate the same configuration but they use that scope slightly differently. One way to explicitly bring the two uses into parity is to have one thing representing the scope data (which COSE calls AAD regardless of its purpose) which is used by the two purposes differently. For integrity, the AAD is concatenated with the target block-type-specific data (BTSD) to produce the IPPT (i.e. IPPT = AAD + BTSD). I think the current definition already behaves this way, but it isn't obvious from the definition that both integrity and confidentiality context use the scope the same way. And isn't obvious that an implementation could share behavior to generate AAD for both integrity and confidentiality.
  2.  Because of the way that the scope data is combined, by simple concatenation of encoded CBOR items, there is ambiguity of how each chunk of AAD/IPPT is sourced. I'm not sure whether this represents an exploitable behavior (because the data contains block type codes) but it's not obvious that there isn't some subtle issue with the current encoding. This is handled in [2] by making the "AAD-structure" a fixed-count (three items for the three scope options) and using array-or-null to disambiguate whether that chunk of the scope is included (as an array) or not (as a null).

I don't think either of these are a critical issue, just things to help add consistency between the contexts.

[1] https://tools.ietf.org/html/draft-ietf-dtn-bpsec-interop-sc-02
[2] https://tools.ietf.org/html/draft-bsipos-dtn-bpsec-cose-04