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

From: Brian Sipos <[email-masked]>
Date: Mon, 5 Apr 2021 15:36:32 +0000

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 <[email-masked]> on behalf of Zaheduzzaman Sarker <zaheduzzaman.sarker=[email-masked]>
Sent: Wednesday, March 31, 2021 03:06
To: Birrane, Edward J. <[email-masked]>; [email-masked] <[email-masked]>
Cc: Magnus Westerlund <[email-masked]>
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." <[email-masked]> 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
[email-masked]
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

---

From: Rick Taylor <[email-masked]>
Date: Tue, 6 Apr 2021 14:08:13 +0000

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:[email-masked]] On Behalf Of Zaheduzzaman Sarker
> Sent: 31 March 2021 08:07
> To: Birrane, Edward J.; [email-masked]
> Cc: Magnus Westerlund
>     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.
> 
>     C15: Yes.  Security policy at the source, verifier, or acceptor is meant to
> imply the local security policy at the node.
> 
>     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.
> 
> 
>     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.
> 
> 
> 
> https://www.ietf.org/mailman/listinfo/dtn

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Thu, 8 Apr 2021 23:40:46 +0000

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
    > 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" <[email-masked]> wrote:

    Hi Zahed,

    Cheers,

    Rick

---

From: Rick Taylor <[email-masked]>
Date: Fri, 9 Apr 2021 07:59:43 +0000

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

---

From: "Birrane, Edward J." <[email-masked]>
Date: Mon, 12 Apr 2021 04:55:27 +0000

Zahed,
  
  I think we are getting close.  I have posted a -04 version of the document. 

  My comments are below and prefaced with [EB].

> is this "shall" should be a "MUST" as described in Section 3.1?

[EB] Yes! Good catch. This has been updated in the -04 version of the draft.

> [ZS] Ok,  is this consensus documented somewhere? Meeting notes or email

[EB] Specific to key communication, the intent from the DTNWG through the last call was to use an approved key wrap algorithm from NIST 800-38F (which really means AES-KW since we do not have keys which require the alternate padding variant). The attempt to leave room for "other key communication techniques" that were not requested by the WG is, on reflection, more likely to hurt interoperability than to provide additional utility. I simplified this language in -04 to state AES-KW as defined in NIST 800-38F.

[EB] The default security context is meant to be a simple context that can be easy to implement with well-understood algorithms - particularly since this security context is required as a normative reference for BPv7 and BPSec. We fully expect other security contexts to be defined over time (one based on COSE is in work now) which can capture more complex behavior. 

> [ZS] Ok, then clearly stating that helps. It was clearly mention in the other

[EB] Agree! Change made.

> there it is in line with the context of the content of the document? Right now

[EB] I'm certainly fine with keeping the text in this default security context document, and left it in for the -04 version of the document.

[EB] I would not want to add this to BPSec for two reasons: (1) It is possible that some security contexts may not have these specific fragmentation vulnerabilities, (2) the impact of fragmentation on security is akin to the impact of bundle modification on security (consider malicious fragmentation) and thus covered in BPSec already. 

> be happy if DTN WG comes up with a best way forward here.

[EB] My only concern regarding test vectors was that there is no new algorithm here. But they certainly don't hurt! I can generate some vectors for this document.

-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

---

From: "Birrane, Edward J." <[email-masked]>
Date: Wed, 14 Apr 2021 12:39:24 +0000

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

---

> From: Rick Taylor <[email-masked]>
> Sent: Friday, April 09, 2021 4:00 AM
> To: [email-masked]; [email-masked]; Birrane, Edward J.
> Cc: [email-masked]
> Subject: [EXT] Re: AD review of draft-ietf-dtn-bpsec-default-sc-02
> 
> APL external email warning: Verify sender [email-masked]
> 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.
> 
> >     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
> >     > The BCB-AES-GCM security context shall have the security context
> >     >     C5: Agreed this might become an issue for interoperability.
> > For example, if
> >     > generation/communication differ on different nodes, there may be
> > interop
> >     > problems. The DTNWG consensus was this limitation is appropriate
> > for now
> >     > [ZS] Ok, then clearly stating that helps. It was clearly mention
> > in the other
> >     > place(s).
> >     >
> >     >
> >     >     > * Section 6.3
> >     >     >
> >     >     C17: I would support removing the fragmentation section from
> > this
> >     > can just refer to it. The question really is, where does it make
> > more sense put
> >     > the SECART review and similar to C17 above, I think that example
> > encodings