Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-dtn-tcpclv4-15

"Christopher Wood" <caw@heapingbits.net> Thu, 07 November 2019 01:57 UTC

Return-Path: <caw@heapingbits.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB4D12008F; Wed, 6 Nov 2019 17:57:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=DBIQxiPV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PIQ5Zq0R
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 R6PNQU7bKRYS; Wed, 6 Nov 2019 17:57:40 -0800 (PST)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C892120045; Wed, 6 Nov 2019 17:57:40 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 7810E529; Wed, 6 Nov 2019 20:57:39 -0500 (EST)
Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Wed, 06 Nov 2019 20:57:39 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=C72BMrL6jBquhnXCh742VpbGfDez gMlqrBOXVMSgjsc=; b=DBIQxiPVnwZPs3J13zSIG156vSbKvTgbJG6mSOzynXvp +92SOLIqTipYwXVKqS79jC87XOn7sB8ESoeUybQBYQh9Z7e+4XBNb94ZLBZB9JJv 95yhfCzIUA7+66baGCfdbPYAYZyO15VCBrGMD6sqzhGJbJjavt+xV1NbUADLafVa mP6PQkdnc6XyyNn7eeYXIrQX2eZH4v1MfsRtFH/9IHM/FEWAvCIhAVYGHBCR4L1T uGO8OHGR1V5JhHQuVLAgzHjrCanTqH4OGliQ7J2O229iMo9gG/Bei8Gn0CJpg0A/ EMqDeuEMlBljBKincKAAUgzDKTxnwdT8qN+ZWeNpqQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=C72BMr L6jBquhnXCh742VpbGfDezgMlqrBOXVMSgjsc=; b=PIQ5Zq0RwcfTAnCGuXM+sO ChYOGiT4192y8Gi5eY6KLalnYMzXh264a/0i1r5xjpcKmaDlGyFWgQoqv8aiLG63 IRzsysYNxMH67RNLX9dhRmv0z+G+OD8NF8OqIJzPHERqqSRIlZJNn9czHhmPjxS4 bL0fdk+qxKVJpOmHEnewKmgcwdwPWK8+qt+TVSvCSXixf4HNb7VRKA8bH+kj14U3 2dhmw+p/g7e1vPUa+19+24l75TW3xIOmAvd3WBfgi0ThmNf3fKrQ3+sh5a4VnnMA E/rq+i058xyWXnYysvRU/zZeq+d6FDqJCb7ynAq/lXBiTPqH9q45NPj6lj1QgPKA ==
X-ME-Sender: <xms:EnrDXYOjIjCAPW9UyIDslaNV9eqTog3bZXB0Xkn-xQs0SgdQQoep_A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddukedggedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepmhhithhrvgdrohhrgh dpihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhi nhhgsghithhsrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:EnrDXTNGkJUA-b-wp8fKhJvb8F9UtIT9FtYaj_jOi4GvWqyepy34fQ> <xmx:EnrDXaSiLgCrjQsRn_J5E2P8FKJOBiNQeP2gYghvUJSVSIc_MNDZwQ> <xmx:EnrDXVChKTAyrbJNykfRT0IqDSUpzPeImRrcmyk1a93vSBdZjT5c6A> <xmx:E3rDXd8EY-JNgFgkQksNWwnA3eaOpsDFYRboAIC702pDohTgUQB2Rg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id A98083C00A1; Wed, 6 Nov 2019 20:57:38 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1
Mime-Version: 1.0
Message-Id: <576b4769-ae0f-4821-a127-12a8a3d05de1@www.fastmail.com>
In-Reply-To: <157309030845.20168.4543125034732217684@ietfa.amsl.com>
References: <157309030845.20168.4543125034732217684@ietfa.amsl.com>
Date: Wed, 06 Nov 2019 17:57:18 -0800
From: "Christopher Wood" <caw@heapingbits.net>
To: "secdir@ietf.org" <secdir@ietf.org>
Cc: last-call@ietf.org, draft-ietf-dtn-tcpclv4.all@ietf.org, dtn@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/8dL6ptKmyFTkeZCdxkQFOEeMN1I>
Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-dtn-tcpclv4-15
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Nov 2019 01:57:43 -0000

Oops. Datatracker butchered the formatting. Let's try that again:

~~~

Reviewer: Christopher Wood
Review result: Has Issues

