Subject: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Feb 2015 15:25:21 +0000

This draft describes a means for an client to discover that the TURN server can provide IP address privacy.
Comments and suggestions are welcome.

-Tiru

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, February 04, 2015 8:54 PM
To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Tirumaleswar Reddy (tireddy); Prashanth Patil (praspati)
Subject: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt

A new version of I-D, draft-reddy-tram-turn-ipaddress-privacy-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository.

Name:		draft-reddy-tram-turn-ipaddress-privacy
Revision:	00
Title:		IP address privacy by TURN server
Document date:	2015-02-04
Group:		Individual Submission
Pages:		6
URL:            http://www.ietf.org/internet-drafts/draft-reddy-tram-turn-ipaddress-privacy-00.txt
Status:         https://datatracker.ietf.org/doc/draft-reddy-tram-turn-ipaddress-privacy/
Htmlized:       http://tools.ietf.org/html/draft-reddy-tram-turn-ipaddress-privacy-00

Abstract:
   A TURN server allocates an IP address for a user.  If this address is
   dis-associated from the user's actual network, the allocated IP
   address increases the user's privacy.  This document describes a
   means for an client to discover that the TURN server can provide IP
   address privacy.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Simon Perreault <[email-masked]>
Date: Wed, 4 Feb 2015 08:42:20 -0700

Thanks for writing this.

After a quick read, I am skeptical. I doubt any client would trust any
assertion from an a priori unknown TURN server about its available privacy
capabilities.

Instead, why can't the client simply request an allocation, perhaps
indicating its desire that the relayed address be "far" from its own with a
new optional attribute, and then accept or reject the allocation using its
own good judgment?

Simon
Le 2015-02-04 08:25, "Tirumaleswar Reddy (tireddy)" <[email-masked]> a
écrit :

> To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Tirumaleswar
> Reddy (tireddy); Prashanth Patil (praspati)
> Subject: New Version Notification for
> draft-reddy-tram-turn-ipaddress-privacy-00.txt
>
>
> URL:
> http://www.ietf.org/internet-drafts/draft-reddy-tram-turn-ipaddress-privacy-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-reddy-tram-turn-ipaddress-privacy/
> Htmlized:
> http://tools.ietf.org/html/draft-reddy-tram-turn-ipaddress-privacy-00
>
>
> Abstract:
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: Benjamin Schwartz <[email-masked]>
Date: Wed, 4 Feb 2015 10:45:44 -0500

I agree with Simon.

1. IP address privacy is not representable as a binary.  See
http://en.wikipedia.org/wiki/Degree_of_anonymity

2. This system actually _reduces_ privacy:
> If the server determines that the relayed address it will allocate and
client IP address are in the same geolocation then the server will redirect
the client to another server

This behavior provides me nonzero information about your location: you
cannot be at the location indicated by the allocated IP address.

(Even Simon's proposal here actually _increases_ address information
leakage. The minimal-leakage strategy is to use a fixed/random address that
might occasionally be close to your real address, by chance.)

3. "Same geolocation" is not a well-defined concept.  There are a multitude
of corporations with different, contradictory geolocation databases of
varying quality.

4. I presume that the goal here is to allow building privacy-preserving
communications systems, but this draft does not make that possible, because
anyone setting up a privacy-preserving chat system cannot trust an
arbitrary enterprise-configured TURN server to be privacy-preserving, just
because that server claims to preserve privacy.

On Wed, Feb 4, 2015 at 10:42 AM, Simon Perreault <[email-masked]>
wrote:

>> To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy);
>> Tirumaleswar Reddy (tireddy); Prashanth Patil (praspati)

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Feb 2015 15:58:09 +0000

Inline [TR]

From: Simon Perreault [mailto:[email-masked]]
Sent: Wednesday, February 04, 2015 9:12 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt

Thanks for writing this.

After a quick read, I am skeptical. I doubt any client would trust any assertion from an a priori unknown TURN server about its available privacy capabilities.

[TR] TURN server could be known and trusted by the client. If the TURN server is malicious then there are other privacy problems like it will know the location of both the endpoints, duration of the call etc.

Instead, why can't the client simply request an allocation, perhaps indicating its desire that the relayed address be "far" from its own with a new optional attribute, and then accept or reject the allocation using its own good judgment ?

[TR] How to measure “far” (same continent different country, different continent) ?

-Tiru

Simon
Le 2015-02-04 08:25, "Tirumaleswar Reddy (tireddy)" <[email-masked]<mailto:[email-masked]>> a écrit :
This draft describes a means for an client to discover that the TURN server can provide IP address privacy.
Comments and suggestions are welcome.

-Tiru

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, February 04, 2015 8:54 PM
To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Tirumaleswar Reddy (tireddy); Prashanth Patil (praspati)
Subject: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

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

