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

From: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" <[email-masked]>
Date: Mon, 2 Jun 2014 18:01:06 +0000

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

---

From: Amy Alford <[email-masked]>
Date: Mon, 2 Jun 2014 20:53:06 -0400

On Mon, Jun 2, 2014 at 2:01 PM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES
CONTRACT] <[email-masked]> wrote:

>
> ·         I don’t see a simplification of the dictionary issue as-is
> either; although, the separating semicolons are not really needed.
>
We discussed this when brainstorming the draft, and I was concerned that
the uri "dtn:foo" and the uri "dtnf:oo" hash to the same thing if you
cannonicalize without the colon.  Similarly, if there's no delimiter
between dictionary entries, there's ambiguity.  I don't see anything
nefarious you can do with this, but it's undesirable that two different
bundles have the same hash, even if one of them is nonsense.

---

From: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" <[email-masked]>
Date: Tue, 3 Jun 2014 12:49:36 +0000

Sorry, I should have double checked the spec instead of relying on memory. I was referring to the delimiter between the entries which is a comma rather than a semicolon but you covered both possibilities. Basically, the dictionary and the block EID references can be manipulated to include and point to a bogus URI that canonicalizes to the same string as the original block EIDs so that it would pass the integrity check but cause issues trying to use the bogus URI. Even using a separator delimiter, it is possible to replace two or more URIs with a single bogus URI by including the separator delimiter(s) and it would be a valid URI to boot -- replace the two EIDs “dtn:foo”,”dtn:bar” with the single EID “dtn:foo,dtn:bar”.

I had not thought of that sort of deviousness and I think it helps bolster Scott’s case to get rid of the dictionary in the “RFC5050bis”.

David Zoller
COLSA Corporation
MSFC/HOSC - C107
•Office: (256) 544-1820
•EMail: [email-masked]<mailto:[email-masked]>

From: Amy Alford [mailto:[email-masked]]
Sent: Monday, June 02, 2014 7:53 PM
To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]
Cc: Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]; Birrane, Edward J.; [email-masked]
Subject: Re: [dtn-security] Updated SBSP Document - Canonicalization of Extension Blocks

On Mon, Jun 2, 2014 at 2:01 PM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] <[email-masked]<mailto:[email-masked]>> wrote:

•         I don’t see a simplification of the dictionary issue as-is either; although, the separating semicolons are not really needed.
We discussed this when brainstorming the draft, and I was concerned that the uri "dtn:foo" and the uri "dtnf:oo" hash to the same thing if you cannonicalize without the colon.  Similarly, if there's no delimiter between dictionary entries, there's ambiguity.  I don't see anything nefarious you can do with this, but it's undesirable that two different bundles have the same hash, even if one of them is nonsense.

---

From: "Scott, Keith L." <[email-masked]>
Date: Tue, 3 Jun 2014 13:08:47 +0000

I think getting rid of the flexibility of supporting different naming schemes (e.g. the ipn and dtn schemes, among others) would be a bad thing.  Keeping that flexibility while ditching the dictionary would probably involve some extra overhead for non-ipn-scheme names, but that might be acceptable given the security and complexity issues.

                        --keith

From: dtn-security [mailto:[email-masked]] On Behalf Of Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]
Sent: Tuesday, June 03, 2014 8:50 AM
To: Amy Alford
Cc: Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]; [email-masked]
Subject: Re: [dtn-security] Updated SBSP Document - Canonicalization of Extension Blocks

David Zoller
COLSA Corporation
MSFC/HOSC - C107
•Office: (256) 544-1820

Cc: Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]; Birrane, Edward J.; [email-masked]<mailto:[email-masked]>

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Tue, 3 Jun 2014 14:13:44 +0000

I think that is exactly the right approach.

Scott
________________________________
From: Scott, Keith L. [[email-masked]]
Sent: Tuesday, June 03, 2014 6:08 AM
To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]; Amy Alford
Cc: Burleigh, Scott C (312G); [email-masked]
Subject: RE: [dtn-security] Updated SBSP Document - Canonicalization of Extension Blocks

                        --keith

David Zoller
COLSA Corporation
MSFC/HOSC - C107
•Office: (256) 544-1820