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

"Scott, Keith L." <kscott@mitre.org> Tue, 03 June 2014 13:08 UTC

Return-Path: <kscott@mitre.org>
X-Original-To: dtn-security@ietfa.amsl.com
Delivered-To: dtn-security@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907301A0268 for <dtn-security@ietfa.amsl.com>; Tue, 3 Jun 2014 06:08:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.85
X-Spam-Level:
X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3EQxP1DA1oF for <dtn-security@ietfa.amsl.com>; Tue, 3 Jun 2014 06:08:53 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A83761A01F6 for <dtn-security@irtf.org>; Tue, 3 Jun 2014 06:08:53 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E51891F0751; Tue, 3 Jun 2014 09:08:47 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id CB4571F0372; Tue, 3 Jun 2014 09:08:47 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.73]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 09:08:47 -0400
From: "Scott, Keith L." <kscott@mitre.org>
To: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" <david.a.zoller@nasa.gov>, Amy Alford <aloomis@sarn.org>
Thread-Topic: [dtn-security] Updated SBSP Document - Canonicalization of Extension Blocks
Thread-Index: AQHPfsYy11Xpp8zu6kiwkU4hBh/bXptfmg4A///BktA=
Date: Tue, 3 Jun 2014 13:08:47 +0000
Message-ID: <5EE81C5C4CFFF4418C5EAD12F49D64EE4C221E9E@IMCMBX01.MITRE.ORG>
References: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E85@NDMSMBX404.ndc.nasa.gov> <CAB9rx+-n5qyfs=tV3VPjvNhHJNocz_A7Y=3MVZP89_7cnHBC0g@mail.gmail.com> <94CFB3711B4CAE4DBFC5BEB3374BF0C60D9006@NDMSMBX404.ndc.nasa.gov>
In-Reply-To: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D9006@NDMSMBX404.ndc.nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.140.19.249]
Content-Type: multipart/alternative; boundary="_000_5EE81C5C4CFFF4418C5EAD12F49D64EE4C221E9EIMCMBX01MITREOR_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/ns0RhBg1cfzKE_OyrS_Fn-AO_xk
Cc: "Burleigh, Scott C \(JPL-312G\)\[Jet Propulsion Laboratory\]" <scott.c.burleigh@jpl.nasa.gov>, "dtn-security@irtf.org" <dtn-security@irtf.org>
Subject: Re: [dtn-security] Updated SBSP Document - Canonicalization of Extension Blocks
X-BeenThere: dtn-security@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." <dtn-security.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-security/>
List-Post: <mailto:dtn-security@irtf.org>
List-Help: <mailto:dtn-security-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jun 2014 13:08:58 -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:dtn-security-bounces@irtf.org] 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]; dtn-security@irtf.org
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: (256) 544-1820
•EMail: david.a.zoller@nasa.gov<mailto:david.a.zoller@nasa.gov>

From: Amy Alford [mailto:aloomis@sarn.org]
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.; dtn-security@irtf.org<mailto:dtn-security@irtf.org>
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] <david.a.zoller@nasa.gov<mailto:david.a.zoller@nasa.gov>> 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.