Re: [tram] Path Forward for STUN ORIGIN - refer policy

[Cullen Jennings <[e-mail]>]

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