Re: [tram] Path Forward for STUN ORIGIN

[Alan Johnston <[e-mail]>]

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 <[e-mail]>
wrote:

> 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
> >
>