Subject: Re: [rtcweb] Relaying for privacy

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 19 Jun 2012 21:20:49 +0000

On May 16, 2012, at 18:09 , Eric Rescorla wrote:

> On Wed, May 16, 2012 at 2:54 PM, Justin Uberti <[email-masked]> wrote:
>> My view was that we need to make it _possible_ for sites to respect privacy
>> (via the API), and provide documentation that encourages sites to do so. As
>> you point out, I think it's difficult for the browser to automatically
>> figure out what to do here, and when to do it.
>> 
>> The identity of the "called" user may not be a factor in certain
>> applications (e.g. some p2p game), making it unclear as to whether forcing
>> use of relay is even the right thing to do.
> 
> I concur with all this.
> 
> I think it's also important to reiterate that this is about the site cooperating
> to protect your privacy. If you want to protect the user's IP address from the
> site, then the user needs to use Torbutton or some such. And I would want
> Torbutton to arrange relay my RTCWEB traffic as well (though likely that
> can't go through Tor for performance reasons).
> 
> -Ekr
> 

Agree this is about the JS cooperating and the JS can decide when to do this but one side comment

If my browser is behind a NAT today, I don't think the JS can find out the private address. I could be wrong about this but I don't know how to do it. Obviously the web server will see the IP of the outermost NAT. Once we can create an offer, this will change, the JS will be able to see the private address.

---

From: "Sunyang (Eric)" <[email-masked]>
Date: Wed, 20 Jun 2012 02:45:12 +0000

I think js can get private ip address and corresponding port number, which I test with google chrome and apprtc, also some private demo.

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Cullen Jennings (fluffy)
发送时间: 2012年6月20日 5:21
收件人: Eric Rescorla
抄送: [email-masked]
主题: Re: [rtcweb] Relaying for privacy

_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Martin Thomson <[email-masked]>
Date: Tue, 19 Jun 2012 22:23:43 -0700

> I think js can get private ip address and corresponding port number, which I test with google chrome and apprtc, also some private demo.

That might be true if you have installed certain plugins, but not for
an unmodified installation.  At least until this
(http://www.w3.org/TR/netinfo-api/) gets deployed.

Proxies and NAT tend to hide addresses unless you add something like
what we are proposing to add.  Getting the address of a NAT is
actually worse for most residential users. RFC 1918 addresses are
usually what you get from the host candidates, which doesn't do much
in terms of privacy leakage, whereas the public address on the NAT is
usually only shared by a handful of people.

--Martin

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 20 Jun 2012 13:58:24 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Martin Thomson
> Sent: Tuesday, June 19, 2012 10:24 PM
> To: Sunyang (Eric)
> Cc: Cullen Jennings (fluffy); [email-masked]
> Subject: Re: [rtcweb] 答复: Relaying for privacy
> 
> > I think js can get private ip address and corresponding port number,
> which I test with google chrome and apprtc, also some private demo.
> 

RTCWEB lacks a precise problem statement on what we mean by "privacy".

Your view seems valid for a typical home user where just about everyone
is using 192.168.1.0/24.  A typical enterprise IT administrator, 
however, does not want their internal network address assignments and
topology (host candidates) mapped from the outside.  Some IT 
administrators strip SMTP "Received:" lines to prevent that 
disclosure.

-d

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 Jun 2012 16:42:18 -0700

> administrators strip SMTP "Received:" lines to prevent that

Dan,

When you say "internal" are you thinking of host candidates for NATed or
non-NATed machines? Obviously, for non-NATed, any Web site will see
that.

-Ekr

the

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 20 Jun 2012 17:34:51 -0700

> From: Eric Rescorla [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2012 4:42 PM
> To: Dan Wing
> Cc: Martin Thomson; Sunyang (Eric); Cullen Jennings (fluffy);
> [email-masked]
> When you say "internal" are you thinking of host candidates for NATed
> or non-NATed machines? Obviously, for non-NATed, any Web site will see
> that.

I'm thinking of hosts behind a NAPT44 device, where the network
administrator feels the IP address sharing and IP address rewriting,
provided by that NAPT44, provides concealment of activities of
individual hosts.  The same feeling exists with IPv6 with IPv6
privacy addresses.  And perhaps that's what WEBRTC should do with
IPv6 is require a new privacy address for each "call".  (For
others' benefit, see last sentence of 
http://tools.ietf.org/html/rfc4941#section-3.1)

-d

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 Jun 2012 18:34:31 -0700

On Wed, Jun 20, 2012 at 5:34 PM, Dan Wing <[email-masked]> wrote:
> individual hosts.

Hmm... I'm not sure this really applies to the Web threat model,
since it's easy to use cookies and/or fingerprinting techniques
to correlate activity between multiple sessions regardless of
the IP.

-Ekr

 >The same feeling exists with IPv6 with IPv6

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 20 Jun 2012 19:51:06 -0700

> Sent: Wednesday, June 20, 2012 6:35 PM
> To: Dan Wing

Are you saying that ecause security can be compromised at layer 
N, we should not provide security at layer Y?

-d

> -Ekr
> 
> 
>  >The same feeling exists with IPv6 with IPv6

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Jun 2012 11:59:48 -0700

> administrators strip SMTP "Received:" lines to prevent that

I am not saying that _browsers_ shouldn't be able to provide a means
of hiding host (or even server reflexive) candidates from sites and
remote peers.  However, if the browser makes it possible to obtain a
host or server reflexive candidate, then the site will be able to
acquire that information.  At that point, we have to rely on the site
to respect the privacy of the user.

I assume that in the cases you cite, the idea is to prevent _anyone_
from getting the topology information.

In either case, I don't think that there is anything significant that
we can say in an IETF document other to indicate that these features
(browser-fixed-relaying, and site-relaying) are highly desirable.

--Martin

---

From: Randell Jesup <[email-masked]>
Date: Thu, 21 Jun 2012 23:10:28 -0400

> (browser-fixed-relaying, and site-relaying) are highly desirable.

This seems reasonable; browsers could implement configuration parameters 
that restrict this information from WebRTC applications or force use of 
a fixed relay server.  (Something not unheard of in the SIP world either.)

-- 
Randell Jesup
[email-masked]