Re: [tram] Path Forward for STUN ORIGIN

[Martin Thomson <[e-mail]>]

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 <[e-mail]> 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.
>
> 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 -
>
>
>
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
>