Bundle Protocol Security Specification

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

Benjamin Kaduk (was Discuss) Yes

Comment (2020-12-02 for -25)
No email
send info
All my previous comments seem to be addressed.

Section 8

I still really like the security considerations section here, and want
to retain my note that it is well-thought-out, from my previous ballot

Alvaro Retana No Objection

Comment (2020-02-06 for -18)
No email
send info
I support Ben's DISCUSS.

Erik Kline No Objection

Comment (2020-12-02 for -25)
Send comments for wrong document; withdrawing in the only way I know how.  My apologies.

Martin Duke (was Discuss) No Objection

Martin Vigoureux No Objection

Murray Kucherawy No Objection

Comment (2020-12-02 for -25)
The shepherd writeup, last updated over a year ago, indicates a possible IPR issue that the WG was investigating at that time.  Was this resolved?

Quite a lot of text changed in this document between the last time it came to the IESG and now, including some new normative text, but the document history doesn't show anything about a second last call either in the WG or in the IETF generally.  Should there have been one?

Robert Wilton No Objection

Comment (2020-12-03 for -25)
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?


Roman Danyliw No Objection

Comment (2020-02-03 for -18)
** Section 2.  Per “The application of security services in a DTN is a complex endeavor that must consider …”, the current and future threat environment is also a needed consideration.

** Section 3.6, Please explicitly state that the values of this ID should come from the registry defined in Section 11.2.

** Section 3.7.  Per “The Security Context Id MUST utilize an end-to-end authentication cipher or an end-to-end error detection cipher.”, what is a “end-to-end” in this context?

** Section 4.  “Reserved flags  MUST NOT be included in any canonicalization as it is not known if those flags will change in transit.”, to which protocol fields is this “reserved flags” referring to?

** Section 8.2.1.  Please add text to note that irrespective of whether BPSec is used, traffic analysis will be possible

** Section 8.2.4.  Per “With these attacks Mallory's objectives may vary, but may be targeting either the bundle protocol or application-layer protocols conveyed by the bundle protocol.”, please add that the target could also be the storage and compute of the nodes running the bundle or application layer protocols (e.g., a denial of service to flood on the storage of the store-and-forward mechanism; or compute which would process the packets and perhaps prevent other activities)

** Editorial Nits
-- Section 3.8.  Editorial nit.  Section 3.7 uses a bulleted list for the properties of the block.  Here there are no bullets.

-- Section 3.8.  Per “The determination of where to place these data is a function of the cipher suite and security context used” -- s/place these data/place this data/

-- Section 5.1.1 and 5.1.2. s/be be treated/be treated/

-- Section 8.2.2. Expand the IND-CCA2 acronym.

Warren Kumari No Objection

Éric Vyncke No Objection

Comment (2020-02-06 for -18)
Thank you for the work put into this document. 

I hope that this helps to improve the document,



-- Section 2.3 --
  "a waypoint node, representing a
   gateway to an insecure portion of the DTN, may receive the bundle and
   choose to apply a confidentiality service"
how could the bundle destination could recover the plain text if there is no security association with the encrypting waypoint? Or is it simple hop-by-hop encryption ?

-- Section 3.2 --
Why not supporting multiple integrity-checks/signatures? After all, this would allow the support of more than 1 integrity check / signature algorithm? (Obvioulsy, this cannot be done for confidentility -- except if transmitting multiple copies). There are some text related to this in section 3.7.

-- Section 8.2.4 --
More details about anti-replay of a DTN message would be welcome. E.g., is the bundle age field used ?

-- Section 9.2 --
This section is a list of issues with BPsec but are there other WG items attempting to solve those issues ? draft-ietf-dtn-bpsec-interop-sc does not seem to cover those issues.

(Mirja Kühlewind; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2020-02-03 for -18)
Sec 1.2 says:
"A sample security
   context has been defined ([I-D.ietf-dtn-bpsec-interop-sc]) to support
   interoperability testing and serve as an exemplar for how security
   contexts should be defined for this specification."
However I don't really understand how interoperability can be reached if there is not at least one security context that is mandatory to implement in this draft (especially as ietf-dtn-bpsec-interop-sc is expired for more than half a year already)...?

(Magnus Westerlund; former steering group member) Yes

Yes ( for -17)
No email
send info

(Adam Roach; former steering group member) No Objection

No Objection ( for -18)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection (2020-02-06 for -18)
I support Mirja's and Benjamin's DISCUSSes.

Please respond to the Gen-ART review.

In Section 3.8:

"o  It is RECOMMENDED that designers carefully consider the effect of
      setting flags that either discard the block or delete the bundle
      in the event that this block cannot be processed.

   o  The BCB block processing control flags can be set independently
      from the processing control flags of the security target(s).  The
      setting of such flags SHOULD be an implementation/policy decision
      for the encrypting node."
Both of these uses of normative language seem inappropriate.

(Barry Leiba; former steering group member) No Objection

No Objection (2020-02-05 for -18)
I support Ben’s DISCUSS and comments.

— Section 1.4 —
Please use the current BCP 14 boilerplate from RFC 8174, and add a normative reference to that RFC.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -18)
No email
send info

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -18)
No email
send info