Comments:
- Section 1.1, fourth bullet: I assume certificate revocation is also out of scope. If so, listing this explicitly might be useful. If not, why not? Relatedly, is pre-shared key authentication supported? If so, perhaps we should mention that this too is out of scope?
- If TLS sits below TCPCL and if resumption is used, what is the definition of a session's lifetime? Is it still bound to the underlying TCP connection lifetime? I would suggest that the definition be generalized to accommodate TLS, e.g., perhaps the lifetime is bound to the underlying transport state lifetime. Relatedly, is TLS session resumption supported (or encouraged)? When discussing TLS session establishment in Section 4, this seems to be omitted.
- Section 3.2, first paragraph: What does "initiate TLS security" mean, exactly? Does this mean the initiator sends a TLS ClientHello upon TCP connection establishment, or only after some other TCPCL headers are exchanged? Similarly, is the Node ID transferred used in authenticating such a TLS connection? If so, how? Is the Node ID sent as the TLS SNI, as hinted at in Section 4.4.1 and 4.4.2, is it included in the responder's certificate SAN list, etc? I think specific details are needed here, perhaps with forward pointers to Section 4 as needed.
- Section 3.2: It's not clear to me how SESS_TERM translates to graceful TLS termination (to avoid truncation attacks). The state machine diagram outlined in Section 3.3 suggests that SESS_TERM, once negotiated, does imply the end of the data transfer. It therefore seems possible for an attacker to truncate data sent between receipt of SESS_TERM and TCP FIN by simply closing the TCP connection. It would be good to require use of a TLS closure alert when finished to avoid this type of truncation. (Maybe BP prevents this by marking data transfer lengths. However, even if that's the case, proper use of TLS seems prudent.)
- Section 4, first paragraph: If entities are encouraged to keep sessions alive for as long as possible, guidance on how to update TLS keying material (via key updates or explicitly tearing down the connection and starting anew) seems prudent. TLS has a bound on how much data can be encrypted under one key. 
- Section 4: This text:

  Once a TCP connection is established, each entity MUST immediately
  transmit a contact header over the TCP connection.

suggests that TLS does *not* proceed as normal upon TCP connection establishment. This is quite problematic, since any active attacker can simply muck with the ContactHeader CAN_TLS bit to disable TLS, right? Is this threat not considered in scope? Relatedly, what is the threat model? (SSL stripping is mentioned in Section 8, but without mention of a threat model.) "Secure" sessions subject to active downgrade do not offer much in the way of security, and the document should acknowledge that in the Security Considerations. Concretely, how about the following text to replace the second paragraph in Section 8?

   TCPCL does not protect against active network attackers. In particular, an
   active man-in-the-middle attackers to set the CAN_TLS flag to 0 on either 
   side of a TCPCL ContactHeader exchange.  This leads to the "SSL Stripping" 
   attack described in [RFC7457].  

   If TLS is desired for use on any TCPCL network, it is strongly encouraged that
   the security policy disallow use of TCPCL when "Enable TLS" is
   negotiated to false.  This requires that the TLS handshake occurs,
   regardless of the policy-driven parameters of the handshake and
   policy-driven handling of the handshake outcome.

- Section 4.4.2: Why is the recommendation that entities "SHOULD terminate the session" if the peer's certificate is untrusted, rather than "MUST terminate the session"? In what circumstances would an entity not want to terminate the connection? (Later text mentions that this may be allowed by "security policy," in which case we should mention that here.)
- Section 4.4.2, fourth paragraph: Why is host name validation done *after* TLS completes, rather than during the connection? This seems wrong, though I suspect I'm misunderstanding the details.
- 4.7, Enable TLS: If security policy allows the absence of TLS, why not just always use TLS and have that policy tune TLS peer authentication? (See https://tools.ietf.org/html/rfc7858#section-4.1 for an example of this.) It seems strange that opportunistic security is supported (and desired as a feature?) yet not always used.
- Section 8: I see no reason why one would want to use TLS for authentication without any form of confidentiality. I would remove text referencing this use case.
- Section 8: In describing volumetric DoS attacks, it might help to consider the "opposite" sort of attack, e.g., similar to what the HTTPT/2 data dribble attack exploited? (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9511)

Nits:
- Section 2.1, TCP Connection: typo in "and other states association" (should be associated?)
- Section 2.1, Transmission Intermediate Progress: typo "transferr" (and elsewhere)
- Inconsistent notation of SESS_TERM (it's referred to as SESSTERM in lots of places)
- Section 3.4, last paragraph: typo "from from"
- Section: typo "negotating"