Change:
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 URL
LGTM

Discussion:
Abstract <del> 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. </del> <ins> 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. </ins> 1. <del> 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. The first approach exposes client private IP addresses by default, as can be seen from websites such as IPLeak.  The second approach implemented in the WebKit engine enforces the following policy: By default, use mode 3 as defined in IPHandling: any host ICE candidate is filtered out. 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. 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. 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. </del> <ins> 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. 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. </ins> 2. <del> 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. 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. 3. </del> This section uses the concept of ICE agent as define in RFC8445.  In the remainder of the document, it is assumed that each browser execution context has its own ICE agent. <del> 3.1. </del> <ins> 2.1. </ins> For any host ICE candidate gathered by a browsing context as part of RFC8445 section 5.1.1, obfuscation of the candidate is done as

Replace the IP address of the ICE host candidate with the name with ".local" appended to it.  Expose the candidate. <del> 3.2. </del> <ins> 2.2. </ins> For any remote host ICE candidate received by the ICE agent, the following procedure is used:

IPv6 address.  In that case, the IPv6 address may be used preferably to the IPv4 address. <del> 4. </del> <ins> 3. </ins> <del> 4.1. </del> <ins> 3.1. </ins> When there is no user consent, the following filtering should be done to prevent private IP address leakage:

RTCIceCandidateStats dictionaries exposed to web pages do not contain any 'ip' member if related to a host ICE candidate. <del> 4.2. </del> <ins> 3.2. </ins> Dynamically generated names can be used to track users if used too often.  Conversely, registering too many names will also generate useless processing.  The proposed rule is to create and register a new generated name for a given IP address on a per execution context. <del> 4.3. </del> <ins> 3.3. </ins> <del> Privacy might also be breached if two execution contexts can identify whether they are run in the same device based on a successful peer- to-peer connection.  The proposed rule is to not register any name using Multicast DNS for any ICE agent belonging to: </del> <ins> 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. </ins> <del> A third-party browser execution context, i.e. a context that is not same origin as the top level execution context. </del> <ins> 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. </ins> <del> A private browsing execution context. 5. </del> <ins> 4. </ins> The proposal relies on identifying and resolving any Multicast DNS based ICE candidates as part of adding/processing a remote candidate.