[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.