BPSec Default Security Contexts
draft-ietf-dtn-bpsec-default-sc-11

Note: This ballot was opened for revision 08 and is now closed.

Benjamin Kaduk (was Discuss) Yes

Comment (2021-07-16 for -10)
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.

Zaheduzzaman Sarker Yes

Alvaro Retana No Objection

Erik Kline No Objection

Francesca Palombini (was Discuss) No Objection

Comment (2021-07-13 for -10)
No email
send info
Thank you for addressing my comments.

John Scudder No Objection

Martin Duke (was Discuss) No Objection

Comment (2021-07-09 for -09)
Thanks for addressing my DISCUSS and COMMENTs.

Martin Vigoureux No Objection

Murray Kucherawy (was Discuss) No Objection

Comment (2021-07-15 for -10)
Thanks for the new Section 5.4.  I would suggest not referring to the DTN working group as a review body, as it might not exist forever.  The guidance you publish here should still be valid even after the working group closes.

My original comments, for posterity:

I support Francesca's first DISCUSS point.

Since the shepherd writeup was written earlier this year, six revisions have been posted, the IESG has rotated (so the responsible AD in the writeup has changed), two authors have been added, two new registries were proposed (the writeup claims there are none), and a considerable amount of text has been added or changed.  The current writeup thus feels markedly stale; I suggest that in such situations, the shepherd should consider updating the writeup so that it appears to be more current when it gets to the IESG.

Appendix B could be simplified a bit:

   Amy Alford of the Johns Hopkins University
   Applied Physics Laboratory contributed useful review and analysis of
   these security contexts.

Robert Wilton No Objection

Roman Danyliw No Objection

Comment (2021-06-30 for -08)
Thank you to Christian Huitema for the SECDIR review.

I support the DISCUSS positions of Martin Duke, Francesca Palombini and Benjamin Kaduk whose substantive positions have already noted what would have been my feedback.

** Section 4.5.  Per “The total number of bytes processed with a single key for AES-GCM is recommended to be less than 2^64, as described in Appendix B of [AES-GCM].”  It would also be worth nothing that in additional to the number of process bytes, that there is a limit of 2^32 of invocations with the same key per Section 8.3 of [AES-GCM].

Éric Vyncke No Objection

Comment (2021-06-28 for -08)
Thank you for the work put into this document. 

Special thanks for the doc shepherd write-up about the WG process / consensus. Please note that I did not review the CBOR-encoded examples.

Please find below some non-blocking COMMENT points (but replies would be appreciated).

I hope that this helps to improve the document,

Regards,

-éric

Is the document limited to SHA-2 and AES-GCM ? How can it be extended to other crypto algorithms ?

-- Section 3.3.1 --
Why is the CBOR encoding specified here ? The text says nothing about serialization or message format, so, I do not understand why CBOR encoding is required.

-- Sections 3.3.3 and 4.3.4 ---
Same comment as above but if there is transmission, what is the difference between the reserved and the unassigned bits ? How should they be transmitted ? How should they be processed by any receiver ?

-- Sections 3.3.4 and 4.3.5 --
Why putting the "0x" prefix in  "0x7" but not for "6" in table 2 ?