I see two possible readings (either or both of them might be useful):

1. The browser must have a way for its user to force the use of TURN servers (and this is only useful if the user also provides the address and credentials for the TURN servers) for transmission of media.

2. The browser must have an API that keeps some kinds of candidates from being included in the SDP the API generates.

#1 seems like a very useful thing to require for users who might actually care about their privacy, but I don't think that requirement belongs in an IETF document but rather the W3C requirements TR for WEBRTC, that appears to have not even been started.

#2 seems highly questionable to me, due to the large number of failure modes in both the interpretation of the spec and the ability to circumvent the intent...

For #2 do you mean "API flag to prevent local candidates from being included" or "API flag to prevent server-reflexive STUN-learned candidates from being included" or both?

For #2 how do you propose a malicious application or page injection not simply change the flag?

For #2 why can't the same behavior be accomplished by including all the candidates in the SDP and then letting the JavaScript remove the "dangerous" candidates before sending the SDP to the server?

For #2 why can't the same behavior be accomplished by including all the candidates in the SDP, sending it to the server (which you must trust anyway, as it also can change the flag itself *or* derive your IP address by looking at where you load pages from), and having the server remove the "dangerous" candidates before sending them on to the far client?

Matthew Kaufman
 

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Eric Burger
Sent: Monday, February 4, 2013 2:53 AM
To: Eric Rescorla
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))

Under what circumstances would it be up to the Web server to decide to make the client interaction quasi-anonymous? Would that not be a entirely up to and the responsibility of the client? By definition, the Web server is not anonymous -- the user had to reach it somehow to get the page in the first place. Likewise, it is well within the power of the server to obfuscate its media address. It is quite likely media is NOT coming from the same IP address as the Web page under normal circumstances, so the server has built-in opportunities to obfuscate its address. Conversely, it is well within the capabilities of the browser to figure out how to obfuscate its media address. More importantly, I have yet to hear a cogent use case for the server saying, "I want this interaction to not have IP addresses *TO PROTECT YOU*." If you are in a scenario where you need protection, you cannot depend on the server. You must depend on yourself, which means you will have a browser that will protect you. Moreover, will not a bad server simply always tell all browsers it connects with to open lots of anonymity relays to DDoS the relays? Saying we want to build something that is only sometimes useful and can only be useful if we trust all sides to do the right thing does not sound very useful.

Am I missing something here?

On Feb 3, 2013, at 6:48 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> 
> 
> On Sun, Feb 3, 2013 at 10:56 AM, Eric Burger <eburger@standardstrack.com> wrote:
> To be clear, I think ekr's formulation is the best:
> > 1. If you don't want the server learning your global IP, you need to use Tor or the like.
> 
> To me, this means it is totally orthogonal to RTCweb. If you want to use Tor, a TURN server, an ALG, or foo, that is up to you. That does not impact the protocol.
> 
> That's certainly what I meant to be saying, with the small caveat that 
> if you are using media relays (e.g., TURN) they are supposed to be 
> reflected in ICE candidate lines.
> 
> 
> > 2. I would suggest that it is simplest to divide the world into host 
> > addresses, server/peer reflexive, and relayed and say that the 
> > requirement is that the browser must be able to send packets without 
> > revealing either of the former two, but that it is not a requirement that it be able to do so in the face of an adversarial server.
> And this is the most reasonable. I guess the concern is we will forget all of this list discussion, and someone will require hard-coded endpoint IP addresses in the protocol, which is what sunk SIP in the early days.
> 
> Inline...
> 
> On Feb 3, 2013, at 1:32 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> > On Sun, Feb 3, 2013 at 7:32 AM, Burger Eric <eburger@cs.georgetown.edu> wrote:
> > Is what we are really asking for is the ability of the protocol to be TOR-, TURN-, and mumble-friendly? I am hesitant to suggest we bake in one particular anonymity network or another into the RTCweb protocol suite.
> >
> > I'm certainly not suggesting that.
> >
> >
> > On the one hand, with my purist hat on, saying it is a requirement to make sure we do not need to have end-to-end connectivity smells a bit weird.
> >
> >> I don't understand this... I don't think anyone is suggesting that.
> 
> Saying we will bake into the protocol the REQUIREMENT that it support good or bad boxes in the middle of the network does not sound like the end-to-end Internet. It sounds more like IMS.
> 
> Which requirement do you think suggests that? I certainly favor 
> requirements that we be able to work in the face of as many known 
> classes of intermediaries (NATs, firewalls, etc. as possible.) I mean, 
> isn't that the point of ICE supporting TURN and other types of relays?
> 
> Is there something wrong with this? Do you think people are suggesting 
> some other requirement?
> 
> 
> > On the other hand, with my practical hat on, saying it is a requirement to make sure the protocol works in situations that are NOT the Internet (NATs, a need for an overlay privacy network, etc.) seems like a good thing to do.
> >
> >> As far as I know, the only novel requirement here is that there be 
> >> a way for Web application to tell the browser to solely use relayed 
> >> addresses/candidates (and hopefully thus not reveal the user's 
> >> actual location) when communicating with the peer. There is of 
> >> course a requirement to be able to work when behind NATs but that is a functional requirement, not an anonymity one.
> 
> That is asking an awful lot of an application. Moreover, as the cat-and-mouse game of anonymous application communication is ever evolving, I would challenge how meaningful it is to specify a Hidden Bit or Anonymous Bit in the protocol. I would offer that will work as well as the Evil Bit.
> 
> I really am not following what you are saying here about a "hidden bit"?
> 
> There is a very specific requirement being suggested here, namely that 
> applications should be able to instruct browsers not to use host or 
> srvflx candidates. This is neither a hidden bit, nor an anonymous bit. 
> Rather, it is a mechanism designed to allow the site, *if it wishes* 
> to offer a calling service that doesn't immediately reveal the 
> caller's location. This isn't a complete anonymity service against 
> sophisticated attackers. For that you need something like Tor. Rather, 
> it's an easy-to-implement measure that offers location protection against a (relatively common) class of limited attackers.
> 
> What is it you object to about this requirement?
> 
> -Ekr
>