---

From: Simon Perreault <[email-masked]>
Date: Wed, 4 Feb 2015 09:09:03 -0700

On Wed, Feb 4, 2015 at 8:58 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> [TR] TURN server could be known and trusted by the client. If the TURN
> server is malicious then there are other privacy problems like it will know
> the location of both the endpoints, duration of the call etc.
>
Sure, but then

1. That needs to be stated clearly in the doc, and
2. That considerably reduces the applicability.

> own good judgment ?

Exactly! How does the server itself know if it can provide privacy, if even
the client can't tell?

Simon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Feb 2015 16:11:47 +0000

Inline [TR]

From: Benjamin Schwartz [mailto:[email-masked]]
Sent: Wednesday, February 04, 2015 9:16 PM
To: Simon Perreault
Cc: Tirumaleswar Reddy (tireddy); [email-masked]
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt

I agree with Simon.

1. IP address privacy is not representable as a binary.  See http://en.wikipedia.org/wiki/Degree_of_anonymity

[TR] It is only offering IP address privacy from remote peer.
2. This system actually _reduces_ privacy:
> If the server determines that the relayed address it will allocate and client IP address are in the same geolocation then the server will redirect the client to another server

This behavior provides me nonzero information about your location: you cannot be at the location indicated by the allocated IP address.

[TR] The relayed address is not allocated by the TURN server, it redirects the client to a different TURN server that can offer IP address privacy.

