Subject: [rtcweb] when should ICE start?

From: "Jim Barnett" <[email-masked]>
Date: Thu, 8 Mar 2012 06:37:26 -0800

Trying to tie up some loose ends from earlier discussions:

1.       In the discussion of SDES, we stated that we don't trust the
web server.

2.       In a separate discussion, people  indicated that there were
serious privacy issues (disclosure of location) if ICE started before
the answerer gave consent.

3.       In the JSEP draft,  ICE is started under control of the
JavaScript

4.       which is served by the web server we don't trust.

I may be confused, but it seems to me that 3-4 are in conflict with 1-2.
For example, in the example in Section 8 of the JSEP draft, the offer is
not sent until the user consents, but it looks to me like ICE can start
on the answerer side  before the user gives consent.   In previous
discussions, someone also observed that it also might be possible to set
up a data channel without user consent, since it doesn't require media.

I'm not advocating a particular solution, but would like to hear how the
group intends to restore consistency.  It seems to me that there are 3
choices:

A.      decide we trust the web server after all

B.      decide that the security issues are not so serious after all

C.      set the default so that ICE does not start until the user
consents (this would amount to turning 'startICE' into
'startICEOnceUserConsents').  We might also treat the data channel as a
media channel requiring explicit consent, or say that data channels may
only be created once media channels are already in place.  

If we choose option C, we should probably run through some examples to
make sure that the potential delay in starting ICE doesn't cause
problems. 

-          Jim

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 08 Mar 2012 16:32:14 +0100

On 03/08/2012 03:37 PM, Jim Barnett wrote:
> 1.In the discussion of SDES, we stated that we don't trust the web server.
>
Well... it's more a question of what we trust the web server with.
>
> 2.In a separate discussion, people  indicated that there were serious 
> privacy issues (disclosure of location) if ICE started before the 
> answerer gave consent.
>
> 3.In the JSEP draft,  ICE is started under control of the JavaScript
>
> 4.which is served by the web server we don't trust.
>
The Javascript is served by a Web server. The Web server already knows 
where I am. So there's no point in trying to guard that information from 
one that already knows.
The one I'm guarding my location from is the person who's calling me, 
not the Web server that serves up my Javascript. In order to do that, I 
need the Web server (who knows where I am) to be on my side.
>
> I may be confused, but it seems to me that 3-4 are in conflict with 
> 1-2.  For example, in the example in Section 8 of the JSEP draft, the 
> offer is not sent until the user consents, but it looks to me like ICE 
> can start on the answerer side  before the user gives consent.   In 
> previous discussions, someone also observed that it also might be 
> possible to set up a data channel without user consent, since it 
> doesn't require media.
>
ICE using relay candidates does not disclose my location. So I can start 
*that* part of ICE.
>
> I'm not advocating a particular solution, but would like to hear how 
> the group intends to restore consistency.  It seems to me that there 
> are 3 choices:
>
> A.decide we trust the web server after all
>
> B.decide that the security issues are not so serious after all
>
> C.set the default so that ICE does not start until the user consents 
> (this would amount to turning 'startICE' into 
> 'startICEOnceUserConsents').  We might also treat the data channel as 
> a media channel requiring explicit consent, or say that data channels 
> may only be created once media channels are already in place.
>
See above. I don't think those are the only options.

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

---

From: "Jim Barnett" <[email-masked]>
Date: Thu, 8 Mar 2012 07:38:36 -0800

Harald,

You're right that the web server already knows where I am.  I'm worried
about it serving me malicious/careless JS that reveals my location to
caller (Syrian secret police, etc.) before I'm aware that I'm being
called.  That's the sense in which I don't trust it.  However you are
right that there are more options than I outlined, and starting ICE
using only relay candidates is one of them.

-          Jim

From: Harald Alvestrand [mailto:[email-masked]] 
Sent: Thursday, March 08, 2012 10:32 AM
To: Jim Barnett
Cc: [email-masked]
Subject: Re: [rtcweb] when should ICE start?

In the discussion of SDES, we stated that we don't trust the web server.

In a separate discussion, people  indicated that there were serious
privacy issues (disclosure of location) if ICE started before the
answerer gave consent.

In the JSEP draft,  ICE is started under control of the JavaScript

which is served by the web server we don't trust.

 

 

decide we trust the web server after all

decide that the security issues are not so serious after all

set the default so that ICE does not start until the user consents (this
would amount to turning 'startICE' into 'startICEOnceUserConsents').  We
might also treat the data channel as a media channel requiring explicit
consent, or say that data channels may only be created once media
channels are already in place.  

 

Jim

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Mar 2012 07:53:30 -0800

