Re: [dtn] BPSec interop contexts

"Birrane, Edward J." <Edward.Birrane@jhuapl.edu> Tue, 01 December 2020 16:05 UTC

Return-Path: <Edward.Birrane@jhuapl.edu>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BC03A0E00 for <dtn@ietfa.amsl.com>; Tue, 1 Dec 2020 08:05:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhuapl.edu
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 bFlKvubz7sUh for <dtn@ietfa.amsl.com>; Tue, 1 Dec 2020 08:05:06 -0800 (PST)
Received: from aplegw01.jhuapl.edu (aplegw01.jhuapl.edu [128.244.251.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3927E3A13C2 for <dtn@ietf.org>; Tue, 1 Dec 2020 08:05:04 -0800 (PST)
Received: from pps.filterd (aplegw01.jhuapl.edu [127.0.0.1]) by aplegw01.jhuapl.edu (8.16.0.42/8.16.0.42) with SMTP id 0B1Fx8XI125466; Tue, 1 Dec 2020 11:05:02 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhuapl.edu; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=JHUAPLDec2018; bh=urYMcV7NiCPC4SipuQhRMFiOINhF6UCl7dXdpeA/jwI=; b=oL7WXGVW9ORVuCNDf1yTAWnrwvS0x+tWL7FVN0j8Auhlqf1kNNfK5f+5ZVT/NKSlMfq+ RdjPsc09/35CbEgiv79z3Kn2W06vFeVI1hFu80f2mB+F6L7Rlr0zjOg6jQOf1PIjm1ak 80apzVZnjwwfJdGugj0gizxusuqhlmr73/VXnoPj+iQQw1e45jAItCx9BWNN3d/n0kXD Q47Q/fqJvQenNuxkeKcfp9mJBCWi58GMN87GhkojoisM0xpo9EnU/lxiJtTz92JXP7gr tlhXTbjqp2GblM6xsYEGgvpR8iVOCb9OVNox+/FvL+ZlsLUDIqVHInokHOSouhwsudyS eQ==
Received: from aplex01.dom1.jhuapl.edu (aplex01.dom1.jhuapl.edu [128.244.198.5]) by aplegw01.jhuapl.edu with ESMTP id 353gfa2j00-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 01 Dec 2020 11:05:02 -0500
X-CrossPremisesHeadersFilteredBySendConnector: aplex01.dom1.jhuapl.edu
Received: from aplex01.dom1.jhuapl.edu (128.244.198.5) by aplex01.dom1.jhuapl.edu (128.244.198.5) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 1 Dec 2020 11:05:01 -0500
Received: from aplex01.dom1.jhuapl.edu ([fe80::19f5:dcc5:c696:1a50]) by aplex01.dom1.jhuapl.edu ([fe80::19f5:dcc5:c696:1a50%25]) with mapi id 15.00.1497.007; Tue, 1 Dec 2020 11:05:01 -0500
From: "Birrane, Edward J." <Edward.Birrane@jhuapl.edu>
To: Brian Sipos <BSipos@rkf-eng.com>
CC: "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: BPSec interop contexts
Thread-Index: AQHWwnSVY9PKJ+JqQkiQsbGN9rMAPqnibVFQ
Date: Tue, 1 Dec 2020 16:05:01 +0000
Message-ID: <1afb3f67ecce43779b72eb7439b2c564@aplex01.dom1.jhuapl.edu>
References: <MN2PR13MB3567A858102480D24C1B90419FFB0@MN2PR13MB3567.namprd13.prod.outlook.com>
In-Reply-To: <MN2PR13MB3567A858102480D24C1B90419FFB0@MN2PR13MB3567.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [128.244.198.169]
Content-Type: multipart/alternative; boundary="_000_1afb3f67ecce43779b72eb7439b2c564aplex01dom1jhuapledu_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: aplex01.dom1.jhuapl.edu
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-01_07:2020-11-30, 2020-12-01 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/UwoDRitZuGUhwuYP2fb2UfT5zA4>
Subject: Re: [dtn] BPSec interop contexts
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Dec 2020 16:05:09 -0000

Brian,

  Great questions! Answers inline below prefaced with [EJB].

Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Principal Staff, Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423<tel:(443)%20778-7423> / (F) 443-228-3839<tel:(443)%20228-3839>


  1.  For the document subsection breakdown, there is some differences between [1] and the outline in [2]. Which one of these would you consider as the best current template for other contexts regarding terminology (e.g., "scope" vs. "interface")?
[EJB] The scot [2] is in its very early stages. The best current template is the default security context [1].   We will be updating the scot as we get more experience writing security context documents, so I wouldn't consider it to be very informative just yet.

  1.  For the interop contexts of [1] I think having AAD for both BIB and BCB are valuable to avoid replay issues. There are now security parameters to control what goes into the AAD with several options. There isn't currently any recommendation on the use of scope flags or any "Security Considerations" subsections discussing the implications of these flags. Do you anticipate that users will want to exclude AAD scope in actual use cases (and accept the replay-attack risk)?
[EJB] I think having a security considerations section in a security context document that describes when/how to use different context parameters is valuable.
[EJB] We could envision scenarios where a user would exclude AAD. Consider a case where a network adds a block to a bundle carrying idempotent network statistics. In this case, the bundle is carrying a block of information about the network, not about the bundle itself. If that block is received multiple times in multiple bundles it won't result in an error and there is no need to cryptographically bind that block to a particular bundle.

  1.  During example implementation for [3], I defined an "augmented target block" for BCB use which is just the target block with its block-type-specific-data as an empty byte string. In this way the structure of the canonical block is preserved, it's serializable as normal, and avoids having a special canonicalization of the block. But this also includes extraneous fields like the original CRC value (if present). The target block AAD used by [1] defines a different encoding of just the first three fields of the canonical block, which seems like a better alternative. Can we find a consistent name for these "first three fields of a canonical block"?
[EJB] I can't think of one.  I was going to suggest "block header" but that would also include the CRC field.
Thanks for any feedback.

[1] https://tools.ietf.org/html/draft-ietf-dtn-bpsec-interop-sc-02
[2] https://tools.ietf.org/html/draft-birrane-dtn-scot-00
[3] https://tools.ietf.org/html/draft-bsipos-dtn-bpsec-cose-03