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

[Brian Sipos <[e-mail]>]

Ed,
Regarding test vectors, I had prepared some similar short examples in [1] using the source in [2]. The only issue with these examples is that they are not yet updated to include the mandatory ASB Security Source field from BPSec -25, but that doesn't affect AAD or other example data. You're welcome to adapt any of those existing examples for the default contexts, they can be run from a local working copy as described in the top-level README.md file.

[1] https://www.ietf.org/archive/id/draft-bsipos-dtn-bpsec-cose-05.html#section-appendix.a
[2] https://github.com/BSipos-RKF/dtn-bpsec-cose/tree/main/src

________________________________
From: dtn <[e-mail]> on behalf of Zaheduzzaman Sarker <zaheduzzaman.sarker=[e-mail]>
Sent: Wednesday, March 31, 2021 03:06
To: Birrane, Edward J. <[e-mail]>; [e-mail] <[e-mail]>
Cc: Magnus Westerlund <[e-mail]>
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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdtn&amp;data=04%7C01%7CBSipos%40rkf-eng.com%7Cb5e10d1118774035b60d08d8f413c262%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637527713006290046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=TtRtdmvpnNBjaaI8dyOQCrclfgLdhDP8BsjV2LnDUrQ%3D&amp;reserved=0