Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpsec-18: (with DISCUSS and COMMENT)

[Magnus Westerlund <[e-mail]>]

Hi Ed, WG, ADs

To my understandig we would actually have [I-D.ietf-dtn-bpsec-interop-sc] as MTI
unless a usage definition overrides this. This will require some reformulations
in section 9.1. 

Maybe something like the below changes. Please wordsmith, but the intention here
to make it clear that this is the specification you implement unless you have
defined something more appropriate. 

OLD:

9.1.  Mandating Security Contexts

   Because of the diversity of networking scenarios and node
   capabilities that may utilize BPSec there is no one security context
   mandated for every possible BPSec implementation.  For example, a
   security context appropriate for a resource-constrained node with
   limited connectivity may be inappropriate for use in a well-
   resourced, well connected node.

   This does not mean that the use of BPSec in a particular network is
   meant to be used without security contexts for interoperability and
   default behavior.  Network designers must identify the minimal set of
   security contexts necessary for functions in their network.  For
   example, a default set of security contexts could be created for use
   over the terrestrial Internet and required by any BPSec
   implementation communicating over the terrestrial Internet.

   Implementations of BPSec MUST support the mandated security contexts
   of the networks in which they are applied.  If a node serves as a
   gateway amongst two or more networks, the BPSec implementation at
   that node MUST support the union of security contexts mandated in
   those networks.

   BPSec has been designed to allow for a diversity of security contexts
   and for new contexts to be defined over time.  The use of different
   security contexts does not change the BPSec protocol itself and the
   definition of new security contexts MUST adhere to the requirements
   of such contexts as presented in this section and generally in this
   specification.

NEW: 

9.1.  Mandating Security Contexts

   Because of the diversity of networking scenarios and node
   capabilities that may utilize BPSec there is some risk that a single security
context mandated for every possible BPSec implementation is not feasible. For
example, a security context appropriate for a resource-constrained node with
   limited connectivity may be inappropriate for use in a well-
   resourced, well connected node.

   This does not mean that the use of BPSec in a particular network is
   meant to be used without security contexts for interoperability and
   default behavior.  Network designers must identify the minimal set of
   security contexts necessary for functions in their network. For
   example, a default set of security contexts could be created for use
   over the terrestrial Internet and required by any BPSec
   implementation communicating over the terrestrial Internet.

   Implementations of BPSec MUST support the mandated security contexts
   of the networks in which they are applied. Unless the network defines another
security context, implementations MUST implement [I-D.ietf-dtn-bpsec-interop-
sc]. If a node serves as a
   gateway amongst two or more networks, the BPSec implementation at
   that node MUST support the union of security contexts mandated in
   those networks. 

   It is expected that security context specifications as well as the mandatory
to implement security context specification will be updated and changed in the
future. Implementors should monitor the specifications for future updates and
replacements. 

   BPSec has been designed to allow for a diversity of security contexts
   and for new contexts to be defined over time.  The use of different
   security contexts does not change the BPSec protocol itself and the
   definition of new security contexts MUST adhere to the requirements
   of such contexts as presented in this section and generally in this
   specification.

   


Cheers

Magnus


