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

[Zaheduzzaman Sarker <[e-mail]>]

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