W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2011

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

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>
Cc: Randell Jesup <randell-ietf@jesup.org>, "<rtcweb@ietf.org>" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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
>
Received on Friday, 28 October 2011 04:10:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:25 UTC