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

Tim Panton <tim@phonefromhere.com> Mon, 20 July 2015 12:58 UTC

Return-Path: <tim@phonefromhere.com>
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 C65C21A8770 for <rtcweb@ietfa.amsl.com>; Mon, 20 Jul 2015 05:58:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 XCfUMtIbZAw5 for <rtcweb@ietfa.amsl.com>; Mon, 20 Jul 2015 05:58:53 -0700 (PDT)
Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B157E1A8782 for <rtcweb@ietf.org>; Mon, 20 Jul 2015 05:58:52 -0700 (PDT)
Received: (qmail 55606 invoked from network); 20 Jul 2015 12:58:51 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769/0 8848
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 20 Jul 2015 12:58:51 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 1FD9F18A1B47; Mon, 20 Jul 2015 13:58:48 +0100 (BST)
Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 0886B18A18CF; Mon, 20 Jul 2015 13:58:48 +0100 (BST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <55ACEA74.8050300@jive.com>
Date: Mon, 20 Jul 2015 13:58:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <13F9D9AE-7B6B-40DE-BDD7-DDED28382EAB@phonefromhere.com>
References: <CA+65OspMD_PVjk0BXh7t4LtjmFDcDatoeNjFQOO_OVtC-Br+OA@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> <55A96DA3.1040907@gmail.com> <CAOJ7v-1ui7349NzK6NZNRHPbnHWZajctk4cDgMKqRZSv47EYdA@mail.gmail.com> <55A9860D.8030903@gmail.com> <CAOJ7v-3LGd32rnpFVW_U0s3+iVaJXsL4vt_YAo=cyp6YyOArdw@mail.gmail.com> <CALiegfmiS18Jux-kCgOhTKKiyGtMertj6xCegpFrox5NOf9EJg@mail.gmail.com> <CABkgnnW0Tmjqz823vKiF84_u6HasBJC7ERMYCO2HL_NPj5saTA@mail.gmail.com> <CALiegfkpbLy1QXxr-RRF0oOpVv1sWsFeab=vvC4iT4DnPtjKQw@mail.gmail.com> <CABkgnnVWcuhX2NjZgx87L+Uo6df6rEBWW73cxbaX3mu_VfHmCA@mail.gmail.com> <CALiegfkQWAn-jMrjhcDPA3rtowOPVk-S8z3c-jvjpNmjtf=3hA@mail.gmail.com> <CABkgnnWERM4oxozNCSvRf1o0Wm-d9Bjw=9B+xh_NJ+h6GfBJ6Q@mail.gmail.com> <7F818FAC-5559-4074-B1FC-EB9516A98FB7@phonefromhere.com> <55ACEA74.8050 300@jive.com>
To: Simon Perreault <sperreault@jive.com>
X-Mailer: Apple Mail (2.2102)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/m6p4a_nRNQ3ERb2PHzSfma6tv1c>
Cc: rtcweb@ietf.org
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: Mon, 20 Jul 2015 12:58:55 -0000

> On 20 Jul 2015, at 13:32, Simon Perreault <sperreault@jive.com> wrote:
> 
> Le 2015-07-20 14:26, Tim Panton a écrit :
>> Gulp. Whilst I mostly see the logic - it is wholly unexpected behaviour
>> to the average sys admin. 
>> Certainly not what I expected.
> 
> I don't know how you can expect ICE to work otherwise.
> 
>> It strikes me that binding to all interfaces might well give a vector
>> for attackers to map out a company’s internal networks.
> 
> You are sending your IP address(es) as payload so that your peer may
> connect to them. We've been doing this in various protocols for ages.
> Just take FTP for example, where data and signalling are separate. How
> is any of this different?

I’d hardly take FTP as a model citizen :-)

But what is different is that we have removed _all_ the sysadmin’s levers
to prevent mapping of internal address spaces.

If I understand correctly we bind to each and every interface
that is up and send out packets to all remote candidates down _every_ interface,
ignoring any preferences set by the admin in the local routing table which
were set to ensure (say) only critical traffic is sent down certain interfaces.

I can think of some financial institutions who’s IDSs will go off when packets
to public external addresses start turning up on internal LANS . (hopefully they 
will get dropped at the egress router, but by then the IDS will have paged someone).

Likewise my fantastically expensive BGAN link which is used for
emergencies only will suddenly start carrying STUN requests irrespective of how I configure my
routes ?

> 
>> It also may restrict the user’s ability to manipulate which medium is used. 
>> E.g. I’m at home and my chromebook pixel (or firefox tablet) is on wifi,
>> but I’ve left LTE enabled.
>> I (or the OS) is configured to prefer wifi wen available - but it
>> happens that for a specific peer LTE completes first.
>> So now my video call goes over LTE without my say-so and with no hint
>> this is happening  - costing me real
>> money. My only option is to completely disable LTE when I get home  (and
>> lose SMS too) ?
> 
> That is a valid concern, and the answer to it is MIF.

And in the meanwhile ?

Tim.

> 
> Simon