[secdir] Secdir last call review of draft-ietf-dtn-tcpclv4-15

Christopher Wood via Datatracker <noreply@ietf.org> Thu, 07 November 2019 01:31 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 839FA120121; Wed, 6 Nov 2019 17:31:48 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Christopher Wood via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: last-call@ietf.org, draft-ietf-dtn-tcpclv4.all@ietf.org, dtn@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.110.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Christopher Wood <caw@heapingbits.net>
Message-ID: <157309030845.20168.4543125034732217684@ietfa.amsl.com>
Date: Wed, 06 Nov 2019 17:31:48 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/h4A82jsoDMEzYIoiahg9CmIq2WU>
Subject: [secdir] Secdir last call review of draft-ietf-dtn-tcpclv4-15
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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:31:49 -0000

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"