Re: [dtn] Martin Duke's Discuss on draft-ietf-dtn-tcpclv4-22: (with DISCUSS and COMMENT)

Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 10 December 2020 16:40 UTC

Return-Path: <magnus.westerlund@ericsson.com>
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 E88FE3A10D4; Thu, 10 Dec 2020 08:40:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.092
X-Spam-Level:
X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 Gp-CQwwbdsO3; Thu, 10 Dec 2020 08:40:44 -0800 (PST)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50058.outbound.protection.outlook.com [40.107.5.58]) (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 6836B3A10D6; Thu, 10 Dec 2020 08:40:43 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IXfrXgmounDqcsiov35Rbb4ijgavJ5FUuf0ZNwC7HoTS4dvQhs4am9Sca4m3E7Vxd3gegZBh/zFwjQTmmZVLgurIEOamX/kCx1iE1cTaBE6uHU9Qo1zjT67KA8AOcOwwSC9VGaO+E4jC+LxwJxCme8TcPt4MGooEp6vuQm1/Z8KVJnkLY9bjggztyBdJivwnUvl43ILDAeVhRufsS+jrk2iBGkgTOABJY8Lo0/tzY7i5MnNvY7nb2mGCzJ3+nLG3XrQskuJdfNwwSiPeYlxWJh/taBMqC6pSRkSc42ol8jHQyk1IoMm0Jt0cMy2SVdp8k+As9tBx+XYg9MQyr71Btg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Wh2/ZwU4nvsus/+3LV3i+3k+EBixvvSMIrIj9jA4zcA=; b=igBRgNpyp4t8yvZ5PMFw4mGuiSf9PiYY3jK3+J/AsDYOF3w1+aFigRBIwmiISyOOsnatHRRtv8h8Mek7RyPsZSx/dUMfPNeWDMuzWZckvdaxV6T8ZKdac9sgmqXq44gykaOevMzbIUj+a0dvcGSd7RV2BnnmUOzxy7yVfdD8J8QGerv8dcweDGUyGyHGVIWGH27ZWktkHMdpVuqr+hDQSXAT7yxipasaHZgg3JdOr1C8l1GObMYSJtvyQY0Slt9spwGTZpssl+aQdbnCQbEAY53R535MGU6BUEhFfh9bYN0k2rSnnN05k3lsTuLxrP0yaJumY8BJt0Mu4nNbLMAUXQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Wh2/ZwU4nvsus/+3LV3i+3k+EBixvvSMIrIj9jA4zcA=; b=lc1RMOxLa+55VitkRzxmPMzs/9Itfb9E4q8ExzXNLU3lXmYSbOu6o35uUrKQPcIwcV+464WXnRn43XmXkBcIgqicyMvEZLmKexcI3Jv8A6bS261x65CtxU/7F/rZEfNhyrw5Cni1RDtmfpYW8fs6MpWC05AVA7D2CXIq6fXcZxM=
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB3098.eurprd07.prod.outlook.com (2603:10a6:7:38::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.5; Thu, 10 Dec 2020 16:40:38 +0000
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace%7]) with mapi id 15.20.3654.013; Thu, 10 Dec 2020 16:40:38 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "kaduk@mit.edu" <kaduk@mit.edu>, "BSipos@rkf-eng.com" <BSipos@rkf-eng.com>
CC: "dtn@ietf.org" <dtn@ietf.org>, "dtn-chairs@ietf.org" <dtn-chairs@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-dtn-tcpclv4@ietf.org" <draft-ietf-dtn-tcpclv4@ietf.org>, "edward.birrane@jhuapl.edu" <edward.birrane@jhuapl.edu>, "martin.h.duke@gmail.com" <martin.h.duke@gmail.com>
Thread-Topic: Martin Duke's Discuss on draft-ietf-dtn-tcpclv4-22: (with DISCUSS and COMMENT)
Thread-Index: AQHWtyEtdWWm/FxN8ES5ptDh1Eao3KnCdJGAgAHjHQCABzBqAIAlMOsA
Date: Thu, 10 Dec 2020 16:40:38 +0000
Message-ID: <e11453fd78270b0dc8f7cce37d16cd9100418d19.camel@ericsson.com>
References: <160479610567.30934.2651041608307943087@ietfa.amsl.com> <d7b8cefdb52977bfbb99bf2608083a2f281dc807.camel@rkf-eng.com> <CAM4esxTNouowAR_f6_WaGC7FfVabDPGjbVGjEgd4rWbBqUixYw@mail.gmail.com> <MN2PR13MB356760FBF3C9232E40C7754E9FE90@MN2PR13MB3567.namprd13.prod.outlook.com> <20201111061055.GS39170@kduck.mit.edu> <MN2PR13MB35671C56F8C002C3E9F5BE799FE70@MN2PR13MB3567.namprd13.prod.outlook.com> <20201117004708.GZ39170@kduck.mit.edu>
In-Reply-To: <20201117004708.GZ39170@kduck.mit.edu>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [158.174.130.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 90dcf902-9d9f-4292-e667-08d89d2a5355
x-ms-traffictypediagnostic: HE1PR07MB3098:
x-microsoft-antispam-prvs: <HE1PR07MB30981C76AD61E44BD8C3F34695CB0@HE1PR07MB3098.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: HxbR6Zo3EBYNUXP+iVDXtpMDtsv9AbdosjXfN6QoE/+BEafm8DnwuivYoNpTlY3fBxUZuiCOQfYLeqEdjr9uR9ZdgdHciHjq8ioZ2e2cw0e6MFSlzAXxeZ0f36WLIVZXDrpehs2umW6dzKFZS0WL2ZtYbJRmJyRh1dM4rwWpVek35TTe7ICFIZe6EWIuvJoGBMiXBVAOZKdCJUFQxoWJ2hm66BLARs3eUyzkyJLVUE2Wku8wgOflNunXs93C0sS9sBREQDQhxmIzmMKqCrI+dp3LS0ceOBgu4m7VgqwtaE1wLh8ta2PuelqjD3sHMOo/lgPy0EAr9z3+PzbUMkW4Hh8KuqeG7NPOg+KB3PEoPiHIYz2i4+052fu9E3uj+nIS
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39860400002)(366004)(136003)(396003)(376002)(66556008)(8936002)(478600001)(66616009)(2616005)(6506007)(36756003)(66446008)(99936003)(64756008)(76116006)(186003)(8676002)(66946007)(86362001)(5660300002)(44832011)(6512007)(110136005)(83380400001)(4001150100001)(316002)(2906002)(54906003)(71200400001)(26005)(66476007)(6486002)(4326008)(99106002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?ZGxxNnRpaWdPWUJVSXRVWnZuVmlHc3NoT0VGVnliaVdoWFpnMUZodGRGcGc4?= =?utf-8?B?dkNGQlF2WCs4aWdlWXk0OEp5QWRvUm5FZGVVdThhL0lvQWtpVWpYSytJZXRC?= =?utf-8?B?M1ZUYXUvbzdNWjJxWkN4OXFxWmxrSUxuQjRqRGszaXVURElweDdwOWRwd2lW?= =?utf-8?B?d0NhbTRGSVNQYk5uYXJ1QjY1WmFPZWFGM25SZmJkM1dEV1czZHBzTk9XcGwy?= =?utf-8?B?N2VuR3I1TjhsRTJkSnNrdDl3NGlUUkduZ1plTUlvSTdRdnhWWTlFNGV3N1ZW?= =?utf-8?B?cXhNaUVCWmlMSzZONllsWmg1N3pna0pNd1ArOHp2TTI4WjNDaHduS0xMYUd2?= =?utf-8?B?ZU5HdUkxK2gxM2VJMTQzRDd4Yi8zVi9aTVY4c2g0OTQrODAvTnlwbGhXZ1Nm?= =?utf-8?B?OWFQei9mamdSK1FvL25Mc3FCSFB1NE8wMVFRNkFUdmd5ZG5uVzFMc2RpbWJj?= =?utf-8?B?WXJVdXhQMmM4bmZKR0ptdHc5UDNJZ1JEdURIVUVwZmNHZ1BlYVN0M3ZOU09l?= =?utf-8?B?eFNYMERvYWlWZUplcnd3TUhBTXNUTHRpRmV1ZVpzdng2c2hFTXdhRkVzSnYw?= =?utf-8?B?UGp5WWJaa3Y1aUM0VmNQMXhaSWV1RS9sOHgzeFk5d1J1Ryt2NVlTMEgvZCtQ?= =?utf-8?B?V21ER1pCcG0xMStZbTliSE00NHpCL2JJWnZ5d3RGbCtWYjFMUFMwclhBam5i?= =?utf-8?B?V0Vhb3d2MkRVNGRFalRnVFpRRVkzRTF2aEdTMnppL3Nlc2NDS3h4L2dtWTFF?= =?utf-8?B?aXUyc0JnQTQ4aWJnTWdqZG1zVkpYYk5LSGdRZGRPYlRvTDRBMGdkRFpwZEE4?= =?utf-8?B?S3RWZHd2Z1BvOGlHNVdESEZPazJZM0JOQWtsRVhiS0FpQXc5aE5qa1g3Yll3?= =?utf-8?B?c29nQTEvNzFWL01aQzFzL0xqR1M3RkliTHdqNTFROGxDTTVsR1B5Umdxa21K?= =?utf-8?B?SGEzR0hHdCtMYWtqZitNdVJ1OUc5Qjgvb20zdEJ6anZWTWkxYVEyV1NrZjY3?= =?utf-8?B?aCthWnFtL1RCQjRSak9zQm1tVjlXKzFjcWNFRlpGWGRzNzcyYkhnK2FjdW9r?= =?utf-8?B?TDJpU1VEaG5vSG9TT2xKQ1pIUEZrdDQ4Z1Nxak5xWEFKdDdXRmRjcEw5Qlho?= =?utf-8?B?V2IrQTNkcmJiVmwxM2pJOTFNYjQ5MHMzZ3dIVWtxM3dRMitrdWNvUGc0NEs0?= =?utf-8?B?U2JGLzV2dzNsRzV3ZzZPaTVQYTZIb01GZHBFcGlaaXAyMGQxaW5NRVk0N2Ex?= =?utf-8?B?NGppcW1QdWlTbFpYSHJsckd1Skl1WXZldURiYXNnVjg4azBDcStKVVJwVTdy?= =?utf-8?Q?xQgFfWBPeuGKROc44dHIHYUde5rEZt33ZY?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-cPQW7DSApQJg8VOWXok2"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 90dcf902-9d9f-4292-e667-08d89d2a5355
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2020 16:40:38.4061 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: SeFze/5BW+LhNcCZO09m1oAnWtYzENQtgE5Gn4V/cA4r8XTMMsje8kB6l2G8+27WxtNP4bQlW4i3G48xE5JCnzba+a1olQL4ecqnLomVNmU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3098
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/tFTELEIY4F7s1wPmMsvlQarGySk>
Subject: Re: [dtn] Martin Duke's Discuss on draft-ietf-dtn-tcpclv4-22: (with DISCUSS and COMMENT)
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: Thu, 10 Dec 2020 16:40:46 -0000

Ben,

Does -24 resolve your discuss? 

Cheers

Magnus

On Mon, 2020-11-16 at 16:47 -0800, Benjamin Kaduk wrote:
> Hi Brian,
> 
> On Thu, Nov 12, 2020 at 11:00:02AM +0000, Brian Sipos wrote:
> > Ben,
> > Thank you for the references, those comments all make sense and I think
> > <draft-ietf-nfsv4-rpc-tls> is a good example of a level of detail that I can
> > use for reference. I'm editing the draft but cannot upload a new version
> > until after the datatracker freeze is lifted in a few days, but after
> > reviewing the letter-of-the-TLS-law and what some implementations that I'm
> > familiar with provide as API it appears that the application-level Session
> > Termination after a TLS handshake completion is both allowed and a
> > guaranteed way to get a consistent behavior. That's not to say that an
> > implementation couldn't do a TLS alert and close TCP connection, but either
> > way the connection is closed before any transfers can be handled.
> > 
> > As a historical note, the Node ID was originally exchanged in plaintext,
> > before a TLS handshake, but the concern was not wanting to leak identity
> > information. The current mechanism exchanges Node ID after the handshake
> > completes and the only way to get the peer Node ID earlier would be to add a
> > TLS extension (or similar) which seems really out-of-scope for this work.
> > 
> > That investigation did bring up a missing piece of logic: while the session
> > is in the Ending state there was previously no way for an XFER_REFUSE to
> > indicate that the transfer itself is fine but the entity cannot handle it
> > within that session. I'm adding a "Session Terminating" refuse reason code
> > to separate this from the "No Resources" or "Retransmit" reasons which have
> > different logic about how a retry can be done.
> > 
> > Finally, your referenced draft <draft-ietf-nfsv4-rpc-tls> defines new PKIX
> > Extended Key Usage OIDs specific to RPC. Is it expected that some new use
> > like DTN would register a new Extended Key Usage for its purpose?
> 
> It's not strictly required, but it can be helpful to have an EKU OID
> availble in some cases.  (I recommended that the NFS document allocate some
> in the initial spec so that there's a clear EKU value to use if a
> deployment chooses to go down that route, without a given site having to
> allocate their own value, etc.)
> 
> Allocating values from the SMI Security fo PKIX Extended Key Purpose
> registry is pretty straightforward and low-effort, so I'd also be inclined
> to suggest doing so for DTN.
> 
> I will get into this topic a bit more in a subsequent message elsewhere in
> the thread, but having a dedicated EKU value also gives an opportunity for
> the CA to say something about the certified entity -- typically (especially
> in the Web PKI) issuing a certificate just says that the entity controls
> the name (DNS name, email address, etc.) in question, but not anything else
> about the general trustworthiness of that entity.  Since in DTN we can be
> in a situation where we trust a node authenticated with DNS-ID or IPADDR-ID
> to give us a Node ID to use, having the EKU bit set could allow the CA to
> indicate that the holder of the certificate is more trusted to give a valid
> Node ID than some random certificate holder would be.
> 
> > We are looking at using PKIX certs for more than just transport
> > authentication, in ways which more closely resemble S/MIME. This question is
> > separate from the topic of "would any CAs even accept this usage?"
> 
> Okay.  I think the general recommendation is that such usage would get a
> distinct EKU than the TLS CL usage, though there aren't really
> hard-and-fast rules here.
> 
> -Ben
>