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

Benjamin Kaduk <> Tue, 17 November 2020 01:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F19E3A0D3A; Mon, 16 Nov 2020 17:39:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V3gQwUR9D2Ca; Mon, 16 Nov 2020 17:39:33 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1BE593A0D39; Mon, 16 Nov 2020 17:39:32 -0800 (PST)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 0AH1dPKi031997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Nov 2020 20:39:30 -0500
Date: Mon, 16 Nov 2020 17:39:25 -0800
From: Benjamin Kaduk <>
To: Brian Sipos <>
Cc: "" <>, "" <>, "" <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Archived-At: <>
Subject: Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Nov 2020 01:39:35 -0000

Hi Brian,

Thanks for the updates in the -22 (and -23 that landed more recently).

On Tue, Oct 27, 2020 at 03:49:24AM +0000, Brian Sipos wrote:
> Ben et al.,
> I've posted an updated draft which includes changes to address all but one of the latest SECDIR comments. The one remaining comment relates to when TLS is supposed to be negotiated for use:

I think we need to continue the conversation about
naming/certificate-validation; more below.

> I think we can also wordsmith the setting of CAN_TLS a little more;
> previous discussion indicated a desire to (e.g.) not require TLS when
> operating over IPsec, but that's a different criterion than "capable of
> exchanging messages [with TLS]".  It's also inconsistent with a desire
> to make TLS support mandatory to implement (but not mandatory to use),
> since mandatory to implement implies mandatory to be "capable of
> exchanging messages with TLS", thus mandatory to use.
> For my own purposes and for public network use TLS would be expected, so I don't have a full idea of when TLS would be desirable to negotiate away. Would a more generic statement, inverting the current logic, such as the following work?
> When sufficient security is not supplied by network layers under TCPCL, the the CAN_TLS flag within its Contact Header SHALL be set to 1.
> When CAN_TLS flag is set to 1, the peer SHALL be capable of exchanging messages according to TLS 1.3 [RFC8446] or any successors which are compatible with that TLS ClientHello.

This phrasing would address my concerns (I gave a different alternative in
my response to Ran a few minutes ago).

Back to the topic of naming and the authentication/certificate-validation
procedures.  Instead of just looking at diffs, I went and re-read all of
§4.4 of the -23 to try to look at a coherent picture of the current draft.
I'll put some specific comments later on, but will try to stick to a
high-level picture here since I'm still not sure that we're understanding
each other very well.

In a typical PKI setup, such as the Web PKI, a CA issuing a certificate
only is making claims about the specific bits in the certificate: for
Subject information like a DNS-ID, the CA verifies that the entity
requesting the certificate controls the domain name in question, and
specific X.509 extensions or extendedKeyUsage values may have additional
semantics (and require additional CA verification of the entity requesting
the certificate).  In particular, it does not say anything about the
general trustworthiness of the holder of the certified private key -- one
example of this is how ACME/Let's Encrypt makes it easy for
spammers/phishers to get valid Web PKI certificates for their malicious
domains.  So in this document when we set up a scenario where an entity
authenticated only with DNS-ID or IPADDR-ID is then somehow trusted to
provide a valid/correct Node ID in the SESS_INIT, this is a huge leap of
faith, in the general case.  Now, if we limited our trust anchors to only
CAs that do additional validation (such as only issuing certificates to
trusted end-entities), or if we required a DTN-specific extendedKeyUsage
value and assign semantics to that EKU value that requires the CA to be
careful about who it issues certificates for, then this leap of faith can
become more controlled and limited, but with only the procedures we
describe in the -23, it's a rather unbounded risk.

Accordingly, if a given entity is willing to accept DNS-ID authentication
of a peer and any claimed Node ID from that peer, then the provable
security of the entire network of nodes that includes that entity degrades
accordingly (in the internet threat model), since the attacker can claim
any Node ID.  A more subtle security policy can improve the situation, if
we could know a priori that (for example) certain Node IDs will always be
able to provide a certificate for that NODE-ID -- then we could only fall
back to allowing DNS-ID validation plus peer-claimed Node ID when we're
initiating connections to other nodes, and we could additionaly apply some
sort of filter to which received Node IDs we allow in the SESS_INIT.  But
that requires having policy in place before we start a connection, based on
the Node ID we're trying to reach -- a reactive behavior where we wait for
what the peer gives us and try to validate that leaves us open to an
attacker manipulating us into using the weakest validation procedures.

