BPSec Default Security Contexts
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)
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 ?