Subject: [tram] Recasting STUN ORIGIN as a 'Host' header

From: Justin Uberti <[email-masked]>
Date: Thu, 10 Dec 2015 18:06:17 -0800

There was some discussion on this in Yokohama, but I haven't seen it make
its way onto the list yet.

I think making ORIGIN into something more like HTTP's Host header is a
pretty good idea, so here's a quick summary from my perspective.

Basically, I propose we get rid of ORIGIN and add a new HOST attribute
which carries the DNS name of the TURN server the application wants to
connect to (not the application origin). When the server is multi-tenant,
the provider can use CNAMEs to set up different DNS names for different
customers (e.g. app1.turnprovider.com, app2.turnprovider.com), all pointing
to the same multi-tenant TURN server - and use the HOST attribute to
identify the application and/or determine which REALM to return.

Browsers don't need to do anything special other than adding a single
attribute, which comes directly from the supplied TURN URI. No name
matching, no multiple origins, no SRV records.

This approach also deals effectively with the concerns around the browser
disclosing the user's ORIGIN to the TURN provider. Since the app is in
charge of what TURN URI it uses, it has control over what is disclosed to
the TURN provider - which is just the name in the TURN URI, not the app's
origin.

For example: consider an app at www.myapp.com, which uses a TURN server at
myapp.turnprovider.com (a CNAME for turnserver.turnprovider.com that was
provisioned for myapp.com by turnprovider.com). In this case, the HOST
attribute would contain "myapp.turnprovider.com", but not "www.myapp.com".

Overall, I think this approach solves the core problem ORIGIN was meant to
solve (e.g. REALM for multi-tenant servers), avoids the privacy gotchas
that have recently come up, and as a bonus, is simpler.

---

From: Alan Johnston <[email-masked]>
Date: Fri, 11 Dec 2015 15:44:53 +0200

Justin,

Thanks for posting this. 

I've been thinking about using HOST as well, but I think this approach generates new meta-data.  Essentially, new WebRTC usage information is generated at the STUN/TURN server where none was generated before. This is true for both cases: where the URI is the domain of the TURN provider and also where the domain is the WebRTC provider. 

Unless a comparison between the HOST and the ORIGIN is made, along the lines of what I proposed in Yokohama. In this case, all we have done is changed the name of the attribute from ORIGIN to HOST.  The same info will be sent over the wire. 

So, regardless if we call it ORIGIN or HOST, the same matching rules will be needed. 

- Alan -

> On Dec 11, 2015, at 4:06 AM, Justin Uberti <[email-masked]> wrote:
> 
> There was some discussion on this in Yokohama, but I haven't seen it make its way onto the list yet. 
> 
> I think making ORIGIN into something more like HTTP's Host header is a pretty good idea, so here's a quick summary from my perspective.
> 
> Basically, I propose we get rid of ORIGIN and add a new HOST attribute which carries the DNS name of the TURN server the application wants to connect to (not the application origin). When the server is multi-tenant, the provider can use CNAMEs to set up different DNS names for different customers (e.g. app1.turnprovider.com, app2.turnprovider.com), all pointing to the same multi-tenant TURN server - and use the HOST attribute to identify the application and/or determine which REALM to return.
> 
> Browsers don't need to do anything special other than adding a single attribute, which comes directly from the supplied TURN URI. No name matching, no multiple origins, no SRV records.
> 
> This approach also deals effectively with the concerns around the browser disclosing the user's ORIGIN to the TURN provider. Since the app is in charge of what TURN URI it uses, it has control over what is disclosed to the TURN provider - which is just the name in the TURN URI, not the app's origin.
> 
> For example: consider an app at www.myapp.com, which uses a TURN server at myapp.turnprovider.com (a CNAME for turnserver.turnprovider.com that was provisioned for myapp.com by turnprovider.com). In this case, the HOST attribute would contain "myapp.turnprovider.com", but not "www.myapp.com". 
> 
> Overall, I think this approach solves the core problem ORIGIN was meant to solve (e.g. REALM for multi-tenant servers), avoids the privacy gotchas that have recently come up, and as a bonus, is simpler.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 11 Dec 2015 08:51:51 -0800

Thanks for your comments. However, I don't think your assertion on matching
rules is correct.

First, ORIGIN sends the webapp origin. HOST sends the TURN DNS name. These
will typically be completely different, and HOST is under application
control as well. This is a substantial difference.

Second, for the TURN provider, the fact that they are using a multi-tenant
server vs several single-tenant servers is an implementation decision. If
they have multiple single-tenant servers with separate DNS names, then
distinguishing what usage is associated with each DNS name is obviously
trivial. The fact that they can continue to do this when running a
single-tenant server with multiple DNS names does not seem like a problem.

