Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: Privacy text was moved to ip - handling , so no longer needed here . Update some surrounding sections accordingly . 
 LGTM . Let 's merge this one , we will correct RFC6762 in the PR that is already doing that or as an editorial commit . 
 As discussed at IETF 101 , ip - handling should define the problems , and this document should present the mDNS solution . 
 See 
 LGTM
Paragraph (version A):
WebRTC applications rely on ICE candidates to enable peer-to-peer
connections between clients in as many network configurations as
possible.  To maximize the probability to create a direct peer-to-
peer connection, client private IP addresses are often exposed
without user consent.  This is currently used as a way to track
users.  This document describes a way to share IP addresses with
other clients while preserving client privacy.  This is achieved by
obfuscating IP addresses using dynamically generated names resolvable
through Multicast DNS RFC6763.
Paragraph (version A):
As detailed in IPHandling, exposing client private IP addresses
allows maximizing the probability to successfully create a connection
between two clients.  This information is also used by many web sites
as a way to fingerprint and identify users without their consent.
Paragraph (version A):
By default, use mode 3 as defined in IPHandling: any host ICE
candidate is filtered out.
Paragraph (version A):
Use mode 2 as defined in IPHandling if there is an explicit user
action to trust the web site: host ICE candidates are exposed to
the web site based on the use of
navigator.mediaDevices.getUserMedia, which typically prompts the
user to grant or deny access to cameras/microphones.
Paragraph (version A):
The second approach supports most common audio/video conference
applications but leads to failing or suboptimal connections for
applications relying solely on data channel.  This is particularly an
issue on unmanaged networks, typically home or small offices where
NAT loopback might not be supported.
Paragraph (version A):
To overcome the shortcomings of the above two approaches, this
document proposes to register dynamically generated names using
Multicast DNS when gathering ICE candidates.  These dynamically
generated names are used to replace private IP addresses in host ICE
candidates.  Only clients that can resolve these dynamically
generated names using Multicast DNS will get access to the actual
client IP address.
Paragraph (version A):
The gathering of ICE candidates without user consent is a well-known
fingerprinting technique to track users.  This is particularly a
concern when users are connected through a NAT which is a usual
configuration.  In such a case, knowing both the private IP address
and the public IP address will usually identify uniquely the user
device.  Additionally, Internet web sites can more easily attack
intranet web sites when knowing the intranet IP address range.
Paragraph (version A):
A successful WebRTC connection between two peers is also a potential
thread to user privacy.  When a WebRTC connection latency is close to
zero, the probability is high that the two peers are running on the
same device.  Browsers often isolate contexts one from the other.
Private browsing mode contexts usually do not share any information
with regular browsing contexts.  The WebKit engine isolates third-
party iframes in various ways (cookies, ITP) to prevent user
tracking.  Enabling a web application to determine that two contexts
run in the same device would defeat some of the protections provided
by modern browsers.
Paragraph (version B):
WebRTC applications collect ICE candidates as part of the process of
creating peer-to-peer connections.  To maximize the probability of a
direct peer-to-peer connection, client private IP addresses are
included in this candidate collection.  However, disclosure of these
addresses has privacy implications.  This document describes a way to
share local IP addresses with other clients while preserving client
privacy.  This is achieved by obfuscating IP addresses with
dynamically generated Multicast DNS RFC6763 names.
Paragraph (version B):
As detailed in IPHandling, exposing client private IP addresses by
default maximizes the probability of successfully creating direct
peer-to-peer connection between two clients, but creates a
significant surface for user fingerprinting.  IPHandling recognizes
this issue, but also admits that there is no current solution to this
problem; implementations that choose to use Mode 3 to address the
privacy concerns often suffer from failing or suboptimal connections
in WebRTC applications.  This is particularly an issue on unmanaged
networks, typically homes or small offices, where NAT loopback may
not be supported.
Paragraph (version B):
This document proposes an overall solution to this problem by
registering ephemeral Multicast DNS names for each local private IP
address, and then providing those names, rather than the IP
addresses, to the web application when it gathers ICE candidates.
WebRTC implementations resolve these names to IP addresses and
perform ICE processing as usual, but the actual IP addresses are not
exposed to the web application.
Paragraph (version A):
A third-party browser execution context, i.e. a context that is
not same origin as the top level execution context.
Paragraph (version A):
A private browsing execution context.
Paragraph (version B):
As noted in IPHandling, privacy may be breached if a web application
running in two browser contexts can determine whether it is running
on the same device.  While the approach in this document prevents the
application from directly comparing local private IP addresses, a
successful local WebRTC connection can also present a threat to user
privacy.  Specifically, when the latency of a WebRTC connection
latency is close to zero, the probability is high that the two peers
are running on the same device.
Paragraph (version B):
To avoid this issue, browsers SHOULD NOT register Multicast DNS names
for WebRTC applications running in a third-party browser execution
context (i.e., a context that has a different origin than the top-
level execution context), or a private browser execution context.