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

Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 01 October 2020 01:57 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dtn@ietf.org
Delivered-To: dtn@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4937C3A0846; Wed, 30 Sep 2020 18:57:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dtn-tcpclv4@ietf.org, dtn-chairs@ietf.org, dtn@ietf.org, Edward Birrane <edward.birrane@jhuapl.edu>, edward.birrane@jhuapl.edu
X-Test-IDTracker: no
X-IETF-IDTracker: 7.17.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <160151744779.20238.14870506094786754296@ietfa.amsl.com>
Date: Wed, 30 Sep 2020 18:57:28 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/_GekXZAa59bTT5EG7CH5UZSozH0>
Subject: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-21: (with DISCUSS and COMMENT)
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
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, 01 Oct 2020 01:57:28 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dtn-tcpclv4-21: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[This is essentially a restatement of the comments at
https://mailarchive.ietf.org/arch/msg/dtn/jnafmsDt0OXUhYlBwT_U9PuNV5c/
but rephrased to be a standalone review rather than continuation of an
existing conversation.]

I'm really impressed by the new text about PKIX environments/CA policy,
and entity identification; thank you!

I suspect that, with one exception, we have similar understandings of
what is supposed to happen, but may need to wrangle the actual text on
the page a little more to get to the right place.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The one exception relates to the security properties of having the
certificate validation procedure be a prioritized list of steps with
which steps to use being dependent on the contents of the received
certificate.  Specifically, if we will end up letting a peer with a
DNS-ID cert authenticate as any node ID, then there is no security gain
from having the node ID in the cert in the first place, since the
attacker will just skip that step.  The value of NODE-ID comes into play
when we know, before we go into the validation procedure, that the
legitimate peer will have the expected NODE-ID in their certificate.
Obviously we cannot expect that to always be the case, given that we aim
to be compatible with DTN-Ignorant CAs, so we will need to specify some
granularity for when we do or do not require the NODE-ID to be present.
There are a number of possibilities here and I don't know which is going
to be best for the broadest group of deployments.  Some simple ideas for
consideration include:

(a) any given node either always or never requires NODE-ID
(b) any given interface either always or never requires NODE-ID
(c) push it to the discovery protocol/"out of band configuration"
(d) a trust-on-first-use-like option of "once you've seen a NODE-ID for
  a given node ID, always require NODE-ID in the future for that node
  ID.  (This has pretty significant risks without a way to "undo the
  latch" but if generating a new node ID is cheap they may be
  tolerable.)
(e) define new URI scheme(s) that have similar semantics to the current
  ones but require NODE-ID for authentication.
(f) similar to (e), apply additional granularity based on URI scheme or
  scheme-specific structure (e.g., certain prefixes/suffixes of names
  but not others

In theory there are similar considerations between DNS-ID and NETWORK-ID
(see below for comment about the "NETWORK-ID" name), but since they are
both expected to be coming from the Web PKI and both have similarly weak
models for node authentication it's not clear to me that we should spend
much effort on a complicated procedure for there.  Something simple like
"if you have a (stable) name for the peer, expect DNS-ID; if you only
have an IP address, use NETWORK-ID" should work quite well (and may even
be what you intended anyway).

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The main place where I'm still seeing a need for wordsmithing is in the
authentication procedures in Section 4.4.3.  I see from the previous
discussion that the intent of "SHALL attempt to authenticate [...] If
<validation fails> and security policy disallows an unauthenticated <X>,
the entity SHALL terminate the session" is for security policy to be
able to say "yes, there's no <X>-ID and I'm fine with that (or
potentially even "the <X>-ID that is present failed validation and I'm
fine with that"), which is a surprising wording to me but I guess
technically okay.  (The current wording strongly implies, to me, that
if validation fails, the session gets terminated; maybe it's something
about the double negative in "disallows an unauthenticated" that makes
the "security policy" aspect feel very weak.)  What seems significantly
problematic to me, though, is the requirement as-written to attempt
validation of all three types of ID (NODE-ID, DNS-ID, and NETWORK-ID).
In the expected case where a peer's certificate contains only one of the
three (or, perhaps, a NODE-ID and one other name type), this means that
security policy would have to be some complex matrix with
interdependencies between the various types (allow unauthenticated host
by DNS-ID if NETWORK-ID present and valid, etc.) that prevents
validation of each type of name being performed independently.

In particular, this "must attempt all three types" logic seems at odds
with the first paragraph of the section that says that attempting host
name validation is optional.

So, I would have expected the text to flow more along the lines of (but
written less hastily) "security policy determines, for a given connection,
which identity type(s) is expected, and validation is attempted for
those specific type(s).  Failed authentication results in session
termination." It is okay with me for security policy to allow continuing
with the connection even when validation is attempted but fails, but I'm
not sure that we currently have a fully consistent picture about
how/when this happens.  In particular, I see a note in Section 8.10.1
that using TLS in a way which does not authenticate both peers is out of
scope of this document" along with a mention of similarities to
opportunistic security, yet letting security policy proceed with an
unauthenticated peer seems at odds with that "out of scope".  We should
have a clearer picture of whether opportunistic security with no or
failed authentication of one or both peers is permitted by this
document.


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.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 4.4.1

I probably would not have picked the name "NETWORK-ID" for the iPAddress
SAN (since identifying a "network" would call to mind an IP prefix or
similar).  If you're not tied to it, I would propose "IPADDR-ID".  (Full
disclosure: I also asked the saag@ietf.org about this topic; responses
so far seem to support IPADDR-ID.)

Section 4.4.2

Apparently I didn't find this remarkable the first time around, but "the
SNI text" is not a common phrase in the TLS community; we would
typically refer to 'the contents of the "server_name" extension' or
perhaps the 'HostName in the "server_name" extension'.  In this context
such verbosity may not be needed, with "the SNI contents holds the
network-layer name for the passive entity" seeming to suffice.

Section 4.6

   Keepalive Interval:  A 16-bit unsigned integer indicating the minimum
      interval, in seconds, to negotiate the Session Keepalive using the
      method of Section 4.7.

nit: maybe "to negotiate as"?  (The current wording sounds like the
Session Keepalive is negotiated periodically at some interval.)

Section 4.7

This still has some stale "contact header" references that should be
switched to SESS_INIT (for Keeplive Interval and the MTUs), as does
section 5.1.1.

Section 8.7

We mention "renegotiation of the TLS connection", which is only defined
for TLS 1.2 and older, but we now seem to only be referencing TLS 1.3,
so renegotiation is in that sense undefined.