Re: [dtn] AD review of draft-ietf-dtn-bpsec-default-sc-02

["Birrane, Edward J." <[e-mail]>]

Rick, Zahed,

  Yes, that works for me. My apologies that I did not see this comment before posting a -04.  

  I am sure we will be producing a -05 in time and would include those statements in that version.

-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: Rick Taylor <[e-mail]>
> Sent: Friday, April 09, 2021 4:00 AM
> To: [e-mail]; [e-mail]; Birrane, Edward J.
> <[e-mail]>
> Cc: [e-mail]
> Subject: [EXT] Re: AD review of draft-ietf-dtn-bpsec-default-sc-02
> 
> APL external email warning: Verify sender [e-mail]
> before clicking links or attachments
> 
> Hi Zahed,
> 
> Okay.. I agree there is value in recording that key management is a potential
> source of complication, and the detail isn't covered in this document.
> 
> @Ed: Does that work for you?
> 
> Cheers,
> 
> Rick
> 
> 
> On Thu, 2021-04-08 at 23:40 +0000, Zaheduzzaman Sarker wrote:
> > Hello Rick,
> >
> > Thanks for the pointers. I have skimmed through the IETF100 minutes
> > but could not really find notes on key management discussion. I
> > certainly found the decision behind separate sec context document.
> > So, that was somewhat helpful to get the context.
> >
> > Now, if the WG has a consensus that "this limitation is appropriate
> > for now
> >     > for this default security context and the DTN WG is looking to
> > determine
> >     > delay-tolerant key management strategies in the future." As
> > mentioned by Edward in his response.
> > I think the bpsec-default-sc document should describe the potential
> > issues due to lack of proper key management and explain why this
> > limitation is OK for default security context. Basically recording
> > that the WG is aware of issues and has well thought decision for
> > default security context.
> >
> >
> > BR
> > Zahed
> >
> > On 2021-04-06, 16:08, "Rick Taylor" <[e-mail]>
> > wrote:
> >
> >     Hi Zahed,
> >
> >     Just as a bit of clarification to your point re Key Management.
> >
> >     The working group has discussed key management a couple of times
> > (IETF-100 in particular) and there is at least one proposed solution,
> > however the rough consensus of the group is that this topic is tricky
> > to get right in a couple of paragraphs in either BPSec or in this
> > document (which we intend to be as short and simple as possible), and
> > therefore it would be better to not attempt a lose definition before
> > the WG has a firmer view on best practice, and have to update these
> > documents.
> >
> >     To that end, Key Management as a work item for the group is a firm
> > proposal for the re-chartering, and there seems to be sufficient
> > interest and excitement in the group to get it done.
> >
> >     References: IETF-100 minutes and mailing list - I can't find a
> > single obvious thread on the mailing list unfortunately.
> >
> >     Cheers,
> >
> >     Rick
> >
> >     > -----Original Message-----
> >     > From: dtn [mailto:[e-mail]] On Behalf Of
> > Zaheduzzaman Sarker
> >     > Sent: 31 March 2021 08:07
> >     > To: Birrane, Edward J.; [e-mail]
> >     > Cc: Magnus Westerlund
> >     > Subject: Re: [dtn] AD review of draft-ietf-dtn-bpsec-default-
> > sc-02
> >     >
> >     > Hi Edward,
> >     >
> >     > Thanks for the update. The -03 version addresses most of the
> > comments and
> >     > concerns.
> >     >
> >     > See my further comments inline below with [ZS].
> >     >
> >     > BR
> >     > Zahed
> >     >
> >     > On 2021-03-29, 05:43, "Birrane, Edward J."
> > <[e-mail]>
> >     > wrote:
> >     >
> >     >
> >     >     > * It would be good for the user of this document to
> > capture the reason
> >     >     > behind selecting HMAC-SHA and AES-GCM in respective
> > overview section
> >     >     > (section 3.1 and section 4.1).
> >     >
> >     >     C3: Agreed. I have added reasons for selection in 3.1 and
> > 4.1 in the -03
> >     > version.
> >     >
> >     > [ZS] Thanks, this is a good addition.
> >     >
> >     > In section 4.1 :
> >     >
> >     > The BCB-AES-GCM security context shall have the security context
> >     >      identifier specified in Section 5.1.
> >     >
> >     > is this "shall" should be a "MUST" as described in Section 3.1?
> >     >
> >     >
> >     >     > * Section 3.3.2 and Section 3.5 :
> >     >     > It seems like some sort of key-id might be required to
> > resolve
> >     >     > this. The BPsec does not define any generic key-id and it
> > is neither
> >     > defined
> >     >     > here. It might become an issue for interoperability.
> >     >
> >     >     C5: Agreed this might become an issue for interoperability.
> > For example, if
> >     > the policies for requiring security operations differ on
> > different nodes there
> >     > may be interop problems. Similarly, if the policies for key
> >     > generation/communication differ on different nodes, there may be
> > interop
> >     > problems. The DTNWG consensus was this limitation is appropriate
> > for now
> >     > for this default security context and the DTN WG is looking to
> > determine
> >     > delay-tolerant key management strategies in the future.
> >     >
> >     > [ZS] Ok,  is this consensus documented somewhere? Meeting notes
> > or email
> >     > thread or whatever?
> >     >
> >     >
> >     >
> >     >     > * Section 4.3.2 :
> >     >     >      Does this "security policy" refers to local security
> > policy?
> >     >
> >     >     C15: Yes.  Security policy at the source, verifier, or
> > acceptor is meant to
> >     > imply the local security policy at the node.
> >     >
> >     > [ZS] Ok, then clearly stating that helps. It was clearly mention
> > in the other
> >     > place(s).
> >     >
> >     >
> >     >     > * Section 6.3
> >     >     >
> >     >     >      To me this security considerations for fragmentation
> > belongs to BPsec
> >     > as
> >     >     > the main technical issues on fragmentation are described
> > there.
> >     >
> >     >     C17: I would support removing the fragmentation section from
> > this
> >     > document and including it in some other broader-scoped document
> > on DTN
> >     > security, though perhaps not the BPSec document itself because
> > the issues
> >     > with fragmentation can extend beyond the insertion and handling
> > of security
> >     > blocks.
> >     >
> >     > [ZS] I don't think removing the fragmentation section from this
> > document to
> >     > some other document actually helps. This is a very important
> > aspect of the
> >     > security context and I think it is better to be decisive about
> > it now. If moved
> >     > to BPSec then other documents , specially security context
> > documentation,
> >     > can just refer to it. The question really is, where does it make
> > more sense put
> >     > there it is in line with the context of the content of the
> > document? Right now
> >     > I see that is BPsec.
> >     >
> >     >
> >     >     > I would also like to draw attention to the SECART review
> > (Thanks to the
> >     >     > SECART team and Christian Huitema) proposing test vectors
> > to mitigate
> >     >     > interoperability issue pointed out by the reviewer. This
> > seems like a good
> >     >     > proposal to include in this specification.
> >     >
> >     >
> >     >     C18: Agreed and grateful for the review! As mentioned in my
> > comments to
> >     > the SECART review and similar to C17 above, I think that example
> > encodings
> >     > are a very useful concept, but would ultimately be useful at
> > showing bundle
> >     > structure and security block structure. Rather than repeating
> > such encodings
> >     > in all future security context documents, I propose the DTN WG
> > consider the
> >     > best way to produce this broader-scope documentation.
> >     >
> >     > [ZS] I see the test vectors related to the applicability of the
> > this document
> >     > hence this need to be considered well. Failing to assure
> > interoperability
> >     > actually undermine the intention of this document, hence any
> > tools to help
> >     > achieving that goal is worth putting effort into. Also we need
> > to make sure
> >     > the test vector is actually usable by more than one
> > implementation.  I would
> >     > be happy if DTN WG comes up with a best way forward here.
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > dtn mailing list
> >     > [e-mail]
> >     > https://www.ietf.org/mailman/listinfo/dtn
> >