Re: [dtn] BPSec interop contexts

[Brian Sipos <[e-mail]>]

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. <[e-mail]>
Sent: Tuesday, December 1, 2020 11:05
To: Brian Sipos <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: RE: BPSec interop contexts


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<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>