Change:
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. This section uses the concept of ICE agent as define in RFC5245.  In </del> <ins> This section uses the concept of ICE agent as define in RFC8445.  In </ins> 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 <del> RFC5245 section 4.1.1, obfuscation of the candidate is done as </del> <ins> RFC8445 section 5.1.1, obfuscation of the candidate is done as </ins> follows: Check whether the context ICE agent registered a name resolving to

Discussion:
Define a new STUN attribute and use it to flag a prflx candidate that may share the IP address with a host candidate.
Are we going to revise this to focus on Option 3?
Yes, the latest commit is focused on Option 3. PTAL.
We found there is an issue with prflx candidates, and we may need to clarify the de-duplication logic in the proposal. Suppose the local ICE agent is in the resolution process of an mDNS remote candidate, the remote ICE agent starts to ping the local agent with connectivity checks from the remote candidate we are resolving, we may need to define a reliable way to identify that the prflx candidate is the same one as the mDNS candidate and not create a duplicate candidate. Also, the identical and duplicate prflx candidate can be a source of IP leak (via stats).
Interesting issue, can it be handled similarly to other redundant candidates as defined in URL
Probably not, that covers a different scenario. I think that the priority attribute could be a solution here.
At the time we receive the STUN check, we have the mDNS candidate with its foundation and priority and host:port. In the received STUN check, we will only have the PRIORITY attribute (of the attributes noted above); the port may be mutated by an intervening NAT. And even the PRIORITY attribute will not match that of the mDNS candidate, as the type preference will be set to 110, per 5245, S 7.1.2.1. If we get a STUN check after we get the mDNS candidate but before resolution completes, we can check to see if the mDNS candidate priority matches the STUN check priority after adjusting the type preference of the mDNS candidate priority to 110. If there is a match, we can avoid creating a prflx candidate. However, what should stats say at this point? Also, what should happen if we get the STUN check before we get the mDNS candidate via signaling (as could be the case for the caller)?

I was thinking of using the PRIORITY attribute from the STUN check, particularly the value of type preference (before we change it to 110 when creating a prflx remote candidate) to infer the underlying type, but the value used in practice is only recommended by 8445 (or 5245), and the inter-op between different implementations is not well-defined. I am wondering if it is possible to define a must-level value of type preference for "hostname" candidate, e.g. in a separate spec for FQDN handling in ICE. I think for prflx candidates, RTCIceCandidateStats still applies and libwebrtc currently exposes it, which has the IP. We should create a prflx candidate (as libwebrtc currently would do), since there is no way to tell if we would have any remote host candidates with unresolved IPs. If we add an indication in the signaling to let the remote endpoint know we would use mDNS candidates, I feel it could be the same case as the one we receive a check during resolution.
This is a good question; I had a similar worry about the use of PRIORITY. Perhaps hostname candidates should include the hostname in the STUN check. I think that invalidates this technique; a web page could then easily use this loophole to get the local IP. (Create 2 PCs, never send the answer, observe IP resulting from prflx candidate). If we put a marker in the STUN check (that this is a check from a mDNS candidate), we could eat the check or queue it until the actual mDNS candidate had been received and resolved. Otherwise, I think we end up leaking the IP, as noted above.
Rather than a marker can't we add an STUN attribute containing the mDNS host-name in question? This eliminates the guesswork out of it: even with just supporting default routes, we could still have 2 mDNS candidates, one for IPv4 and one for IPv6 (and the mDNS candidate signaled doesn't tell us which is which) if at some point in the future we want to support non-default routes through mDNS, this might produce even more mDNS candidates This should then be a 'comprehension required' attribute, so that pre-mDNS ICE implementations don't inadvertently leak the IP.

Good point, and I feel this is much better than recommending adding anything in the signaling, which we cannot really ask the implementation to comply. This should also help the case when we receive the STUN check before getting the mDNS candidate via signaling. Would the plain hostname add too much payload (e.g. 128-bit UUID)? We have received the feedback that ICE overheads are quite heavy for low bandwidth. Also, if we do the above, should we stop the ongoing/imminent mDNS resolution? The STUN check basically provide one resolution in this case. The would-be prflx candidate would immediately be converted/merged to a host candidate. If we consider the STUN check with a hostname as one resolution as above, it looks to me that we could avoid creating prflx candidates that would leak private IPs. If we allow the mDNS resolution to start/continue, while also creating a host instead of prflx with IP of the check source, there is an issue of how to reconcile conflicts if the resolution later returns something different. This could be an alternative solution to using the info in the STUN check as a resolution as above. I am not sure which makes more sense at the moment.
It seems to me that the signaled mDNS host-name does need to be resolved through mDNS. The STUN check could be malicious in itself (e.g. part of a DoS attack), until we have done the mDNS resolution we can't tell whether the originator is a real candidate. Since STUN checks are in the clear, adding the host-name does leak some information that previously was protected through the signalling channel. If the mDNS host-names are randomly generated UUIDs, not sure this is an issue. If implementers were to use something not 100% random, this could be used for fingerprinting? I'm unsure what the bar is, but the IETF is putting a lot of emphasis on privacy.
From a privacy point of view, I believe the most important issue is to ensure that a simple page creating two peer connections cannot get access to the IP address. Since the same browser is controlling both endpoints, that should be made possible. In the case of a successful connection, the fact that the other party is leaking the private IP address cannot be fully addressed in general.

I think stats should basically not provide the peer-reflexive IP address unless it can ensure that it is not breaking the privacy of the other party.
As discussed in URL, we could simplify the solution if we agree to not expose the RTCICeCandidateStats address member for prflx candidates. Let's discuss this approach in URL
Does mDNS itself have any protection against malicious advertisements? To NAME 's point above, an attacker would need to know the ICE ufrag/pwd and your local IP in order to send STUN checks with a bogus name from a bogus address - not sure this is realistic or creates a real-world problem - but maybe I'm not thinking about it right. Anyway, recapping the options we have: I kind of like having STUN serve as a mechanism for DNS. The downside here is that adding 44 bytes to the STUN check increases STUN bandwidth from non-TURN local candidates by 40% (URL). However, in Mode 2, with a small number of candidate pairs, this may be acceptable. Using the marker is a cheaper form of Option 1, but we have to delay servicing the check until we get and resolve the mDNS name, which will slow down connections slightly in some edge cases. Feels like the most complex option. NAME 's suggestion from w3c/webrtc-stats. Simple, easy to reason about. Probably causes some collateral damage to the stats of existing apps.
Regarding option 1: We could, instead of adding a 44 byte mDNS hostname, add the 16 byte random number that is the basis for the UUID. This would put a MUST requirement on the use of UUIDs for mDNS names and would maybe hamper server implementations down the road. At the same time, I think this also avoids (more easily) the case where we have multiple IP addresses associated with an MDNS name.
Agreed, we could have multiple attribs for the hostname - a string form or a compact uuid-bytes form, both of which would expand to the same thing.
Option 3 will be discussed at TPAC 2018. If the MDNS proposal is the only driver for changing STUN, I feel we should try to push for option 3.

If it might provide benefit in other contexts, the story might be different (although I still think we should try to fix w3c/webrtc-stats)
As per TPAC discussion within WebRTC WG, we should be able to go on with option 3.
Approving with suggestion, will tweak location of text later