On Mon, 2020-03-02 at 15:54 +0000, Birrane, Edward J. wrote:
> Benjamin,
> 
>   Thank you for the updated comments.  I have posted a new version of BPSec
> (bpsec-21) which I believe addresses the open discusses and comments.
> 
>   My comments are in-line in the text below and prefaced with [EJB#] (EJB1 -
> EJB16).
> 
> -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: Benjamin Kaduk <[e-mail]>
> > Sent: Monday, February 24, 2020 4:58 PM
> > To: Birrane, Edward J. <[e-mail]>
> > Cc: The IESG <[e-mail]>; [e-mail]; Scott Burleigh
> > <[e-mail]>; [e-mail]; [e-mail]
> > Subject: [EXT] Re: Benjamin Kaduk's Discuss on draft-ietf-dtn-bpsec-18:
> > (with
> > DISCUSS and COMMENT)
> > 
> > APL external email warning: Verify sender [e-mail] before clicking
> > links or attachments
> > 
> > Hi Ed,
> > 
> > Sorry for the slow reply -- I had a nice vacation that left me with a lot
> > of stuff to catch up with upon my return.
> > 
> > On Sat, Feb 08, 2020 at 12:20:39AM +0000, Birrane, Edward J. wrote:
> > > Benjamin,
> > > 
> > >   Thank you for the detailed read of BPSEC-18.  I have posted a new
> > > version,
> > 
> > BPSEC-20, which addresses many of the comments and discuss items
> > received for this review.
> > > 
> > >   Specific comments are in-line below.  I have enumerated the Discuss
> > 
> > items as **D# and the comment items as **C# to aid in referencing these
> > points going forward.
> > > 
> > > -Ed
> > > 
> > > 
> > > Edward J. Birrane, III, Ph.D.
> > > Embedded Applications Group Supervisor
> > > Principal Staff, Space Exploration Sector
> > > Johns Hopkins Applied Physics Laboratory
> > > (W) 443-778-7423 / (F) 443-228-3839
> > > 
> > > 
> > > -----Original Message-----
> > > From: Benjamin Kaduk via Datatracker <[e-mail]>
> > > Sent: Wednesday, February 5, 2020 10:16 PM
> > > To: The IESG <[e-mail]>
> > > Cc: [e-mail]; Scott Burleigh
> > 
> > <[e-mail]>; [e-mail];
> > [e-mail]; [e-mail]
> > > Subject: [EXT] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpsec-18: (with
> > 
> > DISCUSS and COMMENT)
> > > 
> > > Benjamin Kaduk has entered the following ballot position for
> > > draft-ietf-dtn-bpsec-18: Discuss
> > > 
> > > 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/
> > > 
> > > 
> > > 
> > > ----------------------------------------------------------------------
> > > DISCUSS:
> > > ----------------------------------------------------------------------
> > > 
> > > I think we need to discuss how this document refers to the level of
> > > security
> > 
> > provided by the network, "insecure network"s or portions thereof, etc..  In
> > the normal RFC 3552 threat model, we assume the entire network is under
> > the control of an attacker.  Any exception to that is going to be treated as
> > a
> > special case (usually only grudgingly so), e.g., if a portion of a network
> > is
> > under administrative control of a single entity and physically controlled as
> > well, or if a network uses MAC-layer security technologies.  I don't think
> > this
> > mindset is well-reflected in the current text.
> > > 
> > > **D1: Section 8 of BPSec does state that it is assumed that the DTN (or
> > 
> > significant portions thereof) are completely under the control of an
> > attacker.
> > I am unsure if you are recommending a change to the normative portions of
> > this document to better reflect this mindset?
> > 
> > Let me see if I can pull out a few places in the text that raised questions
> > for me:
> > 
> > (a) Section 1 says "The BP might be deployed such that portions of the
> > network cannot be trusted, posing the usual security challenges related to
> > confidentiality and integrity."  My expectation would be that having
> > portions of the network that *are* trusted would be the exceptional case,
> > the converse of what this describes.
> 
> [EJB1] Agreed that this can be read to imply a false sense of security. I have
> updated this text in bpsec-21.
> 
> > (b) Section 1.1 notes (correctly) that "Networks in which BPSec may be
> > deployed may have a mixture of security-aware and not-security-aware
> > nodes."  In my mental model this is okay, but I think of such nodes as
> > merely being "dumb routers" that do not create bundles or act as endpoints.
> > I mention this point just to confirm that my mental model is not
> > incomplete.
> 
> [EJB2] This is correct except that a non-security-aware waypoint node could
> drop blocks  that it does not understand how to process, making the selection
> of block processing flags for security blocks important. 
> 
> 
> > (c)  Section 1.2 mentions that "Different networking conditions and
> > operational considerations require varying strengths of security
> > mechanism[...]", which is also true, though to me it conveyed an
> > implication that "trusted networks" would be common.
> 
> [EJB3] I have updated this text to try and avoid this incorrect implication.
> 
> > (d) Section 2 notes that "[t]he application of security services in a DTN
> > is a complex endeavor that must consider physical properties of the
> > network, [...]" again with implication that physically secure networks are
> > common.
> 
> [EJB4] In bpsec-21 I have clarified physical properties are not meant to refer
> to physical security, but other physical characteristics of the network (e.g.,
> connectivity).
> 
> > (e) Section 2.2 discusses a "gateway to an insecure portion of the DTN",
> > implying that there is a companion "secure portion of the DTN".
> > 
> 
> [EJB5] In have updated this text in bpsec-21.
> 
> > (f) New in the -20, Section 9.1 does discuss that (paraphrasing) "just
> > because different networks have different security needs, that doesn't
> > mean
> > that any given network should expect to not use security at all", which
> > does help.  I didn't give much thought as to whether it would help to
> > forward-reference this section from earlier places in the document.
> > 
> > > 
> > > I agree with Mirja that we need more clarity on usable security contexts
> > > for
> > 
> > interoperable implementation.  My suggestion would be to define a security
> > context that is usable for normal Internet hosts over the normal Internet
> > (i.e., not a stressed network) to have as a baseline secure configuration,
> > and
> > customizations for other environments would be treated as deviations from
> > that well-established baseline in terms of algorithms and security
> > strength.  I
> > furthermore note that even after reading draft-ietf-dtn-bpsec-interop-sc I
> > do not have a clear picture of exactly which bytes are used as input to the
> > various cryptographic algorithms and how the output is encoded.  For
> > example, is the block data contents of a target block always going to be a
> > fixed-length bstr?  Can the process of applying protection change whether
> > the #6.24 tag is present?
> > > 
> > > **D2: An updated interoperability security context (draft-ietf-dtn-bpsec-
> > 
> > interop-sc-01) has been uploaded to provide a clearer example of what a
> > security context could look like. I agree that a default, mandatory security
> > context usable for normal Internet hosts would be useful and an appropriate
> > baseline for BPSec deployments that interface with the Internet. I have
> > further added a section (9.1 in BPSEC-20) titled "Mandating Security
> > Contexts" which clarifies our desired approach for security contexts.
> > 
> > An intention to proceed with review/publication of
> > draft-ietf-dtn-bpsec-interop-sc does help a lot here; my previous
> > understanding was that it was just a "point in time snapshot" to aid a
> > particular interoperability test and not intended for publication, so it's
> > good to know otherwise.  I think I can accept an architecture that mandates
> > the security contexts at a network level vs. a protocol level, on the
> > expectation that these networks are going to be actively managed for other
> > reasons.
> 
> [EJB6] Thank you. I have moved the interop security contexts to be a normative
> reference in bpsec-21.
> 
> > 
> > I also see some updates in the -20 ca. § 5.1.1 regarding the interaction of
> > the framing with the security processing.  My question about the #6.24 tag
> > specifically was with respect to the CDDL in bpbis, which has:
> > 
> > block-type-specific-data = bstr / #6.24(bstr)
> > 
> > I don't have a great picture on when that #6.24 tagging would be used.
> > While the current text in bpbis is pretty clear that it would not be
> > included as input to the security operations, I do wonder whether it's
> > allowed to appear or disappear as a result of security processing.
> > Presumably the recipient has to be prepared for either form regardless, so
> > it may not matter very much in practice.
> 
> [EJB7] Tags in BP are optional and can be dropped (or added) at any time which
> is why they should be excluded from overall security processing. If necessary
> we could reiterate that such tags be excluded from canonical forms in this
> specification, but I think the BP spec already states this. 
> 
> > 
> > > I understand the need to provide a defined processing order for message
> > 
> > deprotection (and thus to avoid having the same operation applied to the
> > same target), but I still don't have a clear picture of why we can't define
> > things in such a way that allows (e.g.) nested signatures over the same
> > content block.  I understand the current mechanics where in the abstract
> > model we only can protect a single block at a time (not a combination of
> > blocks), so that blindly applying the current mechanics to an attempt at a
> > nested signature would produce the problematic ambiguity of processing
> > order, but I don't understand why it has to be that way.
> > > 
> > > **D3: The decision to not allow nesting security blocks was a WG decision
> > > -
> > 
> > possibly influenced by (negative) implementation experience with
> > experimental RFC6257. The working group preference is to have fewer
> > security blocks and to migrate complexity into security context
> > specifications.
> > 
> > This is still somewhat surprising to me, though I guess at least most
> > potential use cases could be addressed by a "bundle-in-bundle" encoding,
> > albeit inefficiently.
> 
> [EJB8] In bpsec-21 I added a paragraph under uniqueness that gives some
> rationale for why I believe the WG makes this decision. Agreed that bundle-in-
> bundle encap would enable some use cases. 
> 
> > > Relatedly, I think that the current formulation where the target list can
> > > be
> > 
> > freely modified/split into separate BIB/BCBs by any waypoint will probably
> > leave us open to some semantic attacks that drop some blocks but not
> > others, when there is supposed to be semantic interdependence between
> > those blocks.
> > > 
> > > **D4: It is not required to merge security results into a single security
> > > block
> > 
> > - implementations could choose a 1-1 mapping between security blocks and
> > security targets and for that reason split and combine should not add extra
> > attacks. Malicious nodes that add, drop, or otherwise update blocks will, I
> > think, cause similar problems in either case.
> > 
> > I think there are potential cases where it is important that I either have
> > signed-A and signed-B or none of them (i.e., just having signed-A and
> > either no B or an unsigned B leads to an attack).  Imagine a hypothetical
> > case where we had blocks for "type of external/additional reporting to do"
> > and "recipients for external/additional reporting".  A signed "do email
> > reporting" with a separate unsigned "report to <attacker>" would be pretty
> > risky!  I'm not sure that we want to leave this sort of full-system
> > security analysis as the responsibility of every block-type designer.
> 
> [EJB9] Policy stating which security services need to be combinaed or co-
> present is something that the WG does not want represented in the bundle
> itself.  In Section 8.2.2 (Modification Attacks) the spec states: 
> 
> "In each of these cases, the implementation of BPSec must be combined  with
> policy configuration at endpoints in the network which describe the expected
> and required security operations that must be applied on  transmission and are
> expected to be present on receipt.  This or other similar out-of-band
> information is required to correct for removal of security information in the
> bundle."
> 
> In your example, we would expect the policy at the receiving node to assert
> that we need both signed-a and signed-b, and this would not be left up to the
> block-type designer. 
> 
> > > The diagram in Figure 2 seems to incorrectly indicate a degree of freedom
> > 
> > in the number of results per target: if we are applying the same operation
> > to
> > all blocks in the target array, the operation should produce the same number
> > of results for all target blocks, thus constraining 'K' to be equal to 'M'.
> > > 
> > > **D5: Agree that K == M is likely most of the time. There is nothing in
> > > the
> > 
> > BPSec that prevents a security context from producing different results as a
> > function of the target block type, target block length, etc... Consider a
> > cipher
> > suite that produces cipher text larger than the plain text. A security
> > context
> > could allow extension blocks to "grow" in size, but when the security target
> > is
> > the payload block, It may choose to place overflow into an additional
> > security
> > result. In such a case, K != M as the security results associated with the
> > payload block would have an additional security result: the overflow.
> > 
> > That feels like the kind of flexibility that's fragile and leads to
> > security-relevant bugs, though I don't dispute what you say.
> > 
> > > Exclusion of most of the block parameters from confidentiality processing
> > 
> > seems to be a critical flaw in the cryptographic hygeine; I think we should
> > include the Block Type Code, Block Number, possibly Block Processing
> > Control Flags, CRC Type and CRC Field (if present), and Block Data Length
> > fields as "additional data" input to the AEAD to provide integrity
> > protection,
> > as well as use them as input to BIB calculation.  Failing to include these
> > parameters seems to leave us prone to "slice and dice" style attacks.
> > > 
> > > **D6: Agreed. BPSEC-20, Section 9.3 (Authorship) states that security
> > 
> > contexts should include immutable block header information.
> > 
> > Thanks!
> > 
> > > Also, the description in Section 4 is unclear about whether the
> > > surrounding
> > 
> > CBOR array encoding is excluded from AEAD iput (though it doesn't really
> > seem like it would make sense to re-encode as a one-item CBOR array prior
> > to applying message protection, the current text is worded such that one
> > might think the array framing is not explicitly excluded).
> > > 
> > > **D7: Agreed. The text in Section 4 has been clarified to exclude array
> > 
> > framing.
> > > 
> > > Section 9.1 gives an example of using a (presumed unprotected in the
> > 
> > absence of any disclaimer) cryptographic key as a security context
> > parameter; given that (per Section 3.6) the parameters are included in the
> > wire-format abstract security block, and not subject to BCB protection, this
> > is
> > wholly insecure and cannot reasonably be used as an example.  (At least
> > draft-ietf-dtn-bpsec-interop-sc had a bit of note about "encoded or
> > protected by the key management system" to give this a veneer of
> > > respectability.)
> > > 
> > > **D8: Agreed. The example has been updated.
> > > 
> > > There's a couple places (noted in the COMMENT) where we claim some
> > 
> > combination of things to be "insecure" without justification; in the noted
> > instances this doesn't seem to be immediately obvious, so I think the
> > justification is needed (or the claim should be removed).
> > > 
> > > **D9: At least one of these instances was at the request of SECDIR last
> > > call
> > 
> > review. However, some of this text was removed in BPSEC20, as cleanup
> > from later comments.
> > > 
> > > Section 7 includes a note that "It is recommended that security operations
> > 
> > only be applied to the blocks that absolutely need them.  If a BPA were to
> > apply security operations such as integrity or confidentiality to every
> > block in
> > the bundle, regardless of need, there could be downstream errors
> > processing blocks whose contents must be inspected or changed at every
> > hop along the path."  While this statement, taken literally, is true, it
> > also
> > seems inconsistent with, e.g., BCP 188, as well as the RFC 3552 threat
> > model,
> > let alone the BPSec threat model of Section 8.  I suggest phrasing that
> > makes
> > applying security operations the default behavior and requiring
> > justification
> > to diverge from that.
> > > 
> > > **D10: Agreed that this is a more consistent way of discussing security.
> > 
> > BPSEC20 includes this update.
> > > 
> > > ----------------------------------------------------------------------
> > > COMMENT:
> > > ----------------------------------------------------------------------
> > > 
> > > Thanks for the well-thought-out security considerations section; it's a
> > 
> > pretty good treatment of the relevant issues for DTN-relevant scenarios and
> > I only have minor comments about it.  Unfortunately, I have pretty
> > substantial comments on much of the rest of the document, which in many
> > places seems internally inconsistent as if some sweeping changes were
> > attempted but not completely implemented.  (E.g., are security contexts
> > IANA-registered values or site-local, including user-defined?  Is there a
> > single
> > target block of a security operation or a list of targets?)  Even among the
> > comments that do not quite rise to Discuss level, there are some pretty
> > significant flaws, especially relating to cryptographic terminology and
> > usage.
> > > 
> > > Section 1.1
> > > 
> > >    3.  Hop-by-hop authentication is a special case of data integrity and
> > >        can be achieved with the integrity mechanisms defined in this
> > >        specification.  Therefore, a separate authentication service is
> > >        not necessary.
> > > 
> > > Data integrity is one thing that can be provided by hop-by-hop
> > 
> > authentication (in combination with trust in the nodes on the path), but it
> > is
> > not the only benefit provided by hop-by-hop authentication; I don't think we
> > should conflate them in this way.
> > > 
> > > 
> > > **C1: I agree that this third bullet adds more confusion (conflation) than
> > 
> > explanation. It has been removed in BPSEC20.
> > > 
> > > Section 1.3
> > > 
> > >    The Bundle Protocol [I-D.ietf-dtn-bpbis] defines the format and
> > >    processing of bundles, defines the extension block format used to
> > >    represent BPSec security blocks, and defines the canonicalization
> > >    algorithms used by this specification.
> > > 
> > > I see a specification in draft-ietf-dtn-bpbis for a "canonical block
> > > structure"
> > 
> > but not for a "canonicalization algorithm" used to produce them.
> > > 
> > > **C2: Agreed. While BpBis describes canonical forms and states that
> > 
> > extension block specifications should provide canonicalization algorithms it
> > is
> > silent, for example, on the way to  generate CBOR values. I have replaced
> > "algorithm" with "form" in BPSEC20.
> > 
> > Thanks!
> > 
> > > Section 1.4
> > > 
> > >    o  Cipher Suite - a set of one or more algorithms providing integrity
> > >       and confidentiality services.  Cipher suites may define necessary
> > >       parameters but do not provide values for those parameters.
> > > 
> > > Could we give examples of such parameters?  If it's things like "secret
> > > keys"
> > 
> > that seems okay, but if it's "key length" or "number of rounds" I don't
> > think
> > that's appropriate to leave as a free parameter, and would be better
> > expressed as separate cipher suite values.
> > > Is there a 1:1 mapping between security context and cipher suite?
> > > Should this be "integrity and/or confidentiality services"?
> > > 
> > > **C3: Agreed this could lead to a confusing interpretation. I clarified
> > > this as
> > 
> > "user parameters (e.g., secret keys to use)" in BPSEC20.
> > 
> > Ah, sounds good.
> > 
> > >    o  Security Service - the security features supported by this
> > >       specification: either integrity or confidentiality.
> > > 
> > > I wonder if we could make the definition more general in case future
> > 
> > security services are defined in the future.
> > > 
> > > **C4: No issue. I made the definition of security service more general in
> > 
> > BPSEC20.
> > > 
> > > Section 2.2
> > > 
> > >    A bundle can have multiple security blocks and these blocks can have
> > >    different security sources.  BPSec implementations MUST NOT assume
> > >    that all blocks in a bundle have the same security operations and/or
> > >    security sources.
> > > 
> > > nit: is it better to say "have the same security operations" or "have the
> > 
> > same security operations applied to them"?
> > > 
> > > **C5: Agreed it is better to say "have the same security operations
> > > applied
> > 
> > to them.". Updated in BPSEC20.
> > > 
> > >    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.
> > > 
> > > What about modifying existing blocks (e.g., Previous Node, Bundle Age)?
> > > 
> > > **C6: If the updated block had been encrypted, it means the node was
> > 
> > able to decrypt, so the updated block could be removed as the security
> > target of any existing BCB. Otherwise, if the updated block had an integrity
> > protection mechanism on it, that mechanism is no longer valid since the
> > contents of the security target are changed. The updated security target
> > should be removed from any BIB where it was a security target and a new
> > integrity protection sourced from the node performing the update would
> > need to be added. Generally, the case of update is treated as a "delete
> > block
> > from bundle and remove any of its security services from the bundle" and
> > then add the new block back and then add any needed security services.
> > 
> > Okay.  (Presumably the case of modifying an existing block with no security
> > services in either the inbound or outbound bundle, a la Previous Hop, is
> > not worth mentioning in this context.)
> 
> [EJB10] Agreed that I don't think we need to mention this specific case.
> 
> > > Section 2.3
> > > 
> > >    Some waypoints will determine, through policy, that they are the
> > >    intended recipient of the security service and terminate the security
> > >    service in the bundle.  For example, a gateway node could determine
> > >    that, even though it is not the destination of the bundle, it should
> > >    verify and remove a particular integrity service or attempt to
> > >    decrypt a confidentiality service, before forwarding the bundle along
> > >    its path.
> > > 
> > > This would not really be "end-to-end" as we claim in the Introduction.
> > > 
> > > **C7: Agreed. I have added the clarification that if the security source
> > > is the
> > 
> > bundle source and the security acceptor is the bundle destination then the
> > security service is end-to-end. Generally, I have reviewed the few instances
> > of "end-to-end" and updated them in BPSEC20.
> > 
> > Thanks for going through and checking.  It is perhaps a little sad in some
> > sense to be removing "end-to-end security", though I understand why it's
> > the right thing to do here.
> > 
> > >    Some waypoints could understand security blocks but refuse to process
> > >    them unless they are the bundle destination.
> > > 
> > > I'm a little confused as to why this would be desirable.
> > > 
> > > **C8: The WG discussions focused on when resource-constrained nodes
> > 
> > might choose to not process very large data or very small-but-high-rate
> > data.
> > Alternatively if resources are limited nodes might only check to certain
> > addresses or only for certain block types.
> > 
> > I think part of my confusion is whether such nodes would just drop bundles
> > with this property ("not process the bundle"), or merely not process the
> > security blocks ("not process the block").
> 
> [EJB11] It is likely that nodes would not process the blocks in this case, but
> I don't know that this specification should make a recommendation here. 
> 
> > > Section 2.4
> > > 
> > >    in the implementation of their security services.  BPSec must provide
> > >    a mechanism for users to define their own security contexts.
> > > 
> > > That seems highly risky, since defining a security context involves
> > > getting a
> > 
> > value allocated by IANA in a 16-bit "Specification Required" codepoint space
> > and it seems pretty unlikely that all users would actually do that.
> > > 
> > > **C9: The text could be clearer. New security contexts could be identified
> > 
> > and registered. These security contexts can be parameterized to give users
> > flexibility. I have clarified this text in BPSEC20.
> > 
> > The new text looks much better; thank you!
> > 
> > >    For example, some users might prefer a SHA2 hash function for
> > >    integrity whereas other users might prefer a SHA3 hash function.  The
> > >    security services defined in this specification must provide a
> > >    mechanism for determining what cipher suite, policy, and
> > >    configuration has been used to populate a security block.
> > > 
> > > Doesn't this imply a requirement for a registry or registries of the
> > > relevant
> > 
> > types of values?  Or are we claiming that this will all be part of the
> > specification for the security context?
> > > 
> > > **C10: The parameter IDs and result IDs are scoped per security context
> > 
> > and do not need a registry. It is allowed for a security context definition
> > to
> > use common enumerations for its parameter and result IDs.
> > 
> > Okay ... I think.  Just to check: the security context specification would
> > also include enumerations for "policy"?
> 
> [EJB12] Please see the comment EJB10.  Additionally, there is discussion of
> security contexts having parameters that can carry policy associated with how
> the node should react to events relating to that policy. In this way out-of-
> band policy (EJB10) discusses what blocks/security contexts are needed and the
> security context itself can carry some policy with it if necessary.
> 
> > > Section 3.1
> > > 
> > >       the bundle destination.  Security-aware waypoints add or remove
> > >       BIBs from bundles in accordance with their security policy.  BIBs
> > >       are never used to sign the cipher-text provided by a BCB.
> > > 
> > > nit: most of this text is good about using a generic treatement of
> > > "integrity
> > 
> > protection", but "sign" is a subset of the ways to get integrity protection.
> > > 
> > > **C11: Agreed. This has been updated in BPSEC20.
> > > 
> > >       of security policy.  BCBs additionally provide authentication
> > >       mechanisms for the cipher-text they generate.
> > > 
> > > I suspect this is going to be authentication in the AEAD sense, that is,
> > 
> > protection against malleability (as opposed to source authentication that
> > provides an indication of the identity of the party applying the
> > protection).  I
> > don't think it's best to refer to such properties as "authentication
> > mechanisms" as opposed to "integrity protection"
> > > 
> > > **C12: Agreed. This has been updated in BPSEC20.
> > > 
> > > Section 3.2
> > > 
> > >    bundle.  Since a security operation is represented as a security
> > >    block, this limits what security blocks may be added to a bundle: if
> > >    adding a security block to a bundle would cause some other security
> > >    block to no longer represent a unique security operation then the new
> > >    block MUST NOT be added.  It is important to note that any cipher-
> > > 
> > > Is it permissible to remove the existing block before adding the new
> > > (conflicting) one?
> > > 
> > > **C13: This is permissible. The constraint is that they do not co-exist in
> > > the
> > 
> > bundle. I added clarifying text in BPSEC20.
> > > 
> > >    o  Signing the payload twice: The two operations OP(integrity,
> > >       payload) and OP(integrity, payload) are redundant and MUST NOT
> > >       both be present in the same bundle at the same time.
> > > 
> > > They're not redundant if a recipient might have different levels of
> > 
> > confidence in the two (different) signers.  Though, IIUC, having the
> > "second"
> > signature include the first BIB as the signed content is permissible as a
> > workaround, right?  [ed. reading further this understanding seems contrary
> > to the current text of the spec]
> > > 
> > > **C14: There was WG discussion on allowing multiple BIBs with the same
> > 
> > security target. This leads to tricky situations such as processing order
> > and
> > failed verifications and whether all BIBs or some BIBs would accompany the
> > security target if fragmentation occurs. The thought was to instead build a
> > "multiple result" security context where a single BIB would carry multiple
> > integrity protection results in its security results.
> > 
> > Okay.  Depending on the (richness of) semantics needed, that might end up
> > needing many types of security context or BIB-like block to meet the needs,
> > but that may not need to be dealt with now.
> > 
> > > 
> > > Section 3.3
> > > 
> > >    Under special circumstances, a single security block MAY represent
> > >    multiple security operations as a way of reducing the overall number
> > > 
> > > I'm not so sure that this is "special circumstances"; I would expect
> > > wanting
> > 
> > to apply the same operation to multiple blocks to be quite common.
> > > 
> > > **C15: No issue. I have updated the text in BPSEC20.
> > > 
> > >    o  The security source for the security operations is the same.
> > >       Meaning the set of operations are being added by the same node.
> > > 
> > > nit: this second sentence is a sentence fragment.
> > > 
> > > **C16: No issue. I have updated the text in BPSEC20.
> > > 
> > >    A security target is a block in the bundle to which a security
> > >    service applies.  This target must be uniquely and unambiguously
> > > 
> > > Given that the ASB always uses an array of block numbers to identify the
> > 
> > target, this use of the singular "a block" seems inappropriate.
> > > 
> > > **C17: A security target is always a single block identified in a
> > > particular
> > 
> > way. That ASBs have multiple security targets does not change that each
> > security target is, itself, a singular block.
> > > 
> > > Section 3.5
> > > 
> > >    o  CRC Type and CRC Field (if present)
> > > 
> > >    o  Block Data Length
> > > 
> > >    o  Block Type Specific Data Fields
> > > 
> > > nit: draft-ietf-dtn-bpbis-21 has the CRC field as the last field, and the
> > > block
> > 
> > data length and type-specific data are encoded together as a definite-length
> > byte string.
> > > 
> > > **C18: Agreed. This has been updated in BPSEC20.
> > > 
> > > Section 3.6
> > > 
> > > Does the array of block numbers in the "Security Targets" field need to be
> > 
> > sorted in a particular order?
> > > 
> > > **C19: There is no required sorting order.
> > 
> > Okay.  It might (or might not) be worth a note that "the order of elements
> > has no semantic meaning".
> 
> [EJB13] No harm in clarifying this, I have added text to that effect in bpsec-
> 21.
> 
> > >    Security Context Flags:
> > >          [...]
> > >          Bit 1  (the least-significant bit, 0x01): Security Context
> > >                 Parameters Present Flag.
> > > 
> > > In draft-ietf-dtn-bpbis we start numbering bits at "bit 0", so it's
> > > confusing to
> > 
> > start at "bit 1" here.
> > > 
> > > **C20: Agreed. BPSEC20 has been updated.
> > > 
> > >    Security Context Parameters (Optional):
> > > 
> > > Why do we use an array of (index, value) tuples instead of a CBOR map?
> > > 
> > > **C21: There was no strong preference for encoding representation. Does
> > 
> > a CBOR map result in a smaller size?
> > 
> > I am not 100% sure but I think there would be some encoding efficiency from
> > not needing repeated array framing.  (Maps also help when you can assign
> > short integer map keys to attributes that otherwise would have longer,
> > e.g., string, names, but the Ids here are already integers so that's a
> > no-op.)
> 
> [EJB14] Recommend no change here. 
> 
> > >    Security Results:
> > >          This field captures the results of applying a security service
> > >          to the security targets of the security block.  This field
> > > 
> > > (I note that here we properly refer to "targets" plural, in contrast to
> > > what I
> > 
> > noted above.)
> > > 
> > >          SHALL be represented as a CBOR array of target results.  Each
> > >          entry in this array represents the set of security results for
> > >          a specific security target.  The target results MUST be ordered
> > >          identically to the Security Targets field of the security
> > >          block.  This means that the first set of target results in this
> > > 
> > > Per the discuss point, what's the motivation for having an array of
> > > results
> > 
> > instead of applying the operation to the concatenation of the blocks in
> > question and having a single result?  Having multiple results negates most
> > of
> > the space savings we could get from coalescing an operation via "target
> > multiplicity".  I see that the BCB procedures can require splitting a BIB if
> > only
> > some of its targets are covered by the BCB (which requires an array of
> > results), but the mechanics of processing would still be possible by
> > encrypting the whole BIB.  Are there reasons why that is not feasible?
> > > 
> > > **C22: From WG discussion, if a single block were updated or dropped we
> > 
> > would lose integrity protection over the set of blocks. It could also make
> > it
> > difficult to verify integrity of blocks if, after BIBs were added, the
> > bundle was
> > fragmented. As-is, if a bundle contains a payload fragment, a waypoint can
> > still choose to verify integrity if a BIB and its security target are
> > together.
> > There was some WG discussion that a separate security block for "multi-
> > target-single-result" could be interesting but this was determined to not be
> > something that should be in the BPSec and if needed, a specification for it
> > could be added as an "Other Security Block" (OSB).
> > 
> > I think this helps me understand the WG's thinking better, in that the
> > potential need to apply fragmentation or otherwise split up bundles is
> > perceived to be very strong, and adding in requirements that would
> > constrain the ability to do so would be seen as reducing the usability of
> > the protocol.  I think this leaves a lot of responsibility for making
> > security-relevant decisions in the hands of implementors and operators,
> > substantially increasing latent risk, but do not have a specific concrete
> > vulnerability that I can point to with the present formulation.
> > 
> > > Section 3.7
> > > 
> > >    o  The Security Context Id MUST utilize an end-to-end authentication
> > >       cipher or an end-to-end error detection cipher.
> > > 
> > > Please don't use the word "cipher" here; "cipher" is a cryptographic term
> > > of
> > 
> > art and does not apply here (see RFC 4949).
> > > 
> > > **C23: Agreed! BPSEC20 has been updated.
> > > 
> > >    o  The EID of the security source MAY be present.  If this field is
> > >       not present, then the security source of the block SHOULD be
> > >       inferred according to security policy and MAY default to the
> > >       bundle source.  The security source MAY be specified as part of
> > >       security context information described in Section 3.10.
> > > 
> > > Isn't the security context identified by an IANA-assigned value?  I cannot
> > 
> > see how the contex would specify the source itself as opposed to the
> > procedure for inferring it from the bundle contents.
> > > 
> > > **C24: I have clarified the text in BPSEC20 to note that this information
> > 
> > could be provided as part of a security context parameter.
> > > 
> > >    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.
> > > 
> > > As indicated above; I don't understand the need for this requirement.
> > > I also don't understand what is meant by a "multi-signature security
> > 
> > context".
> > > 
> > > **C25: Please see **C22.
> > 
> > Just to check: is this more likely to be done as an OSB or a security
> > context for which (all?) BIBs are "multi-signature"?
> > 
> > >    o  For some security contexts, (e.g., those using asymmetric keying
> > >       to produce signatures or those using symmetric keying with a group
> > >       key), the security information MAY be checked at any hop on the
> > >       way to the bundle destination that has access to the required
> > >       keying information, in accordance with Section 3.9.
> > > 
> > > I am strongly reluctant to endorse the use of a group-shared symmetric key
> > 
> > in a standards-track document.
> > > 
> > > **C26: Agreed. I have added text that group-shared symmetric key is not
> > 
> > recommended.
> > > 
> > > Also, nit: wouldn't an "error-detection cipher [sic]" also allow for a
> > 
> > waypoint node to check the integrity information?
> > > 
> > > **C27: text in BPSEC20 has been updated to simply state that checks can
> > 
> > occur if access to required keying information. Did not feel it necessary to
> > state key information could be NULL for unkeyed error detection (e.g.
> > different CRC alg).
> > 
> > Sure.
> > 
> > > Section 3.8
> > > 
> > >       The Block Processing Control flags value can be set to whatever
> > >       values are required by local policy, except that this block MUST
> > >       have the "replicate in every fragment" flag set if the target of
> > >       the BCB is the Payload Block.  Having that BCB in each fragment
> > > 
> > > (now we're back to "the target" singular)
> > > 
> > > **C28: text should be "if a target" not "if the target". BPSEC20 text has
> > 
> > been updated.
> > > 
> > >       The Security Context Id MUST utilize a confidentiality cipher that
> > >       provides authenticated encryption with associated data (AEAD).
> > > 
> > > nit: is it the Id or the Context that utilizes the cipher?
> > > 
> > > **C29: It is the context. BPSEC20 has been updated.
> > > 
> > >       Additional information created by a cipher suite (such as
> > >       additional authenticated data) can be placed either in a security
> > > 
> > > nit: the "additional authenticated data" of an AEAD cipher is *input* to
> > > the
> > 
> > AEAD, not output; perhaps you mean "authentication tag" here.
> > > 
> > > C30: Agreed! Updated text in BPSEC20 to use authentication tag.
> > > 
> > >       bundle source.  The security source MAY be specified as part of
> > >       security context information described in Section 3.10.
> > > 
> > > [same comment as for 3.7]
> > > 
> > > **C31: See **C24.
> > > 
> > >    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.
> > > 
> > > Can we even allow setting "discard this block", since we modify the
> > 
> > contents of the target and the target would be wrongly interpreted in the
> > absence of this block?
> > > 
> > > **C32: Agreed this is a useful way to prevent implementations from doing
> > 
> > something they will regret. I have updated BPSEC20 to disallow the setting
> > of
> > this block processing flag for BCB.
> > > 
> > >    o  A BIB MUST NOT be added for a security target that is already the
> > >       security target of a BCB.  In this instance, the BCB is already
> > >       providing authentication and integrity of the security target and
> > >       the BIB would be redundant, insecure, and cause ambiguity in block
> > >       processing order.
> > > 
> > > The type of authentication that is provided by the BCB can be
> > > qualitatively
> > 
> > different than the authentication provided by a BIB; ambiguity in block
> > processing order alone is a sufficient reason to disallow this case and we
> > probably shouldn't mention the other alleged reasons.
> > > I also don't understand why you say that this combination is "insecure"
> > > based just on the description here; please either remove the claim of
> > 
> > justify it.
> > > 
> > > **C33: Agreed. I have shortened this text in BPSEC20.
> > > 
> > >    o  A BIB integrity value MUST NOT be evaluated if the BIB is the
> > >       security target of an existing BCB.  In this case, the BIB data is
> > >       encrypted.
> > > 
> > > What does "evaluated" mean here, and by whom?
> > > 
> > > **C34: Replaced evaluated with checked in the text. Any node can check
> > 
> > integrity if they have appropriate means to do so, as per **C27.
> > > 
> > >    o  A BIB integrity value MUST NOT be evaluated if the security target
> > >       of the BIB is also the security target of a BCB.  In such a case,
> > >       the security target data contains cipher-text as it has been
> > >       encrypted.
> > > 
> > > I thought we already disallowed this from happening because the BIB
> > 
> > contents are encrypted.
> > > 
> > > **C35: Text is reinforcing that this is not an allowed combination.
> > > 
> > > Section 3.9
> > > 
> > >    Since any cipher suite used with a BCB MUST be an AEAD cipher suite,
> > >    it is inefficient and insecure for a single security source to add
> > >    both a BIB and a BCB for the same security target.  In cases where a
> > > 
> > > Again, please justify or remove the claim of "insecure".
> > > Also, the authentication provided by a signature BIB remains qualitatively
> > 
> > different from that provided by an AEAD.
> > > 
> > > **C36: Use of insecure was as directed by SECDIR last call review. I have
> > 
> > shortened the text in BPSEC20 to just focus on normative guidance.
> > > 
> > > Section 3.10
> > > 
> > > I still don't have any real idea of what type(s) of parameters the
> > > "security
> > 
> > context parameters" might be, which is worryisome.
> > > 
> > > **C37: BPSEC20 points readers to interop-sc.
> > > 
> > > Section 3.11
> > > 
> > > It's not entirely clear to me what value is provided by using the Bn layer
> > > of
> > 
> > abstraction for block IDs, as opposed to actual integer values (which makes
> > it
> > clear that the primary block has ID 0 and the payload has ID 1).
> > > 
> > > **C38: If the question is why (B1) notation instead of (1), it is simple
> > 
> > preference as (1) looks like a citation or an in-line enumeration.
> > 
> > (Yes, it was just a question of the notation, and your preference takes
> > priority over mine.)
> > 
> > > Section 3.11.1
> > > 
> > >    o  An integrity signature applied to the canonicalized primary block
> > > 
> > > [noting again that the core spec does not define a "canonicalization"
> > > procedure.]
> > > 
> > > **C39: BpBis gives a standard form for the primary block. Updated text in
> > 
> > BPSEC20 to say canonical form.
> > > 
> > >    o  Confidentiality for the first extension block (B4).  This is
> > >       accomplished by a BCB (B3).  Once applied, the contents of
> > >       extension block B4 are encrypted.  The BCB MUST hold an
> > > 
> > > nit(?): I don't think "contents" is the term used most often by the core
> > > spec
> > 
> > for the block-type-specific data.
> > > 
> > > **C40: Agreed. The text in BPSEC20 has been updated.
> > > 
> > >       authentication signature for the cipher-text either in the cipher-
> > >       text that now populates the first extension block or as a security
> > > 
> > > "authentication signature" is going to confuse people by its similarity to
> > > the
> > 
> > cryptographic signature concept, which this is not.  Please use
> > "authentication tag" instead.
> > > 
> > > **C41: Agreed. Updated text in BPSEC20.
> > > 
> > > Section 3.11.2
> > > 
> > >    The resultant bundle is illustrated in Figure 4 and the security
> > >    actions are described below.  Note that block IDs provided here are
> > >    ordered solely for the purpose of this example and not meant to
> > >    impose an ordering for block creation.  The ordering of blocks added
> > >    to a bundle MUST always be in compliance with [I-D.ietf-dtn-bpbis].
> > > 
> > > Is there a particular ordering requirement from bpbis that is relevant
> > > here?
> > > 
> > > **C42: The primary block must be first in a bundle and the payload block
> > 
> > must be last.
> > 
> > Okay.  That's foundational enough that we probably don't need to repeat it
> > here.
> > 
> > >    o  Since the waypoint node wishes to encrypt blocks B5 and B6, it
> > >       MUST also encrypt the BIBs providing plain-text integrity over
> > >       those blocks.  However, BIB B2 could not be encrypted in its
> > >       entirety because it also held a signature for the primary block
> > >       (B1).  Therefore, a new BIB (B7) is created and security results
> > > 
> > > [I still don't understand why this is not an artificial rule, but no need
> > > to
> > 
> > further discuss that here.]
> > > 
> > > Section 4
> > > 
> > >    the same target information (e.g., the same bits in the same order)
> > >    is provided to the cipher suite when generating an original signature
> > >    and when generating a comparison signature.  Canonicalization
> > > 
> > > For many integrity-protection algorithms it is not possible to "generate a
> > 
> > comparison signature" and instead the destination node must "validate the
> > signature" in a dedicated operation.
> > > 
> > > **C43: Agreed this better captures the idea. Updated the text in BPSEC20.
> > > 
> > >    Canonical forms are not transmitted, they are used to generate input
> > >    to a cipher suite for security processing at a security-aware node.
> > > 
> > > nit: comma splice.
> > > 
> > > **C44: Agreed. Text has been updated in BPSEC20.
> > > 
> > > As far as I can tell from draft-ietf-dtn-bpbis, there is a single
> > > canonical
> > 
> > representation form defined and that is what is transmitted; I do not see a
> > separate canonicalization procedure specified.
> > > 
> > > **C45: Agreed. Text updated in BPSEC20.
> > > 
> > >    The canonicalization of the primary block is as specified in
> > >    [I-D.ietf-dtn-bpbis].
> > > 
> > > [where?]
> > > 
> > > **C46: Agreed. Text updated to clarify BpBis provides a canonical form of
> > 
> > the primary block.
> > > 
> > >    All non-primary blocks share the same block structure and are
> > >    canonicalized as specified in [I-D.ietf-dtn-bpbis] with the following
> > >    exceptions.
> > > 
> > > [ibid]
> > > 
> > > **C47: BpBis provides that extension blocks define the manner in which
> > 
> > they are serialized and provides a way to serialize the payload block.
> > > 
> > >    o  Reserved flags MUST NOT be included in any canonicalization as it
> > >       is not known if those flags will change in transit.
> > > 
> > > So they're ... set to zero?  Or since the previous bullet says they're
> > 
> > excluded, there's no problem by definition?
> > > 
> > > **C48: This was at WG request.
> > 
> > We have to produce a canonical CBOR encoding as input to the security
> > operations, and just having them be "excluded" could perhaps cause some
> > confusion.  I would guess, absent other guidance, that we treat the flags
> > as an unsigned integer and encode it in the minimum-width CBOR integer
> > formulation, but that could still leave us with an encoded version that
> > *could* have encoded some flag bits that are marked as "Reserved".  So I
> > think we should say what the value of those bits should be set to, instead
> > of just leaving it implicit.
> 
> [EJB15] Agreed - and the text for bpsec-21 has been updated.
> 
> > >    These canonicalization algorithms assume that Endpoint IDs do not
> > >    change from the time at which a security source adds a security block
> > >    to a bundle and the time at which a node processes that security
> > >    block.
> > > 
> > > When might that not hold?  Shouldn't this be stated much earlier in the
> > 
> > document as a requirement/foundational assumption?
> > > 
> > > **C49: I can see how this text is confusing - it means that if an EID is
> > 
> > selected as a security source, then by the time the security block reaches
> > its
> > eventual security acceptor then the security acceptor knows the security
> > source by the EID at the time the security service was applied. This is a
> > bit like
> > saying that the bundle destination EID cannot have changed by the time the
> > bundle gets to its destination. Unsure this needs to be stated - text
> > removed
> > from BPSEC20.
> > > 
> > > Section 5.1.1
> > > 
> > >    If the security policy of a security-aware node specifies that a
> > >    bundle 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.
> > >    This may involve removing the security target from the bundle.  If
> > >    the removed security target is the payload block, the bundle MUST be
> > >    discarded.
> > > 
> > > As written this seems to impose a requirement on security policies to
> > 
> > specify what happens in this case.  Perhaps we should give a default
> > behavior
> > (discard the bundle?) to avoid accidental omissions that lead to inesecure
> > operation?
> > > Also, nit: "a bundle should have applied confidentiality" is weird
> > > grammar; I
> > 
> > assume "a bundle should have had confidentiality applied" is the intended
> > meaning (or perhaps with s/bundle/block/), albeit in a very awkward
> > grammatical construction.  The difficulty comes in that it is not the bundle
> > that applies protection, but rather the BPA.
> > > 
> > > **C50: Agreed. Text has been added in BPSEC20 to recommend a default
> > 
> > behavior and to fix the nit.
> > > 
> > >    If the Block Data Length field was modified at the time of encryption
> > >    it MUST be updated to reflect the decrypted block length.
> > > 
> > > "How would the node removing BCB protection know this?" (The security
> > 
> > context and cipher suite, I know, but we should say it.)
> > > 
> > > **C51: Updated in BPSEC20 to remove reference to Block Data Length and
> > 
> > to explain that security context knows the length.
> > > 
> > > Section 5.1.2
> > > 
> > >    If the security policy of a security-aware node specifies that a
> > >    bundle 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.  This
> > > 
> > > [same comment as above about requirement on security policy and default
> > 
> > behavior, and same grammatical nit]
> > > 
> > > **C52: See **50.
> > > 
> > >    may involve removing the security target from the bundle.  If the
> > >    removed security target is the payload or primary block, the bundle
> > >    MAY be discarded.  This action can occur at any node that has the
> > > 
> > > Removed from the bundle or as a security target?
> > > I note that removing the payload or primary block from a bundle produces
> > 
> > a protocol violation, so "MAY" does not seem quite right...
> > > 
> > > **C53: text was unclear and has been updated in BPSEC20. If a BIB was
> > 
> > expected on the primary or payload block the blocks are not to be removed,
> > the node may discard the bundle.
> > > 
> > > Section 5.2
> > > 
> > >    Security processing in the presence of payload block fragmentation
> > >    may be handled by other mechanisms outside of the BPSec protocol or
> > >    by applying BPSec blocks in coordination with an encapsulation
> > >    mechanism.
> > > 
> > > Wouldn't it be worth mentioning the possibility for the application to
> > > just
> > 
> > ensure that any needed confidentiality protection is applied prior to any
> > need for fragmentation?
> > > 
> > > **C54: No issue. Text in BPSEC20 has been updated to reflect this as a
> > 
> > possibility.
> > > 
> > > Section 6
> > > 
> > >    There exist a myriad of ways to establish, communicate, and otherwise
> > >    manage key information in a DTN.  Certain DTN deployments might
> > >    follow established protocols for key management whereas other DTN
> > >    deployments might require new and novel approaches.  BPSec assumes
> > >    that key management is handled as a separate part of network
> > >    management and this specification neither defines nor requires a
> > >    specific key management strategy.
> > > 
> > > Just so we're clear: this is literally leaving the hardest part of
> > > building a
> > 
> > secure system out of scope by saying this, and it's pretty disappointing to
> > see
> > no guidance at all for how one might do so.
> > > 
> > > **C55: The WG has other drafts and items for key management. It was
> > 
> > decided to not address that progressing work in this document.
> > 
> > I'm happy to hear there is other work ongoing in this space, and leave it
> > to you to assess whether that work is mature enough to merit mentioning
> > here as WIP.
> 
> [EJB16] I think it is early to reference a WIP.
> 
> > > Section 7
> > > 
> > >    o  If a bundle is received that contains more than one security
> > >       operation, in violation of BPSec, then the BPA must determine how
> > > 
> > > Just to be clear: "more than one security operation" is not in and of
> > > itself a
> > 
> > violation of BPsec.  Perhaps we could rephrase to be more clear, presumably
> > about blocks that are the target of the same type of security operation?
> > > 
> > > **C56: Agreed. Text was updated in BPSEC20.
> > > 
> > >    o  It is recommended that BCBs be allowed to alter the size of
> > >       extension blocks and the payload block.  However, care must be
> > >       taken to ensure that changing the size of the payload block while
> > >       the bundle is in transit do not negatively affect bundle
> > >       processing (e.g., calculating storage needs, scheduling
> > >       transmission times, caching block byte offsets).
> > > 
> > > How would block byte offsets be relevant, given that it's forbidden to
> > > apply
> > 
> > a BCB to fragments?
> > > 
> > > **C57: Agreed. Text was updated in BPSEC20.
> > > 
> > >       1.  At the time of encryption, a plain-text integrity signature
> > >           may be generated and added to the BCB for the security target
> > >           as additional information in the security result field.
> > > 
> > > Would the need to do this be part of a ... security profile?  A security
> > 
> > context?  It remains unclear to me how these pieces are intended to
> > interact.
> > > 
> > > **C58: A security context. Text was clarified in BPSEC20.
> > > 
> > >       2.  The encrypted block may be replicated as a new block and
> > >           integrity signed.
> > > 
> > > (ditto)
> > > 
> > > **C59: A security context. Text was clarified in BPSEC20.
> > > 
> > >    o  It is recommended that security policy address whether cipher
> > >       suites whose cipher-text is larger (or smaller) than the initial
> > >       plain-text are permitted and, if so, for what types of blocks.
> > > 
> > > It is *extremely* unclear to me in what cases a cipher-text might be
> > > smaller
> > 
> > than the initial plaintext.  I suggest to remove the parenthetical.
> > > 
> > > **C60: No issue. Case was removed and text simplified in BPSEC20.
> > > 
> > > Section 8.1
> > > 
> > >    provide appropriate capabilities if they are needed.  It should also
> > >    be noted that if the implementation of BPSec uses a single set of
> > >    shared cryptographic material for all nodes, a legitimate node is
> > >    equivalent to a privileged node because K_M == K_A == K_B.
> > > 
> > > So sharing a key like that is NOT RECOMMENDED, right?
> > > 
> > > **C61: No issue. Text stating this case is not recommended was added to
> > 
> > BPSEC20.
> > > 
> > >    A special case of the legitimate node is when Mallory is either Alice
> > >    or Bob (i.e., K_M == K_A or K_M == K_B).  In this case, Mallory is
> > >    able to impersonate traffic as either Alice or Bob, which means that
> > > 
> > > "either Alice or Bob, respectively", right?  Having K_B does not let
> > > Mallory
> > 
> > impersonate traffic as Alice?
> > > 
> > > **C62: Agreed. Text was added to say "respectively" in BPSEC20.
> > > 
> > > Section 8.2.1
> > > 
> > >    When evaluating the risk of eavesdropping attacks, it is important to
> > >    consider the lifetime of bundles on a DTN.  Depending on the network,
> > >    bundles may persist for days or even years.  Long-lived bundles imply
> > >    that the data exists in the network for a longer period of time and,
> > >    thus, there may be more opportunities to capture those bundles.
> > >    [...]
> > > 
> > > It's probably worth noting that Mallory is of course not limited by the
> > 
> > bundle lifetime in how long she retains a given bundle.
> > > 
> > > **C63: Agreed. Note was added in BPSEC20.
> > > 
> > > Section 8.2.2
> > > 
> > >    removal of blocks.  Within BPSec, both the BIB and BCB provide
> > >    integrity protection mechanisms to detect or prevent data
> > >    manipulation attempts by Mallory.
> > > 
> > > The protection against removal of blocks (or entire bundles) seems a lot
> > 
> > weaker, though.  The following paragraph is a pretty good treatment; thanks!
> > > 
> > >    only validating that the BIB was generated by a legitimate user, Bob
> > >    will acknowledge the message as originating from Mallory instead of
> > >    Alice.  In order to provide verifiable integrity checks, both a BIB
> > > 
> > > It might be worth saying something about how "validating a BIB indicates
> > 
> > only that the BIB was generated by a holder of the relevant key; it does not
> > provide any guarantee that the bundle or block was created by the same
> > entity".
> > > 
> > > **C64: Agreed. Note was added in BPSEC20.
> > > 
> > > Section 8.2.4
> > > 
> > >    BPSec relies on cipher suite capabilities to prevent replay or forged
> > >    message attacks.  A BCB used with appropriate cryptographic
> > >    mechanisms (e.g., a counter-based cipher mode) may provide replay
> > >    protection under certain circumstances.  Alternatively, application
> > > 
> > > This seems to imply keeping counter state across bundles, something that's
> > 
> > pretty finicky to get right and risky to get wrong.  I don't think we should
> > be
> > implying that this is a good idea without a lot more discussion of the
> > potential
> > pitfalls and how to avoid them.  (Which basically means I don't think it's
> > worth
> > mentioning this approach, given the work involved in generating such
> > discussion).
> > > 
> > > **C63: Agreed. Example was removed in BPSEC20.
> > > 
> > > Section 9.2
> > > 
> > >    o  Security Results.  Security contexts MUST define their security
> > >       result Ids, the data types of those results, and their CBOR
> > >       encoding.
> > > 
> > > Are these result Ids expected to be global to a security context or scoped
> > 
> > to a specific block type?
> > > 
> > > **C64: Result ids are expected to be global to the security context and
> > > not
> > 
> > specific to a block type.
> > > 
> > >       *  Place overflow bytes, authentication signatures, and any
> > >          additional authenticated data in security result fields rather
> > >          than in the cipher-text itself.
> > > 
> > > [same note as (far) above about "authenticated data"]
> > > 
> > > **C65: Agreed. Text was updated in BPSEC20.
> > > 
> > > 
> > >       *  Pad the cipher-text in cases where the cipher-text is smaller
> > >          than the plain-text.
> > > 
> > > [same note about smaller ciphertext than plaintext]
> > > 
> > > **C66: Agreed. Text was removed and simplified in BPSEC20.
> > > 
> > > Section 10
> > > 
> > >    o  Other security blocks (OSBs) MUST NOT reuse any enumerations
> > >       identified in this specification, to include the block type codes
> > >       for BIB and BCB.
> > > 
> > > I don't understand what this means.
> > > 
> > > **C67: This was to prevent the idea that idea that the block type code for
> > 
> > BIB and/or BCB could be reused by another organization or deployment but
> > with a different BIB/BCB syntax from another document. Which of course
> > should be discouraged. And perhaps so obvious to not do as to not need a
> > call out in the document?
> > 
> > IMO it is "that obvious", though I am not exactly the average reader.
> 
> [EJB17] No harm in keeping this text.
> 
> > >    NOTE: The burden of showing compliance with processing rules is
> > >    placed upon the standards defining new security blocks and the
> > >    identification of such blocks shall not, alone, require maintenance
> > >    of this specification.
> > > 
> > > nit: I suggest using a different word than "standards"
> > > ("specifications"?),
> > 
> > since the block type registry is just under the Specification Required
> > policy.
> > > 
> > > **C68: Agreed. The text was updated in BPSEC20.
> > > 
> > > Section 11.1
> > > 
> > >    This specification allocates two block types from the existing
> > >    "Bundle Block Types" registry defined in [I-D.ietf-dtn-bpbis].
> > > 
> > > draft-ietf-dtn-bpbis-21 does not contain a direction to IANA to update the
> > 
> > reference for the bundle block types registry away from its current
> > reference, RFC 6255, so it seems "defined in [RFC6255]" would be more
> > correct.
> > > 
> > > **C69: Agreed. The text was updated in BPSEC20.
> > 
> > 
> > Thanks for all the updates!
> > 
> > -Ben
> 
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------