[dtn] Benjamin Kaduk's Yes on draft-ietf-dtn-bpsec-22: (with COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Fri, 23 October 2020 20:13 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: dtn@ietf.org
Delivered-To: dtn@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 474323A0B1C; Fri, 23 Oct 2020 13:13:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dtn-bpsec@ietf.org, dtn-chairs@ietf.org, dtn@ietf.org, Scott Burleigh <Scott.C.Burleigh@jpl.nasa.gov>, Scott.C.Burleigh@jpl.nasa.gov
X-Test-IDTracker: no
X-IETF-IDTracker: 7.20.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <160348400826.10060.17399934724249341281@ietfa.amsl.com>
Date: Fri, 23 Oct 2020 13:13:28 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/OhUpOcgvtod6V-Y0rYvQ2ORlibo>
Subject: [dtn] Benjamin Kaduk's Yes on draft-ietf-dtn-bpsec-22: (with COMMENT)
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Oct 2020 20:13:28 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-dtn-bpsec-22: Yes 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: ---------------------------------------------------------------------- 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.
- [dtn] Benjamin Kaduk's Yes on draft-ietf-dtn-bpse… Benjamin Kaduk via Datatracker