Re: [dtn] AD review of draft-ietf-dtn-bpsec-10

[Magnus Westerlund <[e-mail]>]

Hi,

With the new draft version, this document is ready for IETF last call.
I going to go ahead and start the last call. I expect BPbis and tcpcl
to follow soon. I will not bring BPsec to the IESG before BPbis, but
most likely together. 

Cheers

Magnus

On Tue, 2019-09-17 at 20:38 +0000, Magnus Westerlund wrote:
> Hi,
> 
> So finnaly following up on the new revision. See inline for my
> comments
> and remarks. I think there are potentially two minor text changes and
> one question to answer. 
> 
> 
> On Wed, 2019-07-24 at 23:01 +0000, Magnus Westerlund wrote:
> > Hi,
> >  
> > I have now done my AD review of draft-ietf-dtn-bpsec-10. I want to
> > point out that I am going to ask about the reasons behind certain
> > choices in the document. Note the intention here is not to change
> > what your specified  but to understand the choices made.
> >  
> > 1. Section 1.2:
> >    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.
> >  
> > As the WG actually have one example specification for a security
> > context and cipher suits, it would be good to reference this so
> > that
> > people realize that it exist and can be looked at in parallel.
> 
> Fixed
> 
> >  
> > 2. Section 1.4: I am missing a term for the receiver / target
> > either
> > if that is any holder of the security context or an intended bundle
> > receiver, in other words the peer to security source.
> >  
> 
> Fixed. 
> 
> > 3. Section 3.1:
> >  
> >       The BIB is used to ensure the integrity of its plain-text
> > security
> >       target(s).  The integrity information in the BIB MAY be
> > verified
> >       by any node along the bundle path from the BIB security
> > source
> > to
> >       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.
> >  
> > This is only part of a conflict between the order between BIB and
> > BCB
> > processing and the possibility for a node along the Bundle path to
> > verify the integrity of parts of the bundle. So my thoughts here is
> > that bundle sender has two security contexts. One with the receiver
> > that it will use to secure the BUNDLE Payload and other Blocks that
> > are of end-to-end nature and not needed on path. Then I will have
> > another security context that a set of the bundle forwarding nodes
> > share so that they can verify the bundle being sent. However, to my
> > understanding this is not possible as any BIB using the second
> > context can’t use encrypted payload block as its input.
> >  
> > So although the documents talks about this, it appears to have
> > limited utility. Any comments about this limited utility?
> 
> So this was resolved in discussion that the solution to this is the
> Bundle-in-bundle encapsulation. 
> 
> >  
> > 4. Section 3.2:
> >   Security operations in a bundle MUST be unique; the same security
> >    service MUST NOT be applied to a security target more than once
> > in
> > a
> >    bundle.
> >  
> > This uniqueness requirement, isn’t this missing a dependency on
> > security context? To me there appear that being able to use more
> > than
> > one security context has some benefits, or is it making things to
> > complex, or are there other reasons?
> 
> Same as 3. 
> 
> >  
> > 5. Section 3.6:
> > Security Context Flags:
> >  
> > What is the meaning of the Reserved bits? What should the sender
> > and
> > receiver do with these bits. Can they be assigned in the future?
> >  
> 
> I think the changes made things clearer, but didn't fully resolve the
> question I have about if it intended that future extension may
> reserve
> any of the other bits? Which would imply a ignore values of for
> implementation undefined bits. 
> 
> If that is the intention please be explicit about that. 
> 
> 
> 
> > 6. Section 3.8:
> >       The Security Context Id MUST utilize a confidentiality cipher
> > that
> >       provides authenticated encryption with associated data
> > (AEAD).
> >  
> > Why is AEAD a requirement? If the requirement is that no
> > confidentiality without integrity, then that can be stated in an
> > other way than requiring AEAD.
> 
> Discussed, no change needed. 
> 
> >  
> > 7. Section 3:
> >  
> > Looking at the BIB and how it is structured and how the signature
> > is
> > created and stored with one signature per block implies that any on
> > path attacker can remove individual blocks without it being
> > noticed.
> > So aren’t there a missing possibility to create a BIB that actually
> > ensures that if it validates a set of blocks was correctly
> > provided?
> > I know that with the current mechanisms such a BIB could be
> > stripped.
> > However, such a block could easily be required in a security policy
> > for a particular deployment. Was such aspects considered?
> 
> This was discussed and no furhter changes required. 
> 
> >  
> > 8. Section 3.9:
> >    o  When adding a BCB to a bundle, if some (or all) of the
> > security
> >       targets of the BCB match some (but not all) of the security
> >       targets of a BIB, then a new BIB MUST be created and all
> > entries
> >       relating to those BCB security targets MUST be moved from the
> >       original BIB to the newly created BIB.
> >  
> > This comment is linked to the pervious one. When reading this, I
> > had
> > a hard time to understand what “moved” in the above text actually
> > meant. Finally I realized that you could actually move a signature
> > from one BIB to another. I think this could be made a bit clearer.
> 
> Fixed. 
> 
> >  
> > 9. Section 3.10:
> >    Individual BPSec security context identifiers SHOULD use
> > existing
> >    registries of identifiers and CBOR encodings, such as those
> > defined
> >    in [RFC8152], whenever possible.  Contexts SHOULD define their
> > own
> >    identifiers and CBOR encodings when necessary.
> >  
> > I find the above paragraph unclear.  I think one part is what
> > “security context identifiers”.
> 
> Fixed. 
> 
> >  
> > 10. Section 5.1.1:
> > If the receiving node is
> >    not the destination of the bundle, the node MUST decrypt the BCB
> > if
> >    directed to do so as a matter of security policy.
> >  
> > I think this is an example of the unclarity of who is to process a
> > particular security block, because I don’t understand how the node
> > will be able to do this.
> 
> Addressed. 
> 
> >  
> > Section 11:
> >  
> >    A registry of security context identifiers will be required.
> >  
> > If you need a registry for security context identifiers then you
> > need
> > to create it and defines its rules.
> 
> The new registry looks reasonable. The comment I have is that as
> draft-
> ietf-dtn-bpsec-interop-sc is a example / template for future security
> context identifiers, then it is actually good to perform the
> registration with IANA in that document also, so that part of the
> process is not forgotten. 
> 
> Cheers
> 
> Magnus Westerlund 
> 
> 
> -------------------------------------------------------------------
> ---
> Network Architecture & Protocols, Ericsson Research
> -------------------------------------------------------------------
> ---
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> -------------------------------------------------------------------
> ---
> 
> 
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn
-- 
Cheers

Magnus Westerlund 


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