Re: [rtcweb] draft-jesup-rtcweb-data-00 posted

Eric Rescorla <ekr@rtfm.com> Fri, 28 October 2011 04:09 UTC

Return-Path: <ekr@rtfm.com>
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 80E4C1F0C55 for <rtcweb@ietfa.amsl.com>; Thu, 27 Oct 2011 21:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.959
X-Spam-Level:
X-Spam-Status: No, score=-102.959 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+WtZHsw3AIe for <rtcweb@ietfa.amsl.com>; Thu, 27 Oct 2011 21:09:42 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF221F0C42 for <rtcweb@ietf.org>; Thu, 27 Oct 2011 21:09:39 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so3646459vcb.31 for <rtcweb@ietf.org>; Thu, 27 Oct 2011 21:09:35 -0700 (PDT)
Received: by 10.220.2.19 with SMTP id 19mr173747vch.161.1319774974170; Thu, 27 Oct 2011 21:09:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.118.132 with HTTP; Thu, 27 Oct 2011 21:08:52 -0700 (PDT)
In-Reply-To: <3F4E6007-6858-49F5-93B0-E3B5ADBB1E97@acmepacket.com>
References: <4EA5EA46.1010803@jesup.org> <D3C41C1C-3586-4A22-8040-C7F0E22B41A7@acmepacket.com> <CABcZeBPuDZKCQgZ4RV-_zMrp2wa1EjM-w74VA=TuDzY3UY0HtQ@mail.gmail.com> <EB4481BA-E39E-4A9C-85E6-79B48F82298C@acmepacket.com> <4EA9ABC1.1000201@jesup.org> <3F4E6007-6858-49F5-93B0-E3B5ADBB1E97@acmepacket.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 27 Oct 2011 21:08:52 -0700
Message-ID: <CABcZeBOezm5UA+opJ_0ESf8avc4CtsV+7ea9VvmNzDWBL8wabg@mail.gmail.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Randell Jesup <randell-ietf@jesup.org>, "<rtcweb@ietf.org>" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Subject: Re: [rtcweb] draft-jesup-rtcweb-data-00 posted
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 28 Oct 2011 04:09:43 -0000

Thanks for pointing this out. I'll amend the document to mention this issue...

-Ekr


On Thu, Oct 27, 2011 at 9:05 PM, Hadriel Kaplan <HKaplan@acmepacket.com> wrote:
>
> Yeah I've kept meaning to email that draft-ietf-rtcweb-security-00 is great but misses a class of issues around privacy we've had to deal with in SIP.  For example if a session-request is received by the Browser and ICE procedures are allowed to start before the human user issues consent, then the far-end peer learns your local IP or your Firewall pinhole.  One of the things they can do with that, for example, is learn roughly where you are, given current IP-geo databases.
>
> For example if I use Facebook to call Domino's for pizza, Domino's learns the town I live in.  They would consider that a feature. :)
> But if the delivery guy in Domino's can someday later make a call back to me through Domino's Facebook account and using wireshark see if my ICE-learned IP isn't in my town or even State, without me even accepting the session request, that's not good.  Heck, I'm not even sure it's good to do if I do accept the session request.
>
> The problem is I'm not sure there's any way to explain these types of things and warn Web-app domain admins or JS developers to think about, let alone normal users, without causing WebRTC to get a bad reputation or scare people.
>
> -hadriel
>
> On Oct 27, 2011, at 3:06 PM, Randell Jesup wrote:
>
>> On 10/25/2011 11:31 AM, Hadriel Kaplan wrote:
>>> On Oct 25, 2011, at 10:20 AM, Eric Rescorla wrote:
>>>
>>>> On Tue, Oct 25, 2011 at 1:02 AM, Hadriel Kaplan<HKaplan@acmepacket.com>  wrote:
>>>>> Req. 8: The data stream transport protocol MUST NOT encode IP addresses inside its protocol fields; doing so reveals potentially private information, and leads to failure if the address is depended upon.
>>>> I don't really understand what this means. In general, the peer has
>>>> access to your IP address
>>>> information from ICE.
>>> From a privacy perspective: if a person uses a Web-site designed with privacy/anonymity in mind (e.g., battered-spouse forum), then the site would relay your media-plane stuff through a type of TURN server that does ICE itself both ways.  But if the SCTP layer on top of UDP encodes your local IP using one of the optional SCTP fields in RFC 4960 or 5061, then you lose that anonymity.  Since the SCTP layer is built into the Browser and not under control of the Javascript, a site can't prevent it from revealing that info.
>>
>>
>> There's a corollary: a user should be able to set their browser and/or App to force all incoming calls (and maybe outgoing) through a TURN server.  (There may be other uses for this ability, like corporate firewall traversal, but the case you mention is one of them).  Witness the recent attack on identity info on Skype using call-setup protocols, without even decoding them:
>>
>> http://www.theregister.co.uk/2011/10/21/skype_bittorrent_stalking/print.html
>> and
>> http://cis.poly.edu/~ross/papers/skypeIMC2011.pdf
>>
>> In theory it could be more nuanced - direct connections for people in your phonebook, or listed as friends, etc.  But that may be too confusing for generic users, and too likely to mess up.
>>
>> This is more likely a W3C issue, so CC-ing that list
>>
>> --
>> Randell Jesup
>> randell-ietf@jesup.org
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>