Subject: [dtn] Éric Vyncke's No Objection on draft-ietf-dtn-bpsec-default-sc-08: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 28 Jun 2021 07:14:36 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-dtn-bpsec-default-sc-08: No Objection

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:
----------------------------------------------------------------------

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 ?

---

From: "Birrane, Edward J." <[email-masked]>
Date: Tue, 29 Jun 2021 22:31:05 +0000

Éric,

  Thank you for the review!

  I have enumerated the COMMENTs below as C# for reference and provided a recommendation for each.

  Please let me know if these recommended actions appropriately address your comments.  

-Ed

---
Edward J. Birrane, III, Ph.D. (he/him/his)
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839
  
> Is the document limited to SHA-2 and AES-GCM ? How can it be extended to
> other crypto algorithms ?

C1: Recommend no change.

Yes, this document is limited to these two security context and its intent was to define two simple, baseline contexts. 

Other documents will exist to define other security contexts, to include a security context for COSE which allows for more flexible definitions (https://datatracker.ietf.org/doc/html/draft-bsipos-dtn-bpsec-cose-06). 

> serialization or message format, so, I do not understand why CBOR encoding
> is required.

C2: Recommend no change.

The BPSec standard, which identifies the security blocks being populated by a security context requires that security contexts specify how a security parameter and a security result be encoded. Section 9.3 of the BPSec document "Authorship" states:

   o  Security Context Parameters.  Security contexts MUST define their
      parameter Ids, the data types of those parameters, and their CBOR
      encoding.

   o  Security Results.  Security contexts MUST define their security
      result Ids, the data types of those results, and their CBOR
      encoding.

> between the reserved and the unassigned bits ? How should they be

C3: Agreed.  

While the text says these should be ignored, language could be added to a -09 specifying that these bits be set to 0 on transmission.

> How should they be processed by any receiver ?

C4: Agreed and fixed by C3. 

In coordination with C3 above, if set to 0 on transmission, this will cause those flags to be ignored by a receiver.

> Why putting the "0x" prefix in  "0x7" but not for "6" in table 2 ?

C5: Agreed. 

This will be corrected in a -09 version of the document.