Change:
SDP does not expose any a=candidate line corresponding to a host ICE candidate which contains an IP address. <del> RTCIceCandidateStats dictionaries exposed to web pages do not contain any 'ip' member if related to a host ICE candidate. </del> <ins> Statistics related to ICE candidates MUST NOT contain the resolved IP address of a remote mDNS candidate or the IP address of a peer- reflexive candidate, unless that IP address has already been learned through other means, e.g., receiving it in a separate server-reflexive remote candidate. </ins> <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. 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> 3.3. </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> 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 private browsing 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> 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.

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