Re: [dtn-security] Updated SBSP Document - Canonicalization of Extension Blocks

["Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" <[e-mail]>]

<DZ>
[Page 24] 3.1.2.3 Extension Block Canonicalization
Endpoint ID references in blocks are canonicalized using the de-
referenced text form in place of the reference pair.  The reference
count is not included, nor is the length of the endpoint ID text.
The EID reference is, therefore, canonicalized as <scheme>:<SSP>,
which includes the ":" character.
·         Need to include a statement to the effect:
o    Artificial EIDs as defined in this document (ssp reference is 0x00) must be skipped and are not included in the canonicalization.
<SB>

Ø  Right, the AEID's offsets don't reference text in the dictionary.  Good catch!


 [Page 24] 3.1.2.3 Extension Block Canonicalization
The block-length is canonicalized as its unpacked SDNV value.  If the
data to be canonicalized is less than the complete, original block
data, this field contains the size of the data being canonicalized
(the "effective block") rather than the actual size of the block.
·         Section 3.1.2.1 (Primary Block Canonicalization) details the length fields as 4 byte values and effectively reserves the term "unpacked SDNV value" to mean the 8 byte value. I recommend using the same convention here.
o    Personally, I would specify all SDNV values canonicalized as 8 byte values and be done with it
·         Add a statement to the effect:
o    The entirety or portion(s) of the block body data are canonicalized as is.

Ø  I agree about canonicalizing all SDNVs as 8-byte values.  FWIW, I think the canonicalization in bundle security protocol is a major pain in the neck.  Is the mutability of blocks - the need to exclude mutable fields from hash computations - the main reason for it?  Is there no way to simplify?


[Page 23] 3.1.2.2 Payload Block Canonicalization
When canonicalizing the payload block, the block processing control
flags value used for canonicalization is the unpacked SDNV value with
reserved and mutable bits masked to zero.  The unpacked value is
ANDed with mask 0x0000 0000 0000 0077 to zero reserved bits and the
"last block" bit.  The "last block" bit is ignored because BABs and
other security blocks MAY be added for some parts of the journey but
not others, so the setting of this bit might change from hop to hop.

Payload blocks are canonicalized as-is, with the exception that, in
some instances, only a portion of the payload data is to be
protected.  In such a case, only those bytes are included in the
canonical form, and additional cipher suite parameters are required
to specify which part of the payload is protected, as discussed
further below.
·         The processing control flags are pulled out and masked so the Payload block can no longer be considered canonicalized "as-is".
·         A Payload Block is the same underlying format as an Extension Block with the restriction that the 'block contains an EID-reference field' is never set and it should follow the same canonicalization methodology as that of the Extension Block
o    I propose a single "Non-Primary Block Canonicalization" section based on the finalized version of the Extension Block Canonicalization

Ø  Again I complain about canonicalization.




<AA>
I think the major issue is the dictionary, since it can be modified even if the actual eid's in the block are stable.  The flags are straightforward.  In BSP, there's also a big issue with tail chasing when a PIB block is required to include chunks of itself in it's own hash.  IIRC, SBSP avoids that entirely.

<SB>
>>           Which is a major reason that I want to get rid of the dictionary altogether in "RFC5050bis".


<DZ>

·         Could the processing flags be ignored? Ultimately, either the block makes it to the destination or it does not. If a changed flag did not prevent it getting there then would you want to discard the block or bundle if that truly was the only change?

·         The length field could be left out as a change in it should be detected in the hash of the block data

·         I don't see a simplification of the dictionary issue as-is either; although, the separating semicolons are not really needed.