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

["Burleigh, Scott C (312G)" <[e-mail]>]

I think that is exactly the right approach.

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

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:[e-mail]] 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]; [e-mail]
Subject: Re: [dtn-security] Updated SBSP Document - Canonicalization of Extension Blocks

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: [phone]
•EMail: [e-mail]<mailto:[e-mail]>

From: Amy Alford [mailto:[e-mail]]
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.; [e-mail]<mailto:[e-mail]>
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] <[e-mail]<mailto:[e-mail]>> 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.