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

"Burleigh, Scott C (312G)" <scott.c.burleigh@jpl.nasa.gov> Tue, 03 June 2014 14:13 UTC

Return-Path: <scott.c.burleigh@jpl.nasa.gov>
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 1A4C41A019C for <dtn-security@ietfa.amsl.com>; Tue, 3 Jun 2014 07:13:54 -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 1qj8ejCrSy9e for <dtn-security@ietfa.amsl.com>; Tue, 3 Jun 2014 07:13:52 -0700 (PDT)
Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA591A0170 for <dtn-security@irtf.org>; Tue, 3 Jun 2014 07:13:52 -0700 (PDT)
Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s53EDjsg014212 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 3 Jun 2014 07:13:45 -0700
Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.156]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.182]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 07:13:45 -0700
From: "Burleigh, Scott C (312G)" <scott.c.burleigh@jpl.nasa.gov>
To: "Scott, Keith L." <kscott@mitre.org>, "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: Ac9+iuEjMG+dNHBvSEOuNdHOvLFJHgAdflgAABkGAwAAAKuDgP//nH1D
Date: Tue, 3 Jun 2014 14:13:44 +0000
Message-ID: <A5BEAD028815CB40A32A5669CF737C3B423B5CA3@ap-embx-sp40.RES.AD.JPL>
References: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E85@NDMSMBX404.ndc.nasa.gov> <CAB9rx+-n5qyfs=tV3VPjvNhHJNocz_A7Y=3MVZP89_7cnHBC0g@mail.gmail.com> <94CFB3711B4CAE4DBFC5BEB3374BF0C60D9006@NDMSMBX404.ndc.nasa.gov>, <5EE81C5C4CFFF4418C5EAD12F49D64EE4C221E9E@IMCMBX01.MITRE.ORG>
In-Reply-To: <5EE81C5C4CFFF4418C5EAD12F49D64EE4C221E9E@IMCMBX01.MITRE.ORG>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [128.149.137.114]
Content-Type: multipart/alternative; boundary="_000_A5BEAD028815CB40A32A5669CF737C3B423B5CA3apembxsp40RESAD_"
MIME-Version: 1.0
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/zzBxJfJbZkG2gakFhV6VfmvbihU
Cc: "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 14:13:54 -0000

I think that is exactly the right approach.

Scott
________________________________
From: Scott, Keith L. [kscott@mitre.org]
Sent: Tuesday, June 03, 2014 6:08 AM
To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]; Amy Alford
Cc: Burleigh, Scott C (312G); dtn-security@irtf.org
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: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.