On Thu, Mar 8, 2012 at 7:38 AM, Jim Barnett <[email-masked]> wrote:
> Harald,
>
> You’re right that the web server already knows where I am.  I’m worried
> about it serving me malicious/careless JS that reveals my location to caller
> (Syrian secret police, etc.) before I’m aware that I’m being called.  That’s
> the sense in which I don’t trust it.

Right but in the most common case, as soon as you connect to the
server, the server knows your IP, so there's nothing we can do about
this.

-Ekr

---

From: "Jim Barnett" <[email-masked]>
Date: Thu, 8 Mar 2012 08:01:17 -0800

Yes, certainly if the Syrian secret police controls the server, I'm in trouble no matter what.  But isn't there a separate case where a third-party server, not under police control, serves up careless JS that reveals my location to the caller before I'm aware I'm being called?  This was the case we were worried about in the earlier discussion - that the caller could discover the answerer's  location even if the answerer rejected the call.  (I think that the example in Section 8 will permit this.)  So the trust question is:  do we let the server decide whether to allow this, or do we put defaults in the browser to protect location information even if the server is carelessly coded?

- Jim 

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Thursday, March 08, 2012 10:54 AM
To: Jim Barnett
Cc: Harald Alvestrand; [email-masked]
Subject: Re: [rtcweb] when should ICE start?

On Thu, Mar 8, 2012 at 7:38 AM, Jim Barnett <[email-masked]> wrote:
> Harald,
>
> You're right that the web server already knows where I am.  I'm 
> worried about it serving me malicious/careless JS that reveals my 
> location to caller (Syrian secret police, etc.) before I'm aware that 
> I'm being called.  That's the sense in which I don't trust it.

Right but in the most common case, as soon as you connect to the server, the server knows your IP, so there's nothing we can do about this.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Mar 2012 08:29:42 -0800

> Yes, certainly if the Syrian secret police controls the server, I'm in trouble no matter what.  But isn't there a separate case where a third-party server, not under police control, serves up carel…

I'm not sure that ICE and WebRTC create much of a new risk here. If the server
is badly coded then there are a lot of ways to leak the user's location. To give
one, say I use targeted ad buys to get the server to show you JS that includes
(a) cookies and (b) calls back to my server to reveal location information.

-Ekr

---

From: "Jim Barnett" <[email-masked]>
Date: Thu, 8 Mar 2012 10:53:03 -0800

Eric,
  I guess this amounts to my original option B - decide that the problem isn't as serious as we thought.  That's not what it sounded like during the first discussion of the issue, but I'm fine with it others agree.

- Jim

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Thursday, March 08, 2012 11:30 AM
To: Jim Barnett
Cc: Harald Alvestrand; [email-masked]
Subject: Re: [rtcweb] when should ICE start?

> Yes, certainly if the Syrian secret police controls the server, I'm in trouble no matter what.  But isn't there a separate case where a third-party server, not under police control, serves up carel…

I'm not sure that ICE and WebRTC create much of a new risk here. If the server is badly coded then there are a lot of ways to leak the user's location. To give one, say I use targeted ad buys to get the server to show you JS that includes
(a) cookies and (b) calls back to my server to reveal location information.

-Ekr

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 08 Mar 2012 20:43:27 +0100

>    I guess this amounts to my original option B - decide that the problem isn't as serious as we thought.  That's not what it sounded like during the first discussion of the issue, but I'm fine wit…
It's strongly application dependent. Fedex' answering machine, or a call 
center switchboard, will take great pain to reply as quickly as 
possibly, and has no expectation of privacy; a subscriber to "anonymous 
flirting page" might have completely different expectations.

When something is application dependent, I don't see that it's possible 
to make rules that allow "only one way to do it".

> On Thu, Mar 8, 2012 at 8:01 AM, Jim Barnett<[email-masked]>  wrote:

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 08 Mar 2012 15:35:03 -0500

Just following up on your original question: Can we " put defaults in 
the browser to protect location information"?

Igor

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 8 Mar 2012 14:37:58 -0800

Protection of location (and privacy in general) depends on a number of individual decisions, not just use of relays. 

For example, use of an FQDN in the CNAME can leak location information. 

My recommendation would be to focus on the media plane rather than signaling, since
there are a lot of ways to leak location in SIP (or XMPP, for that matter).

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Mar 2012 18:23:11 -0800

On Thu, Mar 8, 2012 at 6:16 PM, Jim Barnett <[email-masked]> wrote:
> Yes, but if we can trust the anonymous flirting site to protect our
> privacy, why can't we trust it not to record our calls if we use SDES?
> Can we trust the web server to do what we expect, or should we be
> systematically untrusting?

Is this a trick question?

1. There's a pretty big difference between knowing where I am and
being able to listen to my calls.
2. The IP-location privacy threat is pre-existing and not fundamentally
a WebRTC problem.
3. Nevertheless, people are concerned about it, which is why things like
Tor exist.

-Ekr