[tram] Secdir last call review of draft-ietf-tram-turnbis-27

Christopher Wood via Datatracker <noreply@ietf.org> Sun, 07 July 2019 20:28 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tram@ietf.org
Delivered-To: tram@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34452120094; Sun, 7 Jul 2019 13:28:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Christopher Wood via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-tram-turnbis.all@ietf.org, ietf@ietf.org, tram@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.98.3
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Christopher Wood <caw@heapingbits.net>
Message-ID: <156253133809.549.13521510978566357744@ietfa.amsl.com>
Date: Sun, 07 Jul 2019 13:28:58 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/hscZGVPt1xKR18YhH0JwVjT_pWE>
Subject: [tram] Secdir last call review of draft-ietf-tram-turnbis-27
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Jul 2019 20:28:59 -0000

Reviewer: Christopher Wood
Review result: Has Nits

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. 
Document editors and WG chairs should treat these comments just like any other
last call comments.

The summary of the review is: Ready with nits

Summary:

In general, the document is well written and clearly founded in operational
experience. The security considerations are thorough, providing examples where
necessary to highlight important problem areas. It draws a clear line between
issues best addressed by applications outside of TURN, and provides sufficient
detail for those issues in scope. My comments and questions are, hopefully,
mostly nits.

General comments:

- TURN server authentication in the case of (D)TLS is underspecified. Are
servers assumed to have WebPKI certificates, OOB-trusted raw public keys, or
something else? Is there a preferred form of authentication? Relatedly, in
Section 3.2, how do clients authenticate the server? - Section 3.7: Could TURN
servers not chunk data from stream-oriented transports (TCP or TLS) to a
preferred MTU size before relaying to peers? Specifically, there are likely
some cases wherein the server could deal with the client data messages larger
than the recommended 500B limit. On that point, should servers even accept data
larger than this recommended size? - Section 3.9: There may be cases where the
TLS connection post TCP connection establishment fails. It would therefore
seems prudent to not declare victory for one connection over the other until
TLS connects, too. - Section 3 could benefit from a subsection on replays and
the nonce role. In particular, as later discussed in the security
considerations, some of these attacks are not new to TURN and should therefore
be dealt with by the application protocol (SRTP). This section might also
describe nonce rotation policies with more specificity, as this is
underspecified in the document. - Section 3 could also benefit from discussion
about cleartext versus encryption transports between clients and servers.
Encrypting the nonce, username, realm, etc., among other things, has obvious
benefits. - Why are SOFTWARE and FINGERPRINT attributes recommended? It seems
like clients should be discouraged from sending these if anything, especially
if not used to make allocation decisions on the server. - Section 5: When
servers receive data that exceeds an allocation’s bandwidth quota, servers
silently discard this data. This means there’s no allocation-based flow control
mechanism between client and server beyond what’s provided by the transport
protocol, right? This seems fine, though perhaps some discussion of why this
design decision was made would be helpful. For example, I could imagine
explicit signals from servers to clients that indicate server state would
reveal information about other allocations on the server, which might be
problematic. - Section 7.2 suggests that servers can redirect client allocation
requests to other servers. Can this create a loop, wherein two TURN servers
redirect to one another? Moreover, is it acceptable for one TURN server to
redirect to an unrelated TURN server? (It should be made clear here that these
responses are authenticated, as otherwise it would be possible for an on-path
adversary to redirect allocation requests to a server it owns.) - Section
21.1.2: Use of (D)TLS doesn’t help against dictionary attacks much, since
presumably there’s low entropy in usernames and passwords alike. Thus, I
question whether this is a “stronger” mitigation. - Section 12.1.6: “username”
and “realm” are not considered sensitive? They seem sensitive to me. - As an
extension, it seems possible to improve on what’s in STUN. For example, it may
be worthwhile, here or elsewhere, to update STUN’s long term credential key
derivation process (MD5(username + realm + password)) to something a bit more
modern. This is quite likely out of scope, though in the context of client
authentication it seems worth mentioning that TURN is limited to the mechanisms
provided by STUN.

Nits and other comments:

- Section 2: “message-digest” is undefined in the Nonce definition.
- Section 3: It’s probably worth citing RFC8446 as the recommended version of
TLS. - Section 3.4: It might be worth mentioning that use of (D)TLS for the
client-to-server transport mitigates the need for Send and Data authentication.
- Section 3.4: What does “proper security” mean? - Figure 4: Adding another
message exchange wherein a channel message is sent without a prior ChannelBind
request would be useful to highlight this dependency and expected behavior from
clients and servers. - Section 3.6: Another benefit of this user space design
decision is use of (D)TLS links. - Section 5: Where did the 40 second request
buffer timeout come from? Adding some details might help. - Section 6: “secure
hash” is undefined, though presumably what is meant is a cryptographic hash
with collision resistance. It would be good to clarify this requirement. -
Section 7.4: What is the retry behavior if allocation requests timeout? -
Section 12.5: The STUN requirement for 4-byte alignment should be cited when
discussing the TCP and TLS padding requirement. - Section 15: Typo “DON’T
FRAGMENT”.