Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Wed, 18 November 2020 02:21 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 562163A12A3; Tue, 17 Nov 2020 18:21:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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] 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 3lIR--BlgS_M; Tue, 17 Nov 2020 18:21:21 -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 383753A1299; Tue, 17 Nov 2020 18:21:20 -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 0AI2LDFN016706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Nov 2020 21:21:18 -0500
Date: Tue, 17 Nov 2020 18:21:13 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Brian Sipos <BSipos@rkf-eng.com>
Cc: "draft-ietf-dtn-tcpclv4@ietf.org" <draft-ietf-dtn-tcpclv4@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>, "edward.birrane@jhuapl.edu" <edward.birrane@jhuapl.edu>
Message-ID: <20201118022113.GZ39170@kduck.mit.edu>
References: <158215235500.17580.7759757155303566523.idtracker@ietfa.amsl.com> <50c5dae1bc26ade7d0fcd9388873665868f7284c.camel@rkf-eng.com> <20201001015416.GE89563@kduck.mit.edu> <MN2PR13MB3567B7727DF06411E47A826A9F160@MN2PR13MB3567.namprd13.prod.outlook.com> <20201117013925.GB39170@kduck.mit.edu> <MN2PR13MB356779F92D179B1BE33D1FD59FE20@MN2PR13MB3567.namprd13.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <MN2PR13MB356779F92D179B1BE33D1FD59FE20@MN2PR13MB3567.namprd13.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/GZRTNysyB7f8ki-yau-fZrgdWic>
Subject: Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (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: Wed, 18 Nov 2020 02:21:23 -0000

Hi Brian,

On Tue, Nov 17, 2020 at 04:56:11AM +0000, Brian Sipos wrote:
> Ben,
> I really appreciate the critical eye for security implications and know that small oversights can lead to big problems.
> Part of the reason for this somewhat slow drag toward a solid set of TLS requirements is the starting point of web-PKI-focused tools and TCPCLv3 statement that "Nothing in TCPCL prevents the use of the TLS protocol to secure a connection" leaves gaps to fill.

Understood.

> Related to your earlier reply, I think that allocating a EKU OID for DTN will help to turn some of these assumptions about CA behavior into actual encoded claims of purpose. Do you think that these two can be treated as equivalent for the goal of recommended security policy?

It will help to some extent, though in practice it might not help very much
-- existing Web PKI CAs are pretty unlikely to start signing new EKUs
without a fair bit of work.  (Mostly on non-technical aspects of things, as I
understand it, though I am sure I will learn a lot at tomorrow's SAAG
presentation on what is needed to set up a PKI.)

>   1.  A certificate with an exact NODE-ID (and EKU either absent or including DTN). This leaves no doubt about the claim.
>   2.  A certificate with a DNS-ID or IPADDR-ID and with a EKU including DTN. Indicates that the CA is aware that the host is intended as a DTN node.

The two are of course not exactly equivalent, but for the purposes of a
default security policy it will probably be fine to accept either of them.
(We will want to be clear in the definition of the EKU that the semantics
include the holder of the certificate being trusted to provide a Node ID if
one is not in the certificate, though.)

> Should #2 be explicitly related to the use of opportunistic security? Only if an entity has enabled opp. sec. does the DNS-ID or IPADDR-ID matter. Otherwise, only the NODE-ID matters.
> Do other protocols make a hard separation between "enabled or disabled" in relation to opportunistic security?

In my mind #2 is a variation on non-opportunistic (or "full") security,
rather than a form of opportunistic security, though in some sense there is
a hierarchy or continuum and this is just one point on that ladder.
Usually I see "opportunistic security" used to refer to just not attempting
to authenticate the peer at all, ignoring failure to validate the expected
hostname against the presented certificate, etc., but the #2 is still doing
some partial validation, just at a different level of naming than #1.  So
I'm not entirely sure that I understand the question about a hard
separation for enabled/disabled.

> For background on how this would be used in DTN: Because DTN is an overlay network, bundle routing always requires a node to have logic related to "when a bundle needs to go to endpoint X, it's next hop should be node Y over convergence layer Z" where "Y" is the next-hop Node ID and "Z" is the transport which (for internet transports) includes either a DNS name or IP address (i.e. some way to contact the node). The idea is that a peer already has an idea of "what node am I looking to send this to" and uses that DNS name or IP address to contact that node.
> I think that this means that the in-band Node ID is superfluous for this use, and is more useful as a diagnostic "oops, I was trying to contact Z but you claim to be W" warning mode. This is how some existing DTN stacks behave.
> The benefit to having a certificate claim on a Node ID directly is that there is added agility to use multiple DNS names or IP addresses over time as network topology or access change (as a DTN is wont to do).

Thank you for this background; it is very reassuring to hear.  (It matches
my intuition on how things should work, but I don't have much confidence
that my intuition will always be correct, since this area is pretty far
from my normal areas of expertise.)  I heartily agree about the benefits of
having a Node ID directly in the certificate.

> One last topic of the authentication logic: I did originally look at requiring it that way, but the current text has a behavior which that type of logic does not; if a certificate does contain an IPADDR-ID then the current text requires it to match the connection. The different claim types are ANDed together. If a cert has a NODE-ID and an IPADDR-ID they both must authenticate the peer, regardless of policy. Policy may only allow the absence of a claim type it may not allow a failed claim type.

I think this is actually a bad property to have, leading the system to
become unnecessarily "fragile".  In particular, the semantics of a
certificate are "the holder of the private key corresponding to this
certificate can act as the various entities named in the Subject fields",
but not "this is an exhaustive list of the names for the holder of the
private key corresponding to the certificate".  So, we might end up in a
scenario where the same entity can be named by any/all of Node-IDs A and B,
and IP addresses X and Y.  But if those identities are bundled to gether
into one certificate with A and X, and a second certificate with B and Y,
then no single certificate could satisfy a peer that is trying to talk to
node A on address Y -- with the current validation policy in the -23 the
peer would have to fail the connection no matter what certificate is
presented.

To put it more pithily: just because I have one IP address in my
certificate does not mean that all of my IP addresses are in my
certificate.

Does that help clarify my thinking?

Thanks again,

Ben