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

Benjamin Kaduk <kaduk@mit.edu> Tue, 17 November 2020 00:47 UTC

Return-Path: <kaduk@mit.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 163093A179A; Mon, 16 Nov 2020 16:47:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no
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 EryO__JDlZRn; Mon, 16 Nov 2020 16:47:17 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 240E23A0420; Mon, 16 Nov 2020 16:47:16 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0AH0l87h017790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Nov 2020 19:47:13 -0500
Date: Mon, 16 Nov 2020 16:47:08 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Brian Sipos <BSipos@rkf-eng.com>
Cc: Martin Duke <martin.h.duke@gmail.com>, "draft-ietf-dtn-tcpclv4@ietf.org" <draft-ietf-dtn-tcpclv4@ietf.org>, "dtn-chairs@ietf.org" <dtn-chairs@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>, "edward.birrane@jhuapl.edu" <edward.birrane@jhuapl.edu>
Message-ID: <20201117004708.GZ39170@kduck.mit.edu>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <MN2PR13MB35671C56F8C002C3E9F5BE799FE70@MN2PR13MB3567.namprd13.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/WglfpmwAkdEGHZNZ_EC6uC9Hglo>
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: Tue, 17 Nov 2020 00:47:19 -0000

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