Subject: Re: [tram] TURN server discovery (please discuss!)

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 25 Mar 2014 03:37:23 +0000

> -----Original Message-----
> From: Brandon Williams [mailto:[email-masked]]
> Sent: Monday, March 24, 2014 10:11 PM
> To: Tirumaleswar Reddy (tireddy); Simon Perreault; Prashanth Patil (praspati);
> [email-masked]
> Subject: Re: [tram] TURN server discovery (please discuss!)
> 
> Hi Tiru,
> 
> I'm not sure that it would be reasonable to expect the degree of privacy that you
> are describing from an auto-discovered TURN server. Even with certs to
> authenticate the TURN server, you are still trusting the random coffee shop's
> network provider.
> 
> I think that Simon's axiom is entirely correct in this context ... don't trust the
> network provided server, and thus don't rely on it for privacy. 

If the same TURN server is auto-discovered in Enterprise network then mutual authentication will happen b/w the client and TURN server. In this case the client can rely on the TURN server provided by the Enterprise for privacy but not in the coffee shop scenario. Security Considerations section in the draft should explain that if the user selects privacy then trusted TURN server should be selected among the list of servers available.

-Tiru

> As long as the
> TURN client allows the user to select an appropriate security policy, I think it's
> OK.
> 
> --Brandon
> 
> On 03/24/2014 10:53 AM, Tirumaleswar Reddy (tireddy) wrote:
> > Hi Simon,
> >
> > Please see inline
> >
> >> -----Original Message-----
> >> From: Simon Perreault [mailto:[email-masked]]
> >> Sent: Monday, March 24, 2014 6:26 PM
> >> To: Tirumaleswar Reddy (tireddy); Brandon Williams; Prashanth Patil
> >> (praspati); [email-masked]
> >> Subject: Re: [tram] TURN server discovery (please discuss!)
> >>
> >> Le 2014-03-24 08:27, Tirumaleswar Reddy (tireddy) a écrit :
> >>> Yes, that will probably solve the problem. But how would the Mobile
> >>> Node
> >> (MN) trust the TURN server provided by the network when let's say MN
> >> is using Coffee shop WIFI ?
> >>> It could be a malicious TURN server provided to monitor the user
> >>> activity. If
> >> certificate validation is not possible then it becomes opportunistic
> encryption.
> >> Further with this restriction, the network provided TURN server may
> >> not be able to offer Mobility unlike the application provided TURN server.
> >>
> >> Do you trust the default gateway that is provided to you by DHCP when
> >> you log on a coffee shop wi-fi? No, you don't. But you still use it.
> >> And maybe you don't even consider this problematic. IMHO, if we dig
> >> deep enough we'll find that this problem is basically unfixable.
> >> There will always be an untrustworthy infrastructure layer on top of which
> trustworthy applications are built.
> >>
> >> I think what we need to do is:
> >>
> >> 0. Consider any network-provided TURN server as untrustworthy. This
> >> is an axiomatic position.
> >>
> >> 1. Devise a mechanism allowing this piece of untrustworthy
> >> infrastructure to be discovered.
> >>
> >> 2. Show how trustworthy applications can be built on top of this.
> >> (i.e., by encrypting media streams using SRTP, DTLS, etc.)
> >>
> >> The untrustworthy TURN server will be able to know the 5-tuples
> >> between the client and the peer.
> >
> > TURN is useful to provide privacy just like TOR. Using TOR ensures that even if
> the traffic is subjected to pervasive monitoring, attacker cannot find out the
> remote server with which the user is communicating. TURN can also be used to
> solve the same problem. If attacker can act as TURN server then this benefit of
> providing privacy will be lost.
> >
> > -Tiru
> >
> >> An untrustworthy IP router would equally be able to do it.
> >> But with appropriate encryption, it won't be able to discover
> >> anything more. So this would not introduce any new attack vector IMHO.
> >>
> >> Simon
> >> --
> >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> >> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> >> STUN/TURN server               --> http://numb.viagenie.ca
> >
> > _______________________________________________
> > tram mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tram
> >
> 
> --
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.