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

[Rick Taylor <[e-mail]>]

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
>