Re: [dtn] BPSec handling of target CRC

["Birrane, Edward J." <[e-mail]>]

Brian,

  BPSec intentionally does not require a specific approach to handling the CRC values of (a) a security target or (b) a security block.  Special handling of CRC values should be specified in the security contexts because the security contexts are the documents specifying the parameters, algorithms, and behaviors that change the block contents.


  For example, it might be reasonable to a BCB to take the CRC Type and CRC field of its target block and store it as a security parameter in the BCB itself and include it as part of the AAD when encrypting the target. The target could have its plain-text CRC type and result field removed, and, upon decryption, the BCB could restore the CRC information for the target.   But there are many permutations and special cases: what if a security context appends AAD inside the target block instead of as a BCB results parameter? Do you then have a CRC-used-to-generate-AAD and then another CRC in the target block which covers the updated ciphertext-with-appended-AAD?



  This is a very valuable discussion to have - but I think it should happen in the context of security contexts.



  To that end, I propose:



1.       I can add some text to BPSEC 9.3 explaining more clearly that CRC considerations include more than whether to include CRC values as AAD.

2.       Place a statement in the current default security contexts that CRC values be removed from an extension block when they are a security target (even for a BIB) and a CRC shall be calculated on an extension block when a security service is removed.



-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 <[e-mail]>
Sent: Tuesday, December 22, 2020 11:39 PM
To: [e-mail]; Birrane, Edward J. <[e-mail]>
Subject: [EXT] BPSec handling of target CRC

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



Ed,
The current BPSec draft [1] seems to be silent about what a security source is supposed to do with BIB-target block CRC Type and CRC Value fields. It's clear that adding a BIB targeting a block will affect the block-type-specific data, but not clear whether there is an obligation to also update (or remove) CRC fields while adding BIB blocks.
Likewise, I don't see any obligation of the security acceptor to do anything to "put back" any CRC fields.

Slightly related, Section 9.3 "Authorship" does recommend that security contexts take into account target block CRC fields as additional authenticated data (AAD). This is not terrible, but it adds fragility and potential interoperability problems.
The contexts in [2], correctly I think, ignore CRC type and value of target blocks for generating IPPT and AAD data.

A BIB and a BCB which both target the same block (the BIB to provide data origination, and the BCB to provide encryption) could collide if the BCB processing does not "put back" the original CRC fields. But then what if the original CRC value was invalid?
It seems like a prohibition on security sources doing anything on a target block with an invalid CRC value, or an explicit requirement that security contexts leave-out CRC value as AAD, is needed.
Although the BCB-and-BIB with the same target is prohibited when only data integrity is desired, this use case is to provide data origination bound to a security source's public key / certificate.

My own feeling on this is that security sources should preserve the CRC Type (as the block originator set it for a reason) and update the CRC Value for the new block data, and security acceptors should update the CRC Value when processing a BIB target.

[1] https://tools.ietf.org/html/draft-ietf-dtn-bpsec-25
[2] https://tools.ietf.org/html/draft-ietf-dtn-bpsec-interop-sc-02