Subject: [dtn] Martin Duke's Discuss on draft-ietf-dtn-bpsec-default-sc-08: (with DISCUSS and COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Fri, 25 Jun 2021 13:20:42 -0700

Martin Duke has entered the following ballot position for
draft-ietf-dtn-bpsec-default-sc-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec-default-sc/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

There are several references to the possibility that the AES-GCM API doesn't
allow for separation of the tag from the cipher text. I have not heard of
products with this API but will accept that they exist. But I'm confused as to
the handling of this case:

(4.4.1) says the tag MUST be CBOR encoded and (4.8.1) says the tag MUST be
reported in the security result; but how is this possible if the tag is not
extractable from the ciphertext?

Moreover, shouldn't there be a parameter or a scope flag somewhere that tells
the receiver if the tag is in the cipher text? It would be hard to discern the
sender's API a priori!

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(4.5) Does "the total number of bytes processed" by AES-GCM include just
plaintext, or also the associated data?

(6.5) If a security block is cryptographically bound to a bundle, it
      cannot be processed even if the security block and target both
      coexist in the fragment.  This is because fragments have different
      primary blocks than the original bundle.

This should point out that it only applies if the primary block is part of the
AAD.

(A.4.4.1) It looks like the BIB data is simply a copy of the payload data, and
therefore incorrect. I didn't check to see if this leads to incorrect values
for the products of these inputs.