Re: [rtcweb] Secdir last call review of draft-ietf-rtcweb-jsep-23

Harald Alvestrand <harald@alvestrand.no> Sun, 08 October 2017 02:22 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24981133085; Sat, 7 Oct 2017 19:22:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 tq5hjdexzSLz; Sat, 7 Oct 2017 19:22:19 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5EF6132944; Sat, 7 Oct 2017 19:22:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 51A8F7C3243; Sun, 8 Oct 2017 04:22:14 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeBkjCEruGCx; Sun, 8 Oct 2017 04:22:12 +0200 (CEST)
Received: from [192.168.8.111] (149-222-232.connect.netcom.no [178.232.222.149]) by mork.alvestrand.no (Postfix) with ESMTPSA id 502407C0D41; Sun, 8 Oct 2017 04:22:12 +0200 (CEST)
To: Phillip Hallam-Baker <hallam@gmail.com>, secdir@ietf.org
Cc: draft-ietf-rtcweb-jsep.all@ietf.org, rtcweb@ietf.org, ietf@ietf.org
References: <150729330872.6204.16821957868857533343@ietfa.amsl.com>
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <3a37950b-676c-05bd-f400-0bd84beacd1b@alvestrand.no>
Date: Sun, 08 Oct 2017 04:22:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <150729330872.6204.16821957868857533343@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/G6gjb01J1JUXuskepZB7UAiz0uQ>
Subject: Re: [rtcweb] Secdir last call review of draft-ietf-rtcweb-jsep-23
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Oct 2017 02:22:21 -0000

On 10/06/2017 02:35 PM, Phillip Hallam-Baker wrote:
> Reviewer: Phillip Hallam-Baker
> Review result: Ready
>
> Given the design constraints in which the protocol operates, it is hard to see
> how this could be done differently.
>
> I have two sets of security concerns. One is that implementations need to be
> designed so as to avoid buffer overrun conditions and also to prevent such
> conditions leading to a breach. Compression formats such as are inevitably used
> in video and image applications tend to make promiscuous use of nested length
> encoding formats that commonly lead to security vulnerabilities.
>
> This document does not have such a warning, having a reference on most of the
> security issues, a warning on this issue should appear in:
> https://tools.ietf.org/html/draft-ietf-rtcweb-security-08
>
> The other security concern is that giving control over the host browser to run
> pretty much arbitrary code was always going to be a security disaster but there
> isn't much that can be done at this point.
>
Participant pushback, I'm neither a WG chair or a document editor:


Was this intended as a review of a different document?

The concern about compression formats seems to be something that belongs
in compression format specifications, such as those referenced by
PAYLOAD et al. As such, it would reasonably belong in -rtcweb-security,
which pulls in security concerns from a number of fields.

The generic concern about running Javascript in the browser seems to
belong to rtcweb-overview if it belongs anywhere except in a generic
architecture critique of the browser ecosystem.

If there are concerns specific to JSEP, and the handling of SDP that is
described in JSEP, it seems appropriate to document them here. Generic
architectural issues and common security best practices don't seem to
have the right home in this document.

-- 
Surveillance is pervasive. Go Dark.