Subject: Re: [dtn] BPSec interop contexts

From: "Birrane, Edward J." <[email-masked]>
Date: Tue, 1 Dec 2020 16:05:01 +0000

Brian,

  Great questions! Answers inline below prefaced with [EJB].

Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Principal Staff, Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423<tel:(443)%20778-7423> / (F) 443-228-3839<tel:(443)%20228-3839>

  1.  For the document subsection breakdown, there is some differences between [1] and the outline in [2]. Which one of these would you consider as the best current template for other contexts regarding terminology (e.g., "scope" vs. "interface")?
[EJB] The scot [2] is in its very early stages. The best current template is the default security context [1].   We will be updating the scot as we get more experience writing security context documents, so I wouldn't consider it to be very informative just yet.

  1.  For the interop contexts of [1] I think having AAD for both BIB and BCB are valuable to avoid replay issues. There are now security parameters to control what goes into the AAD with several options. There isn't currently any recommendation on the use of scope flags or any "Security Considerations" subsections discussing the implications of these flags. Do you anticipate that users will want to exclude AAD scope in actual use cases (and accept the replay-attack risk)?
[EJB] I think having a security considerations section in a security context document that describes when/how to use different context parameters is valuable.
[EJB] We could envision scenarios where a user would exclude AAD. Consider a case where a network adds a block to a bundle carrying idempotent network statistics. In this case, the bundle is carrying a block of information about the network, not about the bundle itself. If that block is received multiple times in multiple bundles it won't result in an error and there is no need to cryptographically bind that block to a particular bundle.

  1.  During example implementation for [3], I defined an "augmented target block" for BCB use which is just the target block with its block-type-specific-data as an empty byte string. In this way the structure of the canonical block is preserved, it's serializable as normal, and avoids having a special canonicalization of the block. But this also includes extraneous fields like the original CRC value (if present). The target block AAD used by [1] defines a different encoding of just the first three fields of the canonical block, which seems like a better alternative. Can we find a consistent name for these "first three fields of a canonical block"?
[EJB] I can't think of one.  I was going to suggest "block header" but that would also include the CRC field.
Thanks for any feedback.

[1] https://tools.ietf.org/html/draft-ietf-dtn-bpsec-interop-sc-02
[2] https://tools.ietf.org/html/draft-birrane-dtn-scot-00
[3] https://tools.ietf.org/html/draft-bsipos-dtn-bpsec-cose-03

---

From: Brian Sipos <[email-masked]>
Date: Wed, 9 Dec 2020 23:07:53 +0000

Ed,
Thanks for the extra info.

Focusing on the security scope (i.e. the AAD for BIB and BCB) the current draft makes the default scope parameter value zero, meaning no context is included in AAD. It seems like better policy to make the default scope 7 (all bits set) and allow the inclusion of an explicit parameter if the scope is desired to be reduced. Does this seem sensible?

Also related to scope, is there actually any benefit to include the security block context (as written, just the first three block fields) as AAD?
COSE makes a similar, but more fine-grained, distinction between "protected" and "unprotected" headers and the consensus of the COSE WG was to include the algorithm identifier in the protected header, which for BPSec is analogous to the Context ID. Is there a reason to include canonical block fields but not the Context ID?

________________________________
From: Birrane, Edward J. <[email-masked]>
Sent: Tuesday, December 1, 2020 11:05
To: Brian Sipos <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: RE: BPSec interop contexts

Brian,

[EJB] The scot [2] is in its very early stages. The best current template is the default security context [1].   We will be updating the scot as we get more experience writing security context documents, so I wouldn’t consider it to be very informative just yet.

[EJB] We could envision scenarios where a user would exclude AAD. Consider a case where a network adds a block to a bundle carrying idempotent network statistics. In this case, the bundle is carrying a block of information about the network, not about the bundle itself. If that block is received multiple times in multiple bundles it won’t result in an error and there is no need to cryptographically bind that block to a particular bundle.

[EJB] I can’t think of one.  I was going to suggest “block header” but that would also include the CRC field.

Thanks for any feedback.

[1] https://tools.ietf.org/html/draft-ietf-dtn-bpsec-interop-sc-02<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-dtn-bpsec-interop-sc-02&data=04%7C01%7CBSipos%40rkf-eng.com%7Cb0360c1882d045bf835c08d89612de41%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637424355073385730%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3lB%2BRSbXBOBfi9EsJ4FZ355pmC%2FiAC0L8NGzQd%2BrHkw%3D&reserved=0>

[2] https://tools.ietf.org/html/draft-birrane-dtn-scot-00<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-birrane-dtn-scot-00&data=04%7C01%7CBSipos%40rkf-eng.com%7Cb0360c1882d045bf835c08d89612de41%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637424355073385730%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Gt6O6JmilHjDgnd%2Bt3a7nBTNWmytRrYcgc2GkUGHCQs%3D&reserved=0>

[3] https://tools.ietf.org/html/draft-bsipos-dtn-bpsec-cose-03<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-bsipos-dtn-bpsec-cose-03&data=04%7C01%7CBSipos%40rkf-eng.com%7Cb0360c1882d045bf835c08d89612de41%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637424355073395736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IWQpn0u1kaByCDNFZmbbJ7PYfktPU6dAsc%2B%2FHBfmxl8%3D&reserved=0>

---

From: "Birrane, Edward J." <[email-masked]>
Date: Sun, 13 Dec 2020 20:49:30 +0000

Brian,

  I think it's reasonable to default security scope to be inclusive rather than exclusive.

  As to how much of the security block to include in AAD:

  I think users would want to know if  the security block has changed from a BP point of view (e.g., the security block identifier was changed). However, security-block-specific information may change as part of regular processing. For example, the security targets field may change as targets are removed by security acceptors.

  My sense was the "BP information about the security block" needs to be protected and "abstract security block" information does not - because changes to abstract security block information would make it impossible to generate the correct results.

-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: Brian Sipos <[email-masked]>
Sent: Wednesday, December 09, 2020 6:08 PM
To: Birrane, Edward J. <[email-masked]>
Cc: [email-masked]
Subject: [EXT] Re: BPSec interop contexts

APL external email warning: Verify sender [email-masked]<mailto:[email-masked]> before clicking links or attachments

Ed,

________________________________
From: Birrane, Edward J. <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, December 1, 2020 11:05
To: Brian Sipos <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: BPSec interop contexts

Brian,

Thanks for any feedback.