Subject: [dtn] Robert Wilton's No Objection on draft-ietf-dtn-bpsec-25: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Thu, 03 Dec 2020 04:28:04 -0800

Robert Wilton has entered the following ballot position for
draft-ietf-dtn-bpsec-25: 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 IESG DISCUSS and COMMENT positions.

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

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

Thank you for this document, this is somewhat outside of my area of expertise
and has previously been reviewed by the IESG.

A couple of minor comments related to section 3.6:

(1) When reading section 3.6, I was questioning whether explicit or arbitrary
length CBOR arrays were used.  I found that this behavior was only clarified
once I got to section 4.  From a document structure perspective, I wonder
whether it wouldn't be better for section 4 to be part of section 3.

(2) In some places, I was surprised that a CBOR array is used in place of a
CBOR map.  E.g., both in the Security Context Parameters and the Security
Results.  Is there a reason why CBOR arrays was chosen here over maps?

3) For security context flags, it states: "Implementations MUST set reserved
bits to 0 when writing this field".  However, I find that somewhat confusing
given how CBOR encodes integers and only encodes what is required and
effectively leaves out all most significant 0 bits from the encoding.  Perhaps
this text could be clarified?

Regards,
Rob

---

From: "Birrane, Edward J." <[email-masked]>
Date: Sun, 13 Dec 2020 19:53:54 +0000

Robert,

  Thank you for the read and comments.  My comments are in-line below and I have numbered them as [C#] for reference.

-Ed

---
Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839

> -----Original Message-----
> From: Robert Wilton via Datatracker <[email-masked]>
> Sent: Thursday, December 03, 2020 7:28 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; Scott
> Burleigh <[email-masked]>; [email-masked]
> Subject: [EXT] Robert Wilton's No Objection on draft-ietf-dtn-bpsec-25: (with
> COMMENT)
> 
> Thank you for this document, this is somewhat outside of my area of
> expertise and has previously been reviewed by the IESG.
> 

[C1] I agree that there should be some mention of CBOR encoding to help with processing section 3.6. I am a little hesitant to move the entire canonicalization section before 3.6 since an understanding of the security block structure is helpful to understanding section 4 as well.

Would it make things clearer if I added the following to the start of 3.6:

"The encoding of these fields MUST be in accordance with the canonical forms described in Section 4."

> Results.  Is there a reason why CBOR arrays was chosen here over maps?

[C2] If I recall correctly, there were three reasons that we did not use maps.  

The first reason is that there is no requirement that CBOR map entries be ordered. Changing the ordering of map elements at waypoints could break integrity mechanisms over things like parameters and results.

The second reason is that a security context may support multiple instances of the same parameter or the same result. For example, a bib-integrity security context could have a parameter for a key, and have 3 or 4 instances of that parameter. A security context could also define a single result type such as "signature" and have 3-4 instances of that signature such that if any match that which is calculated at a local node bib-integrity would be considered verified.  In either case, I don't believe that a CBOR map allows multiple instances of the same key.

The third reason was that we did not see a compelling space savings between maps and arrays.

> this text could be clarified?

[C3] If I recall correctly there were 2 concerns that this requirement was meant to address.

The first is that if an application did not zero the internal structure used to store these values, reserved bits could go uninitialized. In that case, the issue is creating too large an encoding because what should be leading 0's might not be 0.

The second is that the flags field is defined as an unsigned integer (major type 0) which will support a minimum of 5 bits of user data. CBOR cannot represent an unsigned integer in less than 1 byte. Since we only define 2 bits of unreserved flags it is possible that an implementation may try and use 3 bits of reserved bits fields. Forcing all reserved bits to be 0 prevents implementations from abusing reserved flags for implementation-specific purposes.