(Even Simon's proposal here actually _increases_ address information leakage. The minimal-leakage strategy is to use a fixed/random address that might occasionally be close to your real address, by chance.)

3. "Same geolocation" is not a well-defined concept.  There are a multitude of corporations with different, contradictory geolocation databases of varying quality.

[TR] Geolocation is well-defined concept already used by firewalls from various vendors to make effective blocking decisions.

4. I presume that the goal here is to allow building privacy-preserving communications systems, but this draft does not make that possible, because anyone setting up a privacy-preserving chat system cannot trust an arbitrary enterprise-configured TURN server to be privacy-preserving, just because that server claims to preserve privacy.

[TR] Enterprise configured TURN server is not an arbitrary server. Typically users trust Enterprise firewall and it act as HTTP(S) proxy, in the same lines Enterprise TURN server can also be trusted when it claims it can provide privacy.

-Tiru

On Wed, Feb 4, 2015 at 10:42 AM, Simon Perreault <[email-masked]<mailto:[email-masked]>> wrote:

Thanks for writing this.

Instead, why can't the client simply request an allocation, perhaps indicating its desire that the relayed address be "far" from its own with a new optional attribute, and then accept or reject the allocation using its own good judgment?

Simon

-Tiru

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, February 04, 2015 8:54 PM
To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Tirumaleswar Reddy (tireddy); Prashanth Patil (praspati)
Subject: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt

Abstract:

The IETF Secretariat

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Feb 2015 16:32:12 +0000

Inline [TR2]

From: Simon Perreault [mailto:[email-masked]]
Sent: Wednesday, February 04, 2015 9:39 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt

On Wed, Feb 4, 2015 at 8:58 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:

[TR2] It is discussed in the draft.
<snip>
The client must only select a TURN server whose authenticity can be ascertained and can offer IP address privacy.
</snip>

[TR2] Client looking for IP address privacy should give higher precedence to a trusted TURN server than some random TURN server whose authenticity cannot be ascertained. We should also consider scenarios where attackers may deploy TURN servers.

Exactly! How does the server itself know if it can provide privacy, if even the client can't tell ?

[TR] ADDRESS-PRIVACY attribute can probably be enhanced to indicate the level of privacy required.

-Tiru

Simon

---

From: Benjamin Schwartz <[email-masked]>
Date: Wed, 4 Feb 2015 11:45:49 -0500

On Wed, Feb 4, 2015 at 11:11 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

>  Inline [TR]
>
>
>
> *From:* Benjamin Schwartz [mailto:[email-masked]]
> *Sent:* Wednesday, February 04, 2015 9:16 PM
> *To:* Simon Perreault
> *Cc:* Tirumaleswar Reddy (tireddy); [email-masked]
> *Subject:* Re: [tram] FW: New Version Notification for

I disagree with your conception of the problem.

I think the real goal here is to achieve some degree of anonymity, assuming
that the TURN server is trusted not to reveal its mapping table (and the
adversary cannot deduce it).  To achieve this, you must choose a TURN
server that is not traceable to the aspect of your identity that you are
trying to obscure.  For example, if you are trying to conceal your IP
address, then this TURN server must not imply your IP address.  If you are
trying to conceal your corporate affiliation, this TURN server must not be
associated with your corporation.  If you are trying to conceal your
location on the planet, this TURN server must must be used by users on all
continents ... etc.

Given the wide variety of trust relationships and privacy goals held by
users, the only reasonable approach here is to let the user select a TURN
server that they trust explicitly.  Such a configuration might happen by
enterprise policy (in the same way that software can be installed on all
workstations at an office), but network-level autoconfiguration does not
indicate sufficient trust.

> [TR] The relayed address is not allocated by the TURN server, it redirects
> the client to a different TURN server that can offer IP address privacy.
>

Presumably the client is intended to ask the second server for address
privacy as well, in which case that server will also redirect if the IP
addresses match.  The result is an information leak, albeit a small one.
Perhaps more importantly, the procedure can easily fail, leaving the client
to explain to the user that all attempts to find a privacy-promising
intermediary have failed.

> 3. "Same geolocation" is not a well-defined concept.  There are a
> multitude of corporations with different, contradictory geolocation
> databases of varying quality.
>
>
>
> [TR] Geolocation is well-defined concept already used by firewalls from
> various vendors to make effective blocking decisions.
>

"Effective" perhaps, but not "reliable".  Systems that promise privacy to
users must be "reliable": they must never fail, because they are entrusted
with a task of grave significance.  I am not willing to bet the user's
privacy on the accuracy of some arbitrary TURN server's geolocation
database, which will likely be poorly implemented, incomplete, and out of
date.

> [TR] Enterprise configured TURN server is not an arbitrary server.
> Typically users trust Enterprise firewall and it act as HTTP(S) proxy, in
> the same lines Enterprise TURN server can also be trusted when it claims it
> can provide privacy.
>

I agree that there exist situations where a trust relationship exists
between the TURN server operator and the user, but not all TURN
autodiscovery implementations have this property.  For example, it is
likely that some ISPs will provide TURN servers via autodiscovery, but I
certainly would not trust my ISP to safeguard my privacy in any way.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Feb 2015 17:15:17 +0000

Inline [TR2]

From: Benjamin Schwartz [mailto:[email-masked]]
Sent: Wednesday, February 04, 2015 10:16 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; [email-masked]
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt

On Wed, Feb 4, 2015 at 11:11 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
Inline [TR]

From: Benjamin Schwartz [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, February 04, 2015 9:16 PM
To: Simon Perreault
Cc: Tirumaleswar Reddy (tireddy); [email-masked]<mailto:[email-masked]>
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt

I agree with Simon.

I think the real goal here is to achieve some degree of anonymity, assuming that the TURN server is trusted not to reveal its mapping table (and the adversary cannot deduce it).  To achieve this, you must choose a TURN server that is not traceable to the aspect of your identity that you are trying to obscure.  For example, if you are trying to conceal your IP address, then this TURN server must not imply your IP address.  If you are trying to conceal your corporate affiliation, this TURN server must not be associated with your corporation.  If you are trying to conceal your location on the planet, this TURN server must must be used by users on all continents ... etc.

Given the wide variety of trust relationships and privacy goals held by users, the only reasonable approach here is to let the user select a TURN server that they trust explicitly.  Such a configuration might happen by enterprise policy (in the same way that software can be installed on all workstations at an office), but network-level autoconfiguration does not indicate sufficient trust.

Presumably the client is intended to ask the second server for address privacy as well, in which case that server will also redirect if the IP addresses match.  The result is an information leak, albeit a small one.  Perhaps more importantly, the procedure can easily fail, leaving the client to explain to the user that all attempts to find a privacy-promising intermediary have failed.

[TR2] A relay service provider with a broadly distributed system like the one discussed in https://tools.ietf.org/html/draft-williams-peer-redirect-03 can pick the right TURN server avoiding NNN number of redirections.

"Effective" perhaps, but not "reliable".  Systems that promise privacy to users must be "reliable": they must never fail, because they are entrusted with a task of grave significance.  I am not willing to bet the user's privacy on the accuracy of some arbitrary TURN server's geolocation database, which will likely be poorly implemented, incomplete, and out of date.

[TR2] TURN service provider can offer privacy as feature to customers, in which case it has SLA to provide reliable privacy. It’s very similar to way Cloud based Security as a service (SaaS) is offered and the Enterprise enters into an agreement with SaaS for privacy, data leakage prevention etc.
TURN client can also do the validation by itself to check if the geolocation of the relayed address matches endpoints geolocation.

I agree that there exist situations where a trust relationship exists between the TURN server operator and the user, but not all TURN autodiscovery implementations have this property.  For example, it is likely that some ISPs will provide TURN servers via autodiscovery, but I certainly would not trust my ISP to safeguard my privacy in any way.

[TR] Client could discover TURN server provided by ISP and learn the TURN server offered by application server. But user may not trust the application server and would want to go with the TURN server provided by the ISP.

-Tiru

-Tiru

Thanks for writing this.

Simon

-Tiru

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, February 04, 2015 8:54 PM
To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Tirumaleswar Reddy (tireddy); Prashanth Patil (praspati)
Subject: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt

Abstract:

The IETF Secretariat

---

From: Benjamin Schwartz <[email-masked]>
Date: Wed, 4 Feb 2015 12:45:00 -0500

On Wed, Feb 4, 2015 at 12:15 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> *Sent:* Wednesday, February 04, 2015 10:16 PM
> *To:* Tirumaleswar Reddy (tireddy)
> *Cc:* Simon Perreault; [email-masked]
> I think the real goal here is to achieve some degree of anonymity,
> assuming that the TURN server is trusted not to reveal its mapping table
> (and the adversary cannot deduce it).  To achieve this, you must choose a
> TURN server that is not traceable to the aspect of your identity that you
> are trying to obscure.  For example, if you are trying to conceal your IP
> [TR2] A relay service provider with a broadly distributed system like the
> one discussed in
> https://tools.ietf.org/html/draft-williams-peer-redirect-03 can pick the
> right TURN server avoiding NNN number of redirections.
>
>
>
>
>
> [TR2] TURN service provider can offer privacy as feature to customers, in
> which case it has SLA to provide reliable privacy. It’s very similar to way
> Cloud based Security as a service (SaaS) is offered and the Enterprise
> enters into an agreement with SaaS for privacy, data leakage prevention etc.
>
>  TURN client can also do the validation by itself to check if the
> geolocation of the relayed address matches endpoints geolocation.
>

I agree that the client can do equally well itself, by sending a STUN
Binding Request and comparing the response to the TURN server's own IP
address.  That's why I don't think that the protocol extension is helpful.

> [TR] Client could discover TURN server provided by ISP and learn the TURN
> server offered by application server. But user may not trust the
> application server and would want to go with the TURN server provided by
> the ISP.
>

Or the client might want to use both, or even _have_ to use both, depending
on their privacy goals and network configuration.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Feb 2015 18:50:50 +0000

I agree that the client can do equally well itself, by sending a STUN Binding Request and comparing the response to the TURN server's own IP address.

[TR3] The difference this draft brings in is that it helps the TURN server (offered by a global or cloud service) to determine that the client wants privacy and level of privacy required conveyed in the new STUN attribute, the TURN server determines suitable alternate TURN server that can offer the required level of privacy.

-Tiru

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 5 Feb 2015 14:55:17 +0800

There is no mechanism to assure how soon the client can find the right TURN Server that can provide one relay address to keep the privacy of the clients.

From: tram [mailto:[email-masked]] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Thursday, February 05, 2015 2:51 AM
To: Benjamin Schwartz
Cc: Simon Perreault; [email-masked]
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt

-Tiru

---

From: Justin Uberti <[email-masked]>
Date: Thu, 5 Feb 2015 16:51:08 -0800

I agree with Simon and Ben in being skeptical about this proposal.

The client is the only party which knows exactly what 'privacy' means, and
there is no trivial way to serialize this into a single attribute for the
TURN server.

As such, I think this decision should be left entirely to the client.

On Wed, Feb 4, 2015 at 10:50 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> address.
> [TR3] The difference this draft brings in is that it helps the TURN server
> (offered by a global or cloud service) to determine that the client wants
> privacy and level of privacy required conveyed in the new STUN attribute,
> the TURN server determines suitable alternate TURN server that can offer
> the required level of privacy.
>
>
>
> -Tiru
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 6 Feb 2015 10:49:08 +0000

On a first read I am also rather skeptical about handing this privacy function over to the TURN server.

The draft introduces the first argument I have seen against using https://tools.ietf.org/html/draft-schwartz-rtcweb-return-03 in that it states:

“If the third party offered TURN server can provide IP address privacy then the application can avoid TURN-in-TURN mechanism discussed in[I-D.schwartz-rtcweb-return<http://tools.ietf.org/html/draft-reddy-tram-turn-ipaddress-privacy-00#ref-I-D.schwartz-rtcweb-return>] and thus avoid the overhead of using RETURN proxying”.

However it does not seem to me that the overhead of using a RETURN proxy is really that significant given that the RETURN proxy is likely to be close to the client in the enterprise proxy/firewall or in the access network.

Andy

From: tram [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: 06 February 2015 00:51
To: Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; Benjamin Schwartz; [email-masked]
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt

The client is the only party which knows exactly what 'privacy' means, and there is no trivial way to serialize this into a single attribute for the TURN server.

On Wed, Feb 4, 2015 at 10:50 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
I agree that the client can do equally well itself, by sending a STUN Binding Request and comparing the response to the TURN server's own IP address.

-Tiru