On Fri, Dec 11, 2015 at 5:44 AM, Alan Johnston <[email-masked]>
wrote:

> Justin,
>
> Thanks for posting this.
>
> I've been thinking about using HOST as well, but I think this approach
> generates new meta-data.  Essentially, new WebRTC usage information is
> generated at the STUN/TURN server where none was generated before. This is
> true for both cases: where the URI is the domain of the TURN provider and
> also where the domain is the WebRTC provider.
>
> Unless a comparison between the HOST and the ORIGIN is made, along the
> lines of what I proposed in Yokohama. In this case, all we have done is
> changed the name of the attribute from ORIGIN to HOST.  The same info will
> be sent over the wire.
>
> customers (e.g. app1.turnprovider.com, app2.turnprovider.com), all
> pointing to the same multi-tenant TURN server - and use the HOST attribute
> to identify the application and/or determine which REALM to return.
>
> For example: consider an app at www.myapp.com, which uses a TURN server
> at myapp.turnprovider.com (a CNAME for turnserver.turnprovider.com that
> was provisioned for myapp.com by turnprovider.com). In this case, the
> HOST attribute would contain "myapp.turnprovider.com", but not "
> www.myapp.com".
>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 11 Dec 2015 09:19:53 -0800

On Fri, Dec 11, 2015 at 8:51 AM, Justin Uberti <[email-masked]> wrote:

> Thanks for your comments. However, I don't think your assertion on
> matching rules is correct.
>

​So, many years ago livejournal.com moved from a model where the typical
URI was http://www.livejournal.com/name-of-journal to one where it was
http://name-of-journal.livejournal.com/ (that had been a paid option prior
to the shift, but it was relatively rare).  The users liked the change
because it resulted in better branding, but it meant that both the DNS
queries and later the SNI leaked the information about which journal was
being accessed.  Other blogging platforms went through similar changes.

What you are suggesting could have a similar effect.  While it might
theoretically possible for someone to set up an independent single-tenant
TURN server for each blog-name.example.com​ that was using WebRTC to fuel a
chat system, it seems pretty unlikely.  Using a multi-tenant system
disambiguated by HOST.turnserverfarm.example does not.  The result would be
that look-ups to the DNS for these turn servers would now reveal which HOST
is being contacted.  When DPRIVE is deployed, that will be mitigated, but
it is currently a privacy concern.  The current ORIGIN method, which the
draft requires to be protected by DTLS or DTLS, in contrast, does not leak
anything via the DNS.

If the working group does accept this change, I would strongly urge it to
update the security considerations to cover this case and to update the
description of multi-tenancy to match the most likely methods of
disambiguation.

regards,

Ted Hardie

---

From: Justin Uberti <[email-masked]>
Date: Fri, 11 Dec 2015 17:04:37 -0800

Ted,

I agree that DNS queries for the TURN server will be accessible to
eavesdroppers. However, the same can be said for blog-name.example.com
itself, which seems like a larger concern.

In the end the application has discretion on what it wants to do here - if
the TURN URI could be considered sensitive, it has the option of using a
non-sensitive URI, or another mechanism altogether, e.g. OAuth.

Agree this should be spelled out in the security considerations.

On Fri, Dec 11, 2015 at 9:19 AM, Ted Hardie <[email-masked]> wrote:

>> First, ORIGIN sends the webapp origin. HOST sends the TURN DNS name.
>> These will typically be completely different, and HOST is under application
>> Second, for the TURN provider, the fact that they are using a
>> multi-tenant server vs several single-tenant servers is an implementation
>> decision. If they have multiple single-tenant servers with separate DNS
>> names, then distinguishing what usage is associated with each DNS name is
>> obviously trivial. The fact that they can continue to do this when running
>> a single-tenant server with multiple DNS names does not seem like a problem.
>>
>
> http://name-of-journal.livejournal.com/ (that had been a paid option
> prior to the shift, but it was relatively rare).  The users liked the
> change because it resulted in better branding, but it meant that both the
> DNS queries and later the SNI leaked the information about which journal
> was being accessed.  Other blogging platforms went through similar changes.
>
> TURN server for each blog-name.example.com​ that was using WebRTC to fuel
> a chat system, it seems pretty unlikely.  Using a multi-tenant system

---

From: Alan Johnston <[email-masked]>
Date: Fri, 11 Dec 2015 21:10:16 -0600

Hi Justin,

The DISCUSS on STUN ORIGIN was because it generated new meta-data for
operators of STUN/TURN servers.

