Re: [rtcweb] Security implications of host candidates

[youenn fablet <[e-mail]>]

Thanks for the feedback.

I'm not sure that what is proposed (limiting to a top-level browsing
>
context that isn't also private browsing) is the best way to achieve
> the stated policy goals in the draft.  And more fundamentally, there
> are probably several policies that browsers might reasonably adopt
> along those lines.
>

Agreed, browsers might have different constraints and security rules (ITP
in Safari for instance) that should be taken into consideration when
solving that particular issue.

It seems also that, given that this is quite tied to browsers and execution
contexts, guidelines might better fit in W3C land if we think there is a
need for such guidelines.
For instance, W3C specs could use some IETF defined hooks to provide
guidelines on how to set the MDNS policy/MDNS names to be used by a
particular ICE agent.

The best idea I have there is to fail resolution for .local names that
> the browser itself has minted for other origins[1].  That way,
> connections that are cross-origin and same-host would always at least
> hit a hairpin or relay.  Of course, failing resolution so quickly
> might leak information, so additional caution might be necessary (I
> don't think that it does, provided that a candidate is not entered
> into a checklist before resolution occurs, but I'm not sure how that
> would be implemented).
>

There is also the issue of detecting same browser clients by failing
connections.
Let's say a web site identifies three clients A, B and C behind a NAT.
If A is able to connect to both B and C without TURN but B and C are not
able to connect with each other without TURN, a web site could probably
infer that B and C are running on the same browser and are not able to
connect with each other because of this rule.

While this case is not super likely for top level pages (and anyway, the
user somehow trusts the page and might already be authenticated with), this
might more often happen with third party tracking iframes.


> This suggests that you could share mDNS names for frames under the
> same top-level browsing context without leaking more information,
> which could be very useful.
>

Agreed if these frames are same-origin with the top-level browsing context.