Re: [rtcweb] Please require user consent for data channels

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 17 July 2015 20:36 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422301A1B5F for <rtcweb@ietfa.amsl.com>; Fri, 17 Jul 2015 13:36:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Xrpv7qUMeOrp for <rtcweb@ietfa.amsl.com>; Fri, 17 Jul 2015 13:36:48 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6F251A1AC6 for <rtcweb@ietf.org>; Fri, 17 Jul 2015 13:36:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BC475BE55 for <rtcweb@ietf.org>; Fri, 17 Jul 2015 21:36:46 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iona3sInEQQ0 for <rtcweb@ietf.org>; Fri, 17 Jul 2015 21:36:45 +0100 (IST)
Received: from [31.133.139.135] (unknown [31.133.139.135]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7AE87BE53 for <rtcweb@ietf.org>; Fri, 17 Jul 2015 21:36:45 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1437165405; bh=uODYCnWVWimyFI1DFveV2jNCuSOOHTmKgBzS9YjykMU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=R+HcKOwDiyHuKM1esgRi9B63hqKxAZHhAMZle3dVwjRnar3N8+KrwqM6ceume6GCp 3I/5ZsOHFtRdfqbCCjoUXwEJU2rk3usxGuRzr/1i+CieVqOVVXf8d4LuADN8hAKHrL v//GmBg803/zJPC2T+spjlc0RMQ6leLOlYgh6YOM=
Message-ID: <55A9675D.2070007@cs.tcd.ie>
Date: Fri, 17 Jul 2015 21:36:45 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
References: <CA+65OspMD_PVjk0BXh7t4LtjmFDcDatoeNjFQOO_OVtC-Br+OA@mail.gmail.com> <CAOJ7v-0UBGtP0-atxP7X4OTj-H6Lost5o42aAS65mA6CEqcQsw@mail.gmail.com> <CA+65OsrhXHK+cRAFLCZFt+34vr8eRhj+CN3DgznUBfSwmWYggw@mail.gmail.com> <CAOJ7v-24VCW6kkn7LOLkqZzhYEU0r=nmd_F7Zns1rnyqKN6xAg@mail.gmail.com> <55A95364.2070806@gmail.com> <CAOJ7v-3t9BQabR2e4EHs4G0Sec4sU9DFC2aiSXXYrat+an+RYg@mail.gmail.com>
In-Reply-To: <CAOJ7v-3t9BQabR2e4EHs4G0Sec4sU9DFC2aiSXXYrat+an+RYg@mail.gmail.com>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/wxdg0sItlmrLkL8qfmnafbyq8B4>
Subject: Re: [rtcweb] Please require user consent for data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 17 Jul 2015 20:36:49 -0000

On a related point. I'm not sure it's very compelling but there is
a passing reference in [1] to using WebRTC to discover local IP
addresses as a way of assisting in an attack on rc4 - presumably
the NAT'd source address offers some more known plaintext to an
attacker that can presumably see the WPA encrypted packets and hence
helps speed up the attack. See [1] p12 for the mention, though it
lacks details.

I guess the point is that folks will find unexpected ways to
(ab)use such knowledge once it's available. The right reaction of
course in this case is to not use rc4, but equally it perhaps
provides another example of the unexpected consequences of
exposing addresses.

S.

[1] http://www.rc4nomore.com/vanhoef-usenix2015.pdf