Are you arguing that your HOST proposal does not generate any new
meta-data?  That is, a STUN or TURN server gets no new data that relates to
site usage?

Or, are you arguing that the meta-data generated by HOST is of minimal
value for site usage?  If this is your assertion, I'd like you to explain
this more.  I can see multiple ways in which HOST could generate site usage
meta-data (see below), unless ORIGIN matching rules are applied.

See a few comments and questions below.

- Alan -

On Fri, Dec 11, 2015 at 10:51 AM, Justin Uberti <[email-masked]> wrote:

> will typically be completely different,
>

Why will these typically be different?  I see two cases:  1) the WebRTC
site runs its own STUN/TURN servers, in which case HOST and ORIGIN will
have the same domain.  2) the WebRTC gets a STUN/TURN URI from another
provider, which may or may not be specific to this WebRTC site, in which
case HOST and ORIGIN will be different domains, but could be related.

> and HOST is under application control as well.
>

Do you mean that the WebRTC site gets to choose the domain name present in
HOST?  Yes, and no.  It could either use the domain given it by the
STUN/TURN provider (which could identify the site or might not) or it could
generate its own DNS record, which would identify the site.

> This is a substantial difference.
>

This is the "we're not making the situation worse because there are other
ways of doing the same thing" argument.  This has worked in the past with
meta-data, but I think the signal from the IESG is that this is no longer a
justification.  Our proposal will be evaluated on its own as to whether it
generates usage meta-data or not, regardless if there are other ways and
tricks to generate the same meta-data.  This is my opinion based on what I
heard during the IESG review.  If others think I am wrong, then feel free
to jump in.

>> Overall, I think this approach solves the core problem ORIGIN was meant
>> to solve (e.g. REALM for multi-tenant servers), avoids the privacy gotchas

---

From: Justin Uberti <[email-masked]>
Date: Sat, 12 Dec 2015 12:51:50 -0800

> meta-data (see below), unless ORIGIN matching rules are applied.
The argument is somewhere in between.
1) By virtue of it being opt-in to the application, it generates no new
*implicit* metadata towards TURN server operators. This is a substantial
difference from ORIGIN, and IMO obviates the need for matching rules.
- if the site runs its own TURN server, this issue is irrelevant
- if the site uses an external TURN server, it can use/insist on a generic
name (this app explicit control is a significant difference from ORIGIN).
2) If used without DTLS, it does generate new metadata visible to
eavesdroppers. This can be addressed via DTLS, if the app thinks this is
important. But this is an orthogonal discussion to any name matching rules.

Overall: yes, technically there is new metadata. But it is different than
the metadata for ORIGIN, and I think enough so that it is worth taking
another run at this.

>> These will typically be completely different,
>>
>
>> On Fri, Dec 11, 2015 at 5:44 AM, Alan Johnston <[email-masked]
>> > wrote:
>>
>>> Justin,
>>>
>>> Thanks for posting this.
>>>
>>> This approach also deals effectively with the concerns around the
>>> browser disclosing the user's ORIGIN to the TURN provider. Since the app is
>>> in charge of what TURN URI it uses, it has control over what is disclosed
>>> to the TURN provider - which is just the name in the TURN URI, not the
>>> app's origin.
>>>

---

From: Simon Perreault <[email-masked]>
Date: Sun, 13 Dec 2015 10:42:09 -0500

Le 2015-12-12 15:51, Justin Uberti a écrit :
> - if the site uses an external TURN server, it can use/insist on a
> generic name (this app explicit control is a significant difference from
> ORIGIN).

And if the user configures his web browser to use a third-party TURN
server (e.g., numb.viagenie.ca) then no information about WebRTC
applications usage is revealed to the TURN server operator. That is very
different from ORIGIN.

Simon

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Dec 2015 09:22:51 +1100

On 12 December 2015 at 12:04, Justin Uberti <[email-masked]> wrote:
> eavesdroppers. However, the same can be said for blog-name.example.com itself, which seems like a larger concern.

