Summary: Needs 2 more YES or NO OBJECTION positions to pass.
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)...?
Please use the updated disclaimer in rfc8174.
Section 1.2 This specification addresses neither the fitness of externally- defined cryptographic methods nor the security of their implementation. Completely trusted networks are extremely uncommon. Amongst untrusted networks, different networking conditions and operational considerations require varying strengths of security mechanism. [...] nit/editorial: the transition between the first and second sentences is a bit abrupt. others. It is expected that separate documents will be standardized to define security contexts and cipher suites compatible with BPSec, to include those that should be used to assess interoperability and those fit for operational use in various network scenarios. An nit: it looks like "those" (in "to include those") binds to "security contexts and cipher suites", but neither of those seems like a good fit for "assess interoperability". The latter "those" also seems a bit off. example security context has been defined ([I-D.ietf-dtn-bpsec-interop-sc]) to support interoperability testing and illustrate how security contexts should be defined for this specification. I think some of the other changes made that draft into more than just for testing and illustration (it's mandatory to implement in some cases, IIRC). Section 1.4 o Security Operation - the application of a security service to a security target, notated as OP(security service, security target). For example, OP(confidentiality, payload). Every security operation in a bundle MUST be unique, meaning that a security service can only be applied to a security target once in a bundle. nit: I suggest "a given security service", since different security services targeting the same target can be okay. Section 2.2 The Bundle Protocol allows extension blocks to be added to a bundle at any time during its existence in the DTN. When a waypoint adds a new extension block to a bundle, that extension block MAY have security services applied to it by that waypoint. Similarly, a waypoint MAY add a security service to an existing extension block, consistent with its security policy. nit: IIUC a waypoint could also add a security service to the payload block, so just "an existing block" in the last sentence seems more accurate to me. In cases where the security source and security acceptor are not the bundle source and bundle destination, it is possible that the bundle will reach the bundle destination prior to reaching a security acceptor. [...] (side note) I note that the definition for "Bundle Destination" says that it acts as the security acceptor for every security target in every security block in the bundle it receives, which suggests that the scenario described here should never happen. That said, I think it is wise do leave this text in place as-is! Section 3.7 o Since OP(integrity, target) is allowed only once in a bundle per target, it is RECOMMENDED that users wishing to support multiple integrity signatures for the same target define a multi-signature security context. I know we had talked about this text a bit previously, but I just wanted to check whether the thing that does multi-signatures would be a security *context* or a security block type. Section 3.9 In cases where a security source wishes to calculate both a plain text integrity mechanism and encrypt a security target, a BCB with a security context that generates such signatures as additional security results MUST be used instead of adding both a BIB and then a BCB for the security target at the security source. ["signatures" may be overly specific, as there are other integrity-protection mechanisms possible in principle.] Section 5.1.1 If the security policy of a security-aware node specifies that a node should have applied confidentiality to a specific security target and no such BCB is present in the bundle, then the node MUST process this security target in accordance with the security policy. It is recommended that the node remove the security target from the bundle. [need to check the motivation for this recommendation] Section 5.1.2 If the security policy of a security-aware node specifies that a node should have applied integrity to a specific security target and no such BIB is present in the bundle, then the node MUST process this security target in accordance with the security policy. It is RECOMMENDED that the node remove the security target from the bundle if the security target is not the payload or primary block. If the We should probably be consistent about lowercase vs uppercase "recommended" for BCB/BIB in this situation. Section 7 1. At the time of encryption, a security context can be selected which computes a plain text integrity signature and included as a security context result field. nit: maybe "that is included" or "and includes it"? 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 position. Section 11.2 Carving off a range of values (maybe even all negative 16-bit integers?) for local/site-specific use would probably be useful.
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.
** 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.
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.
I support Ben's DISCUSS.
Thank you for the work put into this document. I hope that this helps to improve the document, Regards, -éric -- Section 2.3 -- About "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.