I'd like to have a better understanding of how you picture the case with no
NODE-ID in the cert being used, and what kind of limitations can be placed
on the peer's ability to claim arbitrary Node IDs in that case.  I feel
like I'm still assuming or inferring a lot, so I don't know how well my
understanding maps to the intended usage.  I'm happy to get on a call to
chat about this (and I plan to be in the IETF 109 space a lot
this week as well).

I also have a note in my specific comments about the apparent case when
just authenticating the peer's NODE-ID is not sufficient, and we would also
insiste on DNS-ID (or IPADDR-ID) validation.  In my intuition, the Node ID
is the application-layer identity that we're trying to authenticate, and
even if the DNS-ID authentication fails we still would believe that we're
talking to the intended Node.  As I say below, "what's the motivation for
failing the connection if the NODE-ID authenticates but the DNS-ID
doesn't?"  I could imagine that there's some desire to have an initial
authentication occur during the TLS handshake, in accordance with the
typical TLS implementation behavior, and then have a separate check for the
Node ID after the TLS handshake has completed; this would keep the
components separate and have a clean abstraction barrier, but the current
description in the -23 doesn't really give me the impression that that was
the intent.

The rest of my specific comments appear below.

Thanks again,


Section 4.4.1

   Node ID:  The ideal certificate identity is the Node ID of the entity
      using the NODE-ID definition below.  When the Node ID is
      identified, there is no need for any lower-level identification to
      be present (though it can still be present, and if so it is also

It's pretty weird to say "if [lower-level identification is present] it
is also validated".  Part of why it is weird is because it's another
example of letting the as-yet-untrusted peer affect what validation
procedure is used for authenticating it, but it also feels like the
NODE-ID is the actual identifier we care about, and even if there's (for
example) DNS hijacking or NAT going on, if we have authenticated the
NODE-ID we know it's the entity we are trying to talk to.  What's the
motivation for failing the connection if the NODE-ID authenticates but
the DNS-ID doesn't?

   When only a DNS-ID or IPADDR-ID can be identified by a certificate,
   it is implied that an entity which authenticates using that
   certificate is trusted to provide a valid Node ID in its SESS_INIT;
   the certificate itself does not actually authenticate that Node ID.

Perhaps a bit meta, but trusting the end-entity with such a cert to
identify itself transitively implies trusting the CA to only issue
certificates to entries that are trusted to provide the correct Node ID.
So I'd consider adding another sentence here along the lines of
"Such trust is in general not guaranteed by PKI name certification,
though a specific set of trusted CAs may apply more stringent
certificate issuance criteria."

   The RECOMMENDED security policy of an entity is to validate a NODE-ID
   when present, and only require DNS-ID/IPADDR-ID authentication in the
   absence of a NODE-ID.

(This is still leeting the as-yet-untrusted entity affect its own
validation procedure.)

Section 4.4.3

   SHALL perform the certification path validation of [RFC5280] up to
   one of the entity's trusted CA certificates.  If certificate
   validation fails or if security policy disallows a certificate for
   any reason, the entity SHALL fail the TLS handshake with a bad
   certificate error.  Leaving out part of the certification chain can

nit: it's conventionally phrased as 'with a "bad_certificate" alert'.

   Either during or immediately after the TLS handshake if the active
   entity resolved a DNS name (of the passive entity) in order to
   initiate the TCP connection, the active entity SHALL authenticate
   that DNS name using any DNS-ID of the peer certificate.  If the DNS
   name authentication result is Failure or if the result is Absent and
   security policy requires an authenticated DNS name, the entity SHALL
   terminate the session (with a reason code of "Contact Failure").

(editorial) the actual behavior here is okay, but the way it is written
with "SHALL authenticate that DNS name" seems to strongly imply that the
entity has to go through the motions of doing that work, even if the
local security policy isn't going to care about the result.  My
preference (which you have no obligation to heed) would be to flip the
order around to say that if security policy requires the result, then it
SHALL do the DNS name authentication.
(Similarly for the IPADDR-ID and NODE-ID text, of course.)