Yes, the blogs are a greater concern.  I understand why a blog site
might choose to make that change (see
https://github.com/blog/1452-new-github-pages-domain-github-io#security-vulnerability),
but the privacy-security trade-off here is fundamentally different.

For the reasons Ted describes, HOST is strictly worse from a privacy
standpoint than ORIGIN.  Just.  And maybe the two will eventually be
the same, though the list of prerequisites on a solution to the DNS
leakage is rather long.

I think that Justin is right to try to find a solution that depends on
the application doing something special to enable the leakage.  I
think that's an important property.  Defaults matter.  And it's not
exactly hard to exfiltrate information using USERNAME, so that's the
bar we need to clear.  But HOST doesn't have a monopoly on the
solution there.  The same could be said for a FUNGUS attribute that
was explicitly set by the application in TURN server config.

---

From: Justin Uberti <[email-masked]>
Date: Sun, 13 Dec 2015 18:15:44 -0800

> was explicitly set by the application in TURN server config.

Sure, we could go down that route, in which FUNGUS is a way for the
application to set its desired REALM programatically. This would avoid the
DNS concerns since no lookup of the REALM would occur, although at that
point we're basically coming up with a more standard and aesthetically
pleasing way of doing what could already be done with USERNAME (e.g.
[email-masked])

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Dec 2015 13:48:24 +1100

On 14 December 2015 at 13:15, Justin Uberti <[email-masked]> wrote:
> at that point we're basically coming up with a more standard and
> aesthetically pleasing way of doing what could already be done with USERNAME
> (e.g. [email-masked])

Yeah, my thoughts exactly.  In that case it would possibly be better
to rely on an @domain convention for USERNAME and be done with it.

---

From: Justin Uberti <[email-masked]>
Date: Sun, 13 Dec 2015 20:25:07 -0800

One possibly important point: USERNAME isn't sent in the initial ALLOCATE.
If choosing a correct REALM on the server is important (which was the
original justification for this work), we need to either send USERNAME in
the initial ALLOCATE, or send up the preferred REALM.

---

From: Oleg Moskalenko <[email-masked]>
Date: Sun, 13 Dec 2015 21:18:12 -0800

USERNAME is not helpful in the initial ALLOCATION because different
realms may have the same (duplicate) names. We cannot require that the
name is unique across all realms.

On Sun, Dec 13, 2015 at 8:25 PM, Justin Uberti <[email-masked]> wrote:
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: Justin Uberti <[email-masked]>
Date: Sun, 13 Dec 2015 21:31:14 -0800

USERNAME would have a domain component (@example.com) in this scenario.

---

From: Oleg Moskalenko <[email-masked]>
Date: Sun, 13 Dec 2015 22:59:26 -0800

Justin, if we are combining username and domain, then the incentives
for having a multi-tenant TURN server are significantly diminishing.
One of original advantages of the ORIGIN attribute idea was that the
usernames are totally independent.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 14 Dec 2015 10:55:29 -0800

> the initial ALLOCATE, or send up the preferred REALM.
​I'm not seeing a downside to sending up the preferred REALM in the initial
allocate, other than it not re-using the known username@realm convention.
Am I missing something, or is it just spend the bytes and call it done?

regards,

Ted​

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 14 Dec 2015 11:02:29 -0800

In general case, how the user knows his realm ? He may not know it.
The user knows the name, the password, and the TURN server's IP
address or URL; knowing the realm is the TURN server's responsibility.

And how transferring the realm in an open request is different from
transferring the ORIGIN ? Those are metadatas of the same nature.

On Mon, Dec 14, 2015 at 10:55 AM, Ted Hardie <[email-masked]> wrote:
> I'm not seeing a downside to sending up the preferred REALM in the initial
> Ted

---

From: Ted Hardie <[email-masked]>
Date: Mon, 14 Dec 2015 11:11:05 -0800

On Mon, Dec 14, 2015 at 11:02 AM, Oleg Moskalenko <[email-masked]>
wrote:

> ​If I understood Justin's drift on this, the application needs to know the
realm, not the user.  It could be set by the application just as HOST would
have been set.

regards,

Ted​

---

From: Justin Uberti <[email-masked]>
Date: Mon, 14 Dec 2015 11:36:13 -0800

Exactly what Ted said.

The difference between REALM/HOST and ORIGIN is that the application needs
to set REALM/HOST, but ORIGIN would be auto-set by the browser.

The key outstanding question IMO is whether setting REALM properly is
actually useful, versus simply having the application include the domain in
USERNAME. Chrome uses REALM solely to compute HA1 and thereby
MESSAGE-INTEGRITY; since HA1 is defined as MD5(username ":" realm ":"
SASLprep(password)), the benefit of using REALM would be that you can use
existing password databases that compute HA1 with username/realm specified
separately. However, I'd like someone who actually has to deal with this
sort of thing to weigh in.

On Mon, Dec 14, 2015 at 11:11 AM, Ted Hardie <[email-masked]> wrote:

>> ​If I understood Justin's drift on this, the application needs to know
> the realm, not the user.  It could be set by the application just as HOST
> would have been set.
>
> regards,
>
> Ted​
>
>
>
>