[secdir] secdir review of draft-ietf-rtcweb-data-channel

David Harrington <ietfdbh@comcast.net> Fri, 24 October 2014 22:11 UTC

Return-Path: <ietfdbh@comcast.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6D9091A9176 for <secdir@ietfa.amsl.com>; Fri, 24 Oct 2014 15:11:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id HIj319IuZXzv for <secdir@ietfa.amsl.com>; Fri, 24 Oct 2014 15:11:39 -0700 (PDT)
Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 180241A909E for <secdir@ietf.org>; Fri, 24 Oct 2014 15:11:39 -0700 (PDT)
Received: from resomta-po-02v.sys.comcast.net ([]) by resqmta-po-12v.sys.comcast.net with comcast id 7ABT1p0024tLnxL01ABeEQ; Fri, 24 Oct 2014 22:11:38 +0000
Received: from [IPv6:2601:6:6f00:495:78d5:e259:ee7:d398] ([IPv6:2601:6:6f00:495:78d5:e259:ee7:d398]) by resomta-po-02v.sys.comcast.net with comcast id 7ABc1p0054dsUhn01ABdyz; Fri, 24 Oct 2014 22:11:38 +0000
From: David Harrington <ietfdbh@comcast.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EB1312CC-BAEC-4EE7-9045-459EFC757FF7"
Date: Fri, 24 Oct 2014 18:11:31 -0400
To: secdir@ietf.org, draft-ietf-rtcweb-data-channel.all@tools.ietf.org
Message-Id: <25AA1780-FCF9-498E-96A1-046C03D509BD@comcast.net>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414188698; bh=g0gMeM/Av4K06UuG/FRpA7UulpZy/+CYp90WIgKfXOQ=; h=Received:Received:From:Content-Type:Date:Subject:To:Message-Id: Mime-Version; b=OIKGr71jctbbmCR7Ap/QeVJusGRum3o0H0m9ExIaX66R9WilsEX6wH1NEJ8knbMUg LLTc7y1f3/Q+alJ7JgtmgBsjt7+DywJ884g6bNiCBl9Ar0Z/qUnjIZwE6nnHIMhVEQ urqwpIGvLI0LXb1Xiz8fxrLr0EI9UWjQCCL/s+1zINGyjvNgRKAfhMaLy9/7SAgDtK jRklrDbI+KG8eCq6TB11swfRhRgmuYPerJEvUR7WDEO3HTO7rE+uT5WyTdLhpKtjh5 IxNaNq0JAAXfL1bk8CpIcPfMadR0qrv+GEvqKuqAslwJXycTDRX3QSjliqPUqr4rbq Rni/E7rR7HKlg==
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/-3RS5xsaaX5akEYFedPk13B33K8
Subject: [secdir] secdir review of draft-ietf-rtcweb-data-channel
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 24 Oct 2014 22:11:42 -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.
I think this document is not ready. 

A few comments.
1) This proposal stacks a number of protocols - SCTP/DTLS/ICE - with which I am not intimately familiar.
I cannot tell whether using these in combination opens any holes.

2) one of the use cases pertains to avoiding internet filtering and monitoring of HTTP messages. 
From a security perspective, I find this undesirable, but it is probably a real world use case.

3) This document has dependencies on 8 different internet drafts - 
features in [I-D.ietf-tsvwg-sctp-prpolicies] MUST be supported.
features in [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used.
[I-D.ietf-rtcweb-jsep] will establish the connection,
and so on …

It is hard to assess the security of the system when so many pieces are yet to be “fixed”. Security is a process.
While this could be put through with downlinks, I think it important to understand how those pieces fit with this document to create system, before this part should be approved.

4) section 6.2 specifies some sentences using “will”; I think to make the standard unambiguous, these should be converted into RFC2119 keywords.

5) section 6.2 says "typically this will be shared via BUNDLE or equivalent”. Without knowing what will be used, it is difficult to assess the security implications.

This is being submitted as standards-track, and I think the language needs to be tightened up considerably to determine whether an implementation is standard-compliant. Which of these options are mandatory to implement for compliance, and which are optional?

6) section 6.2 says "The number of streams negotiated during SCTP association setup SHOULD
   be 65535, which is the maximum number of streams that can be
   negotiated during the association setup.” It is unclear to me whether the following paragraphs explain why the maximum number of streams should be negotiated. If so, then I think this should be made clearer. If not, then I think a justification for negotiating the maximum should be provided.

7) section 6.4 says “A strong wish if for the application-level API to be close to the
   API for WebSockets ...”; Can I assume that by “close to” the authors mean “similar to”?
I think the text in 6.4 needs to be tightened, using RFC2119 keywords.
“each data channel has the following properties …”; I cannot tell whether this is defining properties that must be implemented or is a description of the properties that happen because this proposal uses SCTP. 

8) 6.5 saya "If it attempts to re-use a stream which is part of an existing data channel, the addition SHOULD fail.” I have a concern that this is not a MUST. Are there security implications if this is not a MUST?

9) 6.6 again could use some RFC2119 keywords. I think the whole section should be looked at for keywords, but have particular concern about error handling and die limitations. If an implementer ignores the SHOULD limit to 16KB, what impact both from an operational perspective and a security perspective will this have?

10) I don’t think pointing to a generic rtcweb security document is sufficient. The security considerations section in this document should discuss the security implications of various implementation choices specific to this document. There are a number of SHOULDs in this document. What are the security implications of not applying the SHOULD,? see my point #9, for example. Could this be exploited to create a DOS attack? 

Hope this helps,

David Harrington