Subject: [dtn] Benjamin Kaduk's Yes on draft-ietf-dtn-bpsec-default-sc-10: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Fri, 16 Jul 2021 10:45:31 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dtn-bpsec-default-sc-10: Yes

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/

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

I continue to be impressed with how the DTN WG and authors update their
documents in response to the review comments -- the changes are
carefully thought out and the entire document treated as a whole.  Thank
you!

Looking at the diff from -08 to -10, just a few final remarks:

Sections 3.3.3 and 4.3.4 still have some text about ignoring
unrecognized scope flags, which is not exactly problematic in light of
the (new) text about "MUST NOT be altered" between source and
destination, but it's also unclear how much value it adds.  One might
assume that any new scope flag will change processing in some manner and
thus result in a validation failure if used by the security source and
unrecognized at the security acceptor.

Section 4.5

   The security provided by block ciphers is reduced as more data is
   processed with the same key.  The total number of blocks processed
   with a single key for AES-GCM is recommended to be less than 2^64, as

I suggest s/total number of blocks/total number of AES blocks/ since BP
also deals in (potentially larger) blocks.

Section 4.7.1

   CBOR byte string.  Therefore, the plain text used during encryption
   MUST be calculated as the value of the block-type-specific data field
   of the security target excluding any CBOR encoding.

I think this is already pretty clear, but I'd consider s/any/the BP/,
since the contents of the block-type-specific data field might well be
CBOR encoded themselves, and we don't want to strip any of that
"internal" CBOR encoding.

Section 4.8.2

      The authentication tag MUST be present in the BCB security context
      parameters field.  This tag MUST be 128 bits in length.

I think this still needs a bit of tweaking to handle the case where the
tag is included in the BCB itself instead of as a security parameter,
which §4.8.1 has been nicely adapted to allow.