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

"Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" <> Tue, 03 June 2014 12:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 028301A01F3 for <>; Tue, 3 Jun 2014 05:49:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3p1o7K0XH25m for <>; Tue, 3 Jun 2014 05:49:43 -0700 (PDT)
Received: from ( [IPv6:2001:4d0:a302:1100::101]) by (Postfix) with ESMTP id 5DD9A1A01D9 for <>; Tue, 3 Jun 2014 05:49:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5A6D5D0581; Tue, 3 Jun 2014 07:43:55 -0500 (CDT)
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s53CnaNV025835; Tue, 3 Jun 2014 07:49:37 -0500
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 07:49:36 -0500
From: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" <>
To: Amy Alford <>
Thread-Topic: [dtn-security] Updated SBSP Document - Canonicalization of Extension Blocks
Date: Tue, 3 Jun 2014 12:49:36 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D9006NDMSMBX404ndcnasa_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-02_03:2014-06-02,2014-06-02,1970-01-01 signatures=0
Cc: "Burleigh, Scott C \(JPL-312G\)\[Jet Propulsion Laboratory\]" <>, "" <>
Subject: Re: [dtn-security] Updated SBSP Document - Canonicalization of Extension Blocks
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Jun 2014 12:49:48 -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
•Office: (256) 544-1820

From: Amy Alford []
Sent: Monday, June 02, 2014 7:53 PM
Cc: Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]; Birrane, Edward J.;
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] <<>> 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.