[secdir] Security Directorate review of draft-ietf-clue-datachannel-13

Barry Leiba <barryleiba@computer.org> Fri, 15 July 2016 19:39 UTC

Return-Path: <barryleiba@gmail.com>
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 ACAE312DD56; Fri, 15 Jul 2016 12:39:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 MJE3RSagaH9E; Fri, 15 Jul 2016 12:39:33 -0700 (PDT)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5513712DD54; Fri, 15 Jul 2016 12:39:30 -0700 (PDT)
Received: by mail-yw0-x232.google.com with SMTP id l125so110875210ywb.2; Fri, 15 Jul 2016 12:39:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=StMCrC/jylLi6kjuYEUvqBafKapoFyDUtxWFbkgOzoE=; b=yS4A3/k4KxpVq7L2PGgmhJWTKekmBCX7yFwYxqCRcW5ofL7p0jpvrHVjqOsxWe5RW2 mzh6PafNWMeTEf15+xDsx5mIQ/6AnaHWDiYorV+O6avkXuv/qbrd+Oud6EjiyTCk0Hyw eiy85sbW9d+aW6J2zV2O3+brwdDoGtzpSUUJzApwKOS7neIYMG9prwe5+idUob/Jd9Qm 99Y/WE/RszN05z2IYttG3bRO84nQrgBC+VmQWdn1CZ56mXfWd05u61GQZQPqCo+glPt0 R+jOSx2MZN2JxlkGZmBtN8KHDlYsFyCmsdPDxh5V9vJ4n9QxnQR0fPv5tUSiB4rb7Lse eIRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=StMCrC/jylLi6kjuYEUvqBafKapoFyDUtxWFbkgOzoE=; b=g1KMOkMnJaMKQ29wjaJUNox3N7CjD/HnCrMzOMIqgQ5+bxsQ9gaemKB0XlkwtSUY9K 0lDKB/5ZTtncaGP/B4pEWxcuQ16h/xhoEPkRXQhYbUivZtTB3d/uLTperNFmiRKqrFnZ 8DOCRWrRXzuTDC6tpmamVIHjjGqgyA8221l1JmxhtjtEtXeZXg47hvJxW4WsF0OKu2zI ZZfJvw/XE+6c6aOJsGwpVf2vZ0sUQ0REW975FrRuvOUYeiFjuV8PMi5n3o2p9SejgvYr 0g1jtlDgs9+d6a7g46XzeKelFt+PX3haiDUNAhfoPmNdaHovTl4wUiXeQY680uzhcJHf B9og==
X-Gm-Message-State: ALyK8tLsqwpYYAJ8P1xhRcEvN0KLnLh9Gy2M6SfJgc/9UCck3hpMxoa82r8ih/te4gno9Chrc9T5jN3IMOhfPw==
X-Received: by 10.37.52.87 with SMTP id b84mr15452469yba.60.1468611569239; Fri, 15 Jul 2016 12:39:29 -0700 (PDT)
MIME-Version: 1.0
Sender: barryleiba@gmail.com
Received: by 10.83.33.137 with HTTP; Fri, 15 Jul 2016 12:39:28 -0700 (PDT)
From: Barry Leiba <barryleiba@computer.org>
Date: Fri, 15 Jul 2016 15:39:28 -0400
X-Google-Sender-Auth: PYTlumXe4suEztmsrDvh8cYlVRQ
Message-ID: <CALaySJJrgfRyrMAYAfRwKSBq0QAcXNZnNZx7gCPu_713DXPLGg@mail.gmail.com>
To: draft-ietf-clue-datachannel.all@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/2C6vuAwMxrpOAwzU89ZkH4BSab0>
Cc: clue@ietf.org, ietf@ietf.org, secdir@ietf.org
Subject: [secdir] Security Directorate review of draft-ietf-clue-datachannel-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 15 Jul 2016 19:39:35 -0000

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.

This document is ready for publication.  It's well written, and, while
I have a few minor comments, they are only of the most minor sort.

-- Section 3.1 --

   As described in [I-D.ietf-rtcweb-data-channel], the SCTP streams
   realizing a WebRTC data channel must be associated with the same SCTP
   association.  In addition, both SCTP streams realizing the WebRTC
   data channel must use the same SCTP stream identifier value.  These
   rules also apply to a CLUE data channel.

I don't know that it matters a lot, but this seems to be an odd way of
saying that because a CLUE data channel is a WebRTC data channel, a
CLUE data channel behaves like and has the same rules as a WebRTC data
channel.  I think I might word it more straightforwardly that way,
something like this:

NEW
   Because a CLUE data channel is a special case of a WebRTC data
   channel [I-D.ietf-rtcweb-data-channel], a CLUE data channel behaves
   like a WebRTC data channel and abides by the same rules.  In particular,
   the SCTP streams realizing a WebRTC data channel must be associated
   with the same SCTP association, and both SCTP streams realizing the
   WebRTC data channel must use the same SCTP stream identifier value.
END

Worded that way, it also supports the many other times in the document
that you point out things that rtcweb-data-channel says that affect
CLUE data channel behaviour.

But, as I said, I don't know that it matters a lot, so... just a suggestion.

-- Section 3.2.3 --
I think I'd move (or copy) the citation of [I-D.ietf-clue-protocol] to
Section 1, where "CLUE protocol" is first mentioned.

-- Section 3.3.1.1 --

   CLUE entities SHOULD NOT transport the SCTPoDTLS association used to
   realize the CLUE data channel over TCP (using the "TCP/DTLS/SCTP"
   proto value), unless it is known that UDP/DTLS/SCTP will not work

Are there other reasons to transport over TCP other than "knowing that
UDP/DTLS/SCTP will not work"?  If so, OK.  If not, then I think you
really mean "MUST NOT ... unless ...."

-- References --
I don't think RFC 3264 is normative.

-- 
Barry