Subject: [rtcweb] draft-schwartz-rtcweb-return

From: Cullen Jennings <[email-masked]>
Date: Thu, 26 Mar 2015 10:20:09 -0500

I'd like to point out that the combination of ietf-tram-turn-server-discovery and draft-schwartz-rtcweb-return allow any network you are connected to more or less MITM your media and do things like rate limit it, generate analytics on who you are talking to, force your traffic through an intermediary that is in a  different legal jurisdiction and so on. 

They are also not clear on how the browser gets the credentials to use the discovered TURN server. This seems like a major lacking before we can significantly discuss this. 

As we have seen from the google proxy deployments, enough revenue can be generated from this relaying info to pay for the relay. I'm not keen on that happening automatically with no user consent or awareness. 

But I don't get how this will work for enterprise deployments - It's just very unclear how the JS would end with the appropriate set of TURN servers to use.

---

From: Benjamin Schwartz <[email-masked]>
Date: Thu, 26 Mar 2015 11:51:17 -0400

On Thu, Mar 26, 2015 at 11:20 AM, Cullen Jennings <[email-masked]> wrote:

> I'd like to point out that the combination of
> ietf-tram-turn-server-discovery and draft-schwartz-rtcweb-return allow any
> network you are connected to more or less MITM your media and do things
> like rate limit it, generate analytics on who you are talking to, force
> your traffic through an intermediary that is in a  different legal
> jurisdiction and so on.
>

This is true on any network, right?  If you can do NAT, you can do all of
those things.

> They are also not clear on how the browser gets the credentials to use the
> discovered TURN server. This seems like a major lacking before we can
> significantly discuss this.
>

I agree that turn-server-discovery should address this.

> As we have seen from the google proxy deployments, enough revenue can be
> generated from this relaying info to pay for the relay. I'm not keen on
> that happening automatically with no user consent or awareness.
>

It's already happening automatically, since 1999, thanks to WPAD, which
allows the network to automatically configure proxies for all web traffic
with no user intervention on all major browsers.

But I don't get how this will work for enterprise deployments - It's just
> very unclear how the JS would end with the appropriate set of TURN servers
> to use.
>

It would be helpful if you could point to text that you think is unclear.

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

---

From: Alan Johnston <[email-masked]>
Date: Thu, 26 Mar 2015 11:24:08 -0500

Cullen,

I think the answer is obvious about credentials.  If an enterprise is
forcing users to use an enterprise TURN server, then it is up to the
enterprise to manage the credentials.  There is nothing new here.

As for your MitM comments, that isn't true unless you are saying that
DTLS-SRTP does not have any protection against MitM attacks.

- Alan -

---

From: Justin Uberti <[email-masked]>
Date: Thu, 26 Mar 2015 11:26:59 -0500

On Thu, Mar 26, 2015 at 10:51 AM, Benjamin Schwartz <[email-masked]>
wrote:

>> They are also not clear on how the browser gets the credentials to use
>> the discovered TURN server. This seems like a major lacking before we can

This is an extant problem for HTTP proxies, not unique to this solution
(and hasn't been a blocking issue there)

> with no user intervention on all major browsers.

I don't buy the revenue argument in this context. There is no cleartext
data to analyze.

> It would be helpful if you could point to text that you think is unclear.

JS doesn't get these TURN servers, the browser does and applies them the
same way it does HTTPS/SOCKS proxies.

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Thu, 26 Mar 2015 18:52:03 +0000

On 3/26/15, 8:20 AM, "Cullen Jennings (fluffy)" <[email-masked]> wrote:

>ietf-tram-turn-server-discovery and draft-schwartz-rtcweb-return allow
>any network you are connected to more or less MITM your media and do
>things like rate limit it, generate analytics on who you are talking to,
>force your traffic through an intermediary that is in a  different legal
>jurisdiction and so on.
>

The client should use the REALM attribute (returned in the 401 error
response) to determine the credentials to use for authentication.

-Prashanth

>very unclear how the JS would end with the appropriate set of TURN
>servers to use. 
>
>
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 26 Mar 2015 20:10:49 +0000

On: 26 March 2015 10:20 Cullen Jennings Wrote:
> 
> I'd like to point out that the combination of ietf-tram-turn-server-
> discovery and draft-schwartz-rtcweb-return allow any network you are
> connected to more or less MITM your media and do things like rate limit
> it, generate analytics on who you are talking to, force your traffic
> through an intermediary that is in a  different legal jurisdiction and
> so on.
> 

I don't see any new issues that are caused by this draft it is just suggesting that the same is done for WebRTC Media as is already done for HTTP(S) but using a TURN proxy which is optimized to handle media. 

We set the requirement in RFC 7478 (Requirement F20) requires that WebRTC handles this scenario and this solution is the only one we have on the table for this and provides a solution to the privacy concerns (IP Address leaks) with regard to deploying a network specific proxy.