Re: [rtcweb] Security implications of host candidates

[Justin Uberti <[e-mail]>]

On Mon, Jul 9, 2018 at 3:42 PM Martin Thomson <[e-mail]>
wrote:

> On Tue, Jul 10, 2018 at 8:19 AM Justin Uberti <[e-mail]> wrote:
> > Well, Tor browser would really need all WebRTC traffic to flow through
> Tor, to prevent linking sessions via the srflx IPs.
>
> The anonymity set would be the hosts on the same exit node, which I
> assume is >1.  More to the point, different top-level contexts use
> different circuits, and therefore (likely) different exits.  IOW, as
> proposed, the linking there is fine.
>

If Tor is already forcing all WebRTC traffic through a Tor proxy, it
doesn't need this tweak; TURN is the only option. This is somewhat
academic, but it points out an issue with the WWTBD framing.

>
> > But let me get to the point. Adding the limitations discussed for .local
> has minimal downside, but what, if anything, should we do with IPv6 host
> candidates? If we decide that we want to prevent host-host IPv6
> connections, there will be implications for datachannel applications.
>
> I don't think that we should treat v6 specially here.  If it is a host
> candidate, use mDNS or don't provide it.  That avoids making a
> judgment about the relative prevalence of v6 NAT and other such
> things.
>

The reason for the different treatment is that it could be argued that v6
addresses, being already public and unique, don't constitute a new signal.
That makes the tradeoff with datachannel impact less clear.