[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.
- [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-… Benjamin Kaduk via Datatracker