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

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:dtn-bounces@ietf.org] On Behalf Of Zaheduzzaman Sarker
> Sent: 31 March 2021 08:07
> To: Birrane, Edward J.; dtn@ietf.org
> 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." <Edward.Birrane@jhuapl.edu>
> 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
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn