Subject: [tram] Path Forward for STUN ORIGIN

From: Alan Johnston <[email-masked]>
Date: Tue, 25 Aug 2015 14:57:40 -0500

All,

Based on feedback during IETF-93 in Prague, the authors of
draft-ietf-stun-origin are looking for feedback on a possible path forward
to solve the privacy/meta data issues and clear the DISCUSSes (see
https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ballot/).
There are two areas of feedback: Use Cases and Proposed Solution.

Use Cases
========

First, we want to be sure that we are considering all the use cases for
STUN ORIGIN.  In the draft, three are described:

1.  Logging of usage of STUN/TURN server. An operator of a STUN or TURN
server would learn the Origin of the web, SIP, and XMPP users.

2.  REALM selection for multi-tenanted TURN server. This avoids having to
run multiple instances on different ports or IP addresses when more than
one REALM is in use.

3.  Service determination after authentication.  Bandwidth or QoS policy
can be applied, after authentication, based on the Origin.

Also, the following use cases have also been discussed but are not in the
draft

4.  Authorization at border TURN server after authentication.  An
enterprise border TURN server can apply policy and allow usage for certain
Origins (whitelist) or block usage of others (blacklist).

5. draft-jennings-behave-rtcweb-firewall-01 discusses how a firewall with
STUN server could use ORIGIN in authorization decisions.

Are there any other use cases we should consider?

Possible Solution
=============

The solution that was discussed in Prague that seems to be the best
tradeoff between privacy and functionality is to only include ORIGIN
information in a STUN or TURN request if the domain of the Origin matches
the domain of the STUN or TURN server in the STUN or TURN URI.  Since web
and STUN and TURN run on different ports, and often will resolve to
different IP addresses, a full host comparison is not possible.  This
proposal is not perfect: it does not provide perfect privacy for subdomains
(e.g. sub1.example.com and sub2.example.com will match with this rule, even
if they are separate entities.  Of course, subdomain users could always
register a new domain and point DNS records to their sub hoster.)

In comparing this solution against the use cases above:

1. Allows logging of your own users on your own TURN server (or one that
you setup DNS SRV records to point towards).  Other users of your STUN or
TURN server will not be identified by an Origin, but you will at least know
if others are using your server.

2. Works for REALM selection as long as you use your own TURN server (or
one that you setup DNS SRV records to point towards).

3. Again, works for service determination as long as you use your own TURN
server (or one that you setup DNS SRV records to point towards).  Having
service-specific TURN credentials is another solution that doesn't rely on
ORIGIN.

4. & 5. Does not seem provide a good solution for these use cases.

Does this analysis make sense?

Feedback most welcome so we can move forward with this draft.

- Alan -

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Aug 2015 13:41:02 -0700

I'm wondering here whether this might be advised by similar work in the area.

ORIGIN is analogous to the HTTP Referer [sic] header field.  There,
the damage was done long ago, and we aren't sure that it can be fixed.
After several attempts to reduce the information that we expose by
default, I think that browser vendors are basically resigned to status
quo (at least for now).  That's the cautionary aspect of this
discussion that we have to be aware of.

However, what advises this is the secondary controls browsers are
providing for controlling use of Referer.  See referrer policy [1].
All this is driven by a simple principle: if we see an explicit signal
that a site wants to share Referer, then we include it for them.  This
is based on the realization that if we don't do this, they will find
another way to exfiltrate the data.  Usernames and passwords being the
obvious channels available for TURN, but I'll observe that there are
no winners if you force people to resort to hacks to get the
information they need or think they need.

Maybe all we need to do here is recognize that we need to provide
adequate controls.  Make it clear that you expect someone else (hello
browser vendors) to apply the policies.  If a TURN server is
configured with a special flag (call it "includeOrigin" for argument's
sake), then we might send the ORIGIN attribute.  Then, I think that
the concerns raised around privacy can be addressed by having ORIGIN
omitted by default.  Privacy-preserving by default is perhaps the most
relevant concern here.

I realize that this might be less than ideal for you because it means
talking to a whole new set of people over @w3.org, but I think that
option is likely to be less cumbersome than your proposed solution.

[1] http://w3c.github.io/webappsec/specs/referrer-policy/

On 25 August 2015 at 12:57, Alan Johnston <[email-masked]> wrote:
> First, we want to be sure that we are considering all the use cases for STUN
> ORIGIN.  In the draft, three are described:
>
> run multiple instances on different ports or IP addresses when more than one
> REALM is in use.
>
> 3.  Service determination after authentication.  Bandwidth or QoS policy can
> be applied, after authentication, based on the Origin.
>
> 4.  Authorization at border TURN server after authentication.  An enterprise
> border TURN server can apply policy and allow usage for certain Origins
> (whitelist) or block usage of others (blacklist).
>
> The solution that was discussed in Prague that seems to be the best tradeoff
> between privacy and functionality is to only include ORIGIN information in a
> STUN or TURN request if the domain of the Origin matches the domain of the
> STUN or TURN server in the STUN or TURN URI.  Since web and STUN and TURN
> run on different ports, and often will resolve to different IP addresses, a
> full host comparison is not possible.  This proposal is not perfect: it does
> not provide perfect privacy for subdomains (e.g. sub1.example.com and
> sub2.example.com will match with this rule, even if they are separate
> entities.  Of course, subdomain users could always register a new domain and
> point DNS records to their sub hoster.)
>
> 1. Allows logging of your own users on your own TURN server (or one that you
> setup DNS SRV records to point towards).  Other users of your STUN or TURN
> server will not be identified by an Origin, but you will at least know if
> others are using your server.
>
> 2. Works for REALM selection as long as you use your own TURN server (or one
> that you setup DNS SRV records to point towards).
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: Alan Johnston <[email-masked]>
Date: Wed, 26 Aug 2015 15:59:06 -0500

Hi Martin,

This is a very interesting idea - thanks for raising it.

Looking at the referrer-policy document, the proposal here is essentially a
default global policy of "origin-only" except not quite as strict.

The idea of the STUN or TURN URI suggesting the policy which would be
enforced by the browser is an interesting one.  Since the application STUN
or TURN server is provided by the JavaScript, it effectively means the
WebRTC web page would set the policy for inclusion of ORIGIN.  I'm trying
to think if this makes sense or not in this context.  I guess the privacy
leakage goes both ways - the STUN or TURN server operator learns about the
WebRTC site that the user is using, and it also learns which WebRTC sites
are being used.  We have mainly been thinking about privacy for the first
case, not the second case.  Having the WebRTC application decide if ORIGIN
should be shared with the STUN or TURN server does provide privacy for the
second case  Having user agent (i.e. browser user interface) controls for
ORIGIN would provide privacy for the first case.  Of course, there is still
the issue of what to do if the STUN TURN server requires ORIGIN but the
user doesn't provide it.

The referrer-policy document doesn't make any judgements on the various
policy levels it defines. Is the "origin-only" policy considered privacy
friendly in HTTP, or is it considered harmful?

Do any browsers provide referrer-policy user interface controls?  If so, I
wonder what the default setting would be?

But if the HTTP experience is that the Referrer header field was just that
it was a bad idea to begin with, then perhaps we should pay attention to
that...

- Alan -

On Tue, Aug 25, 2015 at 3:41 PM, Martin Thomson <[email-masked]>
wrote:

> STUN
> one
> can
> enterprise
> tradeoff
> you
> one

---

From: Alan Johnston <[email-masked]>
Date: Wed, 26 Aug 2015 16:07:06 -0500

Justin,

It is an important question for the WG on whether ORIGIN is a useful
solution to the use cases.  Hopefully we'll get more feedback on this.

Your comments seem mainly directed towards a solution for use case #2 below
(REALM selection for TURN authentication), right?  I'm not sure if use case
#3 applies or not.  I don't think OAuth helps with #1 or #4 or #5.

I know we have discussed it before, but I also don't think that everyone
believes that OAuth means that ORIGIN is no longer needed. There have been
suggestions that a multi-tenanted TURN server using OAuth might still use
ORIGIN.

And using domain-specific USERNAME attributes sounds a bit like the problem
that Martin mentioned of simply working around the approach.

- Alan -

On Tue, Aug 25, 2015 at 3:50 PM, Justin Uberti <[email-masked]> wrote:

> Overall, I think most/all of the goals that ORIGIN is trying to accomplish
> would be better handled by STUN OAuth (
> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/)
>
> Generally, it's not clear that ORIGIN is a great solution for any of the
> use cases listed.
> 1) is easily accomplished via oauth, without any of the restrictions
> present here
> 2) can be dealt with using other means (e.g. oauth, or supplying domain
> info in USERNAME)
> 3) is fairly weak control, and can be done better through oauth, or
> domained USERNAMEs
>
> Of course, as noted by others, use of domained USERNAMEs creates a
> quasi-ORIGIN value within the USERNAME attribute, which makes OAuth more
> attractive.
>
> On Tue, Aug 25, 2015 at 12:57 PM Alan Johnston <[email-masked]>
> wrote:
>
>> All,
>>
>> (e.g. sub1.example.com and sub2.example.com will match with this rule,
>> even if they are separate entities.  Of course, subdomain users could
>> always register a new domain and point DNS records to their sub hoster.)
>>
>> 3. Again, works for service determination as long as you use your own
>> TURN server (or one that you setup DNS SRV records to point towards).
>> Having service-specific TURN credentials is another solution that doesn't
>> rely on ORIGIN.
>>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 26 Aug 2015 15:50:41 -0700

> default global policy of "origin-only" except not quite as strict.

I was actually going to suggest that no-referrer be the default.  It's
the policy a lot of us wish we had for Referer.  Some of us configure
our browsers to do just that.

> enforced by the browser is an interesting one.

I wasn't suggesting that it be baked into the URI, but it is an
option.  Though in the same way that we no longer like to put
usernames and passwords in URIs, I don't think that including this
origin-policy attribute in there.

I was actually thinking that you would have an option on
RTCPeerConnection that set the policy.

> friendly in HTTP, or is it considered harmful?

That very much depends on where you stand.  "origin-only" is not
sufficient for some use cases, but is also too much information for
others.

> wonder what the default setting would be?

Firefox provides control through about:config only, and in the most
obtuse fashion imaginable (you have to know what a value of 3 means).
The default policies vary depending on the different origins involved,
and whether they are secure (i.e.,https://) or not.  The defaults we
*want* are somewhat different to the ones that we *have* though.

> it was a bad idea to begin with, then perhaps we should pay attention to

As I said, it is mixed.  Hence the suggestion to allow a measure of control.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 27 Aug 2015 01:15:03 +0000

Hi Alan,

OAuth solves all the below use cases, #4 and #5 is discussed in https://www.iab.org/wp-content/IAB-uploads/2015/01/semi2015_reddy.pdf.

-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Alan Johnston
Sent: Thursday, August 27, 2015 2:37 AM
To: Justin Uberti
Cc: [email-masked]; [email-masked]
Subject: Re: [tram] Path Forward for STUN ORIGIN

Justin,

It is an important question for the WG on whether ORIGIN is a useful solution to the use cases.  Hopefully we'll get more feedback on this.

Your comments seem mainly directed towards a solution for use case #2 below (REALM selection for TURN authentication), right?  I'm not sure if use case #3 applies or not.  I don't think OAuth helps with #1 or #4 or #5.

I know we have discussed it before, but I also don't think that everyone believes that OAuth means that ORIGIN is no longer needed. There have been suggestions that a multi-tenanted TURN server using OAuth might still use ORIGIN.

And using domain-specific USERNAME attributes sounds a bit like the problem that Martin mentioned of simply working around the approach.

- Alan -

On Tue, Aug 25, 2015 at 3:50 PM, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:
Overall, I think most/all of the goals that ORIGIN is trying to accomplish would be better handled by STUN OAuth (https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/)

Generally, it's not clear that ORIGIN is a great solution for any of the use cases listed.
1) is easily accomplished via oauth, without any of the restrictions present here
2) can be dealt with using other means (e.g. oauth, or supplying domain info in USERNAME)
3) is fairly weak control, and can be done better through oauth, or domained USERNAMEs

Of course, as noted by others, use of domained USERNAMEs creates a quasi-ORIGIN value within the USERNAME attribute, which makes OAuth more attractive.

On Tue, Aug 25, 2015 at 12:57 PM Alan Johnston <[email-masked]<mailto:[email-masked]>> wrote:
All,

Based on feedback during IETF-93 in Prague, the authors of draft-ietf-stun-origin are looking for feedback on a possible path forward to solve the privacy/meta data issues and clear the DISCUSSes (see https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ballot/).  There are two areas of feedback: Use Cases and Proposed Solution.

Use Cases
========

First, we want to be sure that we are considering all the use cases for STUN ORIGIN.  In the draft, three are described:

1.  Logging of usage of STUN/TURN server. An operator of a STUN or TURN server would learn the Origin of the web, SIP, and XMPP users.

2.  REALM selection for multi-tenanted TURN server. This avoids having to run multiple instances on different ports or IP addresses when more than one REALM is in use.

3.  Service determination after authentication.  Bandwidth or QoS policy can be applied, after authentication, based on the Origin.

Also, the following use cases have also been discussed but are not in the draft

4.  Authorization at border TURN server after authentication.  An enterprise border TURN server can apply policy and allow usage for certain Origins (whitelist) or block usage of others (blacklist).

5. draft-jennings-behave-rtcweb-firewall-01 discusses how a firewall with STUN server could use ORIGIN in authorization decisions.

Possible Solution
=============

The solution that was discussed in Prague that seems to be the best tradeoff between privacy and functionality is to only include ORIGIN information in a STUN or TURN request if the domain of the Origin matches the domain of the STUN or TURN server in the STUN or TURN URI.  Since web and STUN and TURN run on different ports, and often will resolve to different IP addresses, a full host comparison is not possible.  This proposal is not perfect: it does not provide perfect privacy for subdomains (e.g. sub1.example.com<http://sub1.example.com> and sub2.example.com<http://sub2.example.com> will match with this rule, even if they are separate entities.  Of course, subdomain users could always register a new domain and point DNS records to their sub hoster.)

1. Allows logging of your own users on your own TURN server (or one that you setup DNS SRV records to point towards).  Other users of your STUN or TURN server will not be identified by an Origin, but you will at least know if others are using your server.

2. Works for REALM selection as long as you use your own TURN server (or one that you setup DNS SRV records to point towards).

3. Again, works for service determination as long as you use your own TURN server (or one that you setup DNS SRV records to point towards).  Having service-specific TURN credentials is another solution that doesn't rely on ORIGIN.

- Alan -

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 27 Aug 2015 07:41:15 -0600

Martin, 

The solution you are proposing puts the control of if the information is shared in the hands of the website. I'm pretty sure man websites will choose "yep, share the origin". The privacy issue raised was more about if the protecting the interests of the user of the browser and not so concerned with what the website wanted. 

I think what was proposed in the meeting is a good compromise but I don't think having the JS indicate if the origin is shared or not really addresses the problem we were trying to solve. It might be a good idea to do this sort of control surface as well as what Alan is proposing. 

Cullen 

> On Aug 25, 2015, at 2:41 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 27 Aug 2015 07:43:55 -0600

more or the analysis of cases 4 and 5 

> On Aug 25, 2015, at 1:57 PM, Alan Johnston <[email-masked]> wrote:
> 
> 
...
> 4. & 5. Does not seem provide a good solution for these use cases.

I think the solution here does meet the most important pats of use case 4 and 5... let me explain. 

For case 5 ... For applications that care about working in network environments that require the ORIGIN, they will have to add a DNS entry to point at the turn server they want to use. Note they don't have to run their own TURN or STUN server, they just have to have a DNS entry that points at the one they use then use the DNS name that matches their website in the javascript. The -02 firewall draft is updated to assume a solution like this. 

For case 4 ... I'm not seeing the problem. The DNS name of the TURN server would have been provided along with credential s by whatever discover / configuration mechanisms gave it to the browser so it would match and would be provided.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 27 Aug 2015 07:49:31 -0600

I think this is close to the right solution but it is different than what I thought we talking about in the room. So I'm basically on board with this approach but think it needs a bit of tweaking ... More inline ...

> The solution that was discussed in Prague that seems to be the best tradeoff between privacy and functionality is to only include ORIGIN information in a STUN or TURN request if the domain of the Origin matches the domain of the STUN or TURN server in the STUN or TURN URI.  Since web and STUN and TURN run on different ports, and often will resolve to different IP addresses, a full host comparison is not possible.  This proposal is not perfect: it does not provide perfect privacy for subdomains (e.g. sub1.example.com and sub2.example.com will match with this rule, even if they are separate entities.  Of course, subdomain users could always register a new domain and point DNS records to their sub hoster.)
> 

I think we are having some confusions over what we mean by domain in this context. So lets say the TURN URL is

turn:acme.example.com

In the meeting when people said domain, I was thinking acme.example.com and I think you were thinking example.com.  

Probably the word we should use is "host" as defined in RFC 7065 to mean acme.example.com. Let me define "label" as the things between the . in the host. So the above example is a list of three labels, acme, example, com with the com being called the "top" end of the list and the acme being the "last" end of the list. 

I think there are three match policies people might  argue for

A) match only the top two labels

B) match all the the labels except the last 

C) match all the labels

So in the A case, if the browser was at a web site acme.example.com, the origin would be sent if the stun/turn server was stun.examle.com but not if it was stun.org. The problem with this is that if website is facebook.com.uk and the stun / turn server is anything in com.uk, then the origin is sent and that is not really what we wanted. 

So in the B case, if the website is example.com, then we match any stun server in .com which is probably not what we wanted. 

In the case of C, imagine a website called example.com that wants to run it's TURN and STUN and web on different servers. It would configure an DNS SRV record to point at it STUN server, another for the TURN server and perhaps a CNAME to point at the the web server. It might even be outsourcing the TURN server to some other provider that provides TURN for lots of domains on the same server. The only thing this domain needs to do to outsource it is provide the DNS entry. 

I could live with A,B, or C, but I think that C provides the best privacy, is the easiest to understand, and meets the requirements so I favor a match rule where we match the whole host found in the TURN or STUN URI to the host part of the HTTP ORIGIN. I don't care about matching if the origin is secure or not or ports.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Aug 2015 11:52:01 -0700

> The solution you are proposing puts the control of if the information is shared in the hands of the website. I'm pretty sure man websites will choose "yep, share the origin". The privacy issue rais…

I think that you are mischaracterizing it.  I'm asking sites that want
to share this information to go out of their way to do so.  Just not a
lot out of their way - which isn't that hard in practice.

I don't want this to be exposed by default, if that wasn't already clear.

Also, I didn't think of it before, but the proposal that Alan made
doesn't work if you are authenticating the TURN server.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Aug 2015 11:54:42 -0700

> I could live with A,B, or C, but I think that C provides the best privacy, is the easiest to understand, and meets the requirements so I favor a match rule where we match the whole host found in th…

If this is the path chosen, I agree that C is best.  (We don't match
certificates on port numbers, so I see no point in greater granularity
here either).

---

From: Alan Johnston <[email-masked]>
Date: Thu, 27 Aug 2015 14:06:07 -0500

Cullen,

You are completely right - we need to match on hostname, ignoring port and
scheme.  So C is the right approach for this proposal.

- Alan -

On Thu, Aug 27, 2015 at 1:54 PM, Martin Thomson <[email-masked]>
wrote:

> > I could live with A,B, or C, but I think that C provides the best
> privacy, is the easiest to understand, and meets the requirements so I
> favor a match rule where we match the whole host found in the TURN or STUN
> URI to the host part of the HTTP ORIGIN. I don't care about matching if the
> origin is secure or not or ports.
>
>