Original text:
Using Multicast DNS to protect privacy when exposing ICE candidates <del> draft-ietf-rtcweb-mdns-ice-candidates-00 </del>  Abstract 2. <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>  2.1. <del> For any host candidate gathered by an ICE agent as part of RFC8445 section 5.1.1, obfuscation of the candidate is done as follows: </del>  Check whether the ICE agent has a usable registered mDNS hostname <del> resolving to the ICE host candidate's IP address.  If one exists, skip ahead to Step 6. If there is a registered hostname, replace the IP address of the ICE host candidate with the hostname.  Expose the candidate and abort these steps. </del>  Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local". Store the mDNS hostname and its related IP address in the ICE agent for future reuse. <del> Replace the IP address of the ICE host candidate with its mDNS hostname.  Expose the candidate. </del>  An ICE agent can implement this procedure in any way so long as it produces equivalent results to this procedure. An implementation may for instance pre-register mDNS hostnames by executing steps 3 to 5 and prepopulate an ICE agent accordingly.  By <del> doing so, only steps 1 and 2 of the above procedure will be executed at the time of gathering candidates. </del>  An implementation may also detect that mDNS is not supported by the <del> available network interfaces.  The ICE agent may skip step 3 and 4 </del>  and directly decide to not expose the host candidate. <del> This procedure ensures that a mDNS name is used to replace only one IP address.  Specifically an ICE agent using an interface with both </del>  IPv4 and IPv6 addresses MUST expose a different mDNS name for each address.  2.2. <del> For any remote host ICE candidate received by the ICE agent, the following procedure is used: </del>  If the connection-address field value of the ICE candidate does not end with ".local" or if the value contains more than one ".", Otherwise, resolve the candidate using mDNS. <del> If it resolves to an IP address, replace the value of the ICE host candidate by the resolved IP address and continue processing of the candidate. </del>  Otherwise, ignore the candidate. An ICE agent may use a hostname resolver that transparently supports both Multicast and Unicast DNS.  In this case the resolution of a <del> ".local" name may happen through Unicast DNS, see RFC6762 section 3. </del>  An ICE agent that supports mDNS candidates MUST support the situation where the hostname resolution results in more than one IP address. use the first IPv6 address resolved, otherwise the first IPv4 address. <del> 2.2.1. A peer-reflexive remote candidate could be learned and constructed from the source transport address of the STUN Binding request as an ICE connectivity check.  The peer-reflexive candidate could share the same address as a remote host ICE candidate that will be signaled or has been signaled, received and is in the process of name resolution. In addition to the elimination procedure of redundant candidates defined in Section 5.1.3 of RFC8445, which could remove constructed peer-reflexive remote candidates, the address of any existing peer- reflexive remote candidate should not be exposed to Web applications by ICE agents that implement this proposal, as detailed in Section #guidelines. </del> 3. <del> 3.1. When there is no user consent, the following filtering should be done to prevent private IP address leakage: </del>  <del> host ICE candidates with an IP address are not exposed as ICE candidate events. </del>  <del> Server reflexive ICE candidate raddr field is set to 0.0.0.0 and rport to 0. </del>  <del> SDP does not expose any a=candidate line corresponding to a host ICE candidate which contains an IP address. </del>  <del> 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. </del>  <del> 3.2. </del>  It is important that use of registered mDNS hostnames is limited in time and/or scope.  Indefinitely reusing the same mDNS hostname candidate would provide applications an even more reliable tracking mechanism than the private IP addresses that this specification is designed to hide.  The use of registered mDNS hostnames SHOULD be <del> scoped by origin, and have the lifetime of the page. If the generated mDNS hostname candidate does not follow the pattern described, the exposed candidate might be used for fingerprinting. If there are multiple host candidates with different IP addresses, IPv4 and/or IPv6, each results in a separate mDNS hostname candidate. The number of mDNS hostname candidates can provide a fingerprinting dimension.  If so desired an ICE agent MAY expose additional mDNS hostname candidates that are not registered. </del>  <del> 3.3. </del>  As noted in IPHandling, privacy may be breached if a web application <del> running in two browser contexts can determine whether it is running </del>  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 are running on the same device. To avoid this issue, browsers SHOULD NOT register mDNS names for <del> 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. 4. </del>  The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP

Reviewer comments:
Followup from , as discussed today
Will wait for LGTM from NAME before merging.
Rethought my approach here and rewrote the section accordingly. PTAL.
LGTM
Sorry for the delay. Github did not let me see any diffs over the weekend.

Revised text:
Using Multicast DNS to protect privacy when exposing ICE candidates  <ins> draft-ietf-rtcweb-mdns-ice-candidates-01 </ins> Abstract 2.  <ins> This section uses the concept of ICE agent as defined in RFC8445.  In the remainder of the document, it is assumed that each browsing context (as defined in Section 7.1 of HTMLSpec) has its own ICE agent. </ins> 2.1.  <ins> For any host candidate gathered by an ICE agent as part of RFC8445, Section 5.1.1, the candidate is handled as follows: </ins> Check whether the ICE agent has a usable registered mDNS hostname  <ins> resolving to the ICE candidate's IP address.  If one exists, skip ahead to Step 6. </ins> Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local". Store the mDNS hostname and its related IP address in the ICE agent for future reuse.  <ins> Replace the IP address of the ICE candidate with its mDNS hostname and provide the candidate to the web application. </ins> An ICE agent can implement this procedure in any way so long as it produces equivalent results to this procedure. An implementation may for instance pre-register mDNS hostnames by executing steps 3 to 5 and prepopulate an ICE agent accordingly.  By  <ins> doing so, only step 6 of the above procedure will be executed at the time of gathering candidates. </ins> An implementation may also detect that mDNS is not supported by the  <ins> available network interfaces.  The ICE agent may skip steps 2 and 3 </ins> and directly decide to not expose the host candidate.  <ins> This procedure ensures that an mDNS name is used to replace only one IP address.  Specifically, an ICE agent using an interface with both </ins> IPv4 and IPv6 addresses MUST expose a different mDNS name for each address. <ins> Any server-reflexive candidates generated from an mDNS local candidate MUST have their raddr field set to 0.0.0.0 and their rport field set to 0. Any candidates exposed to the web application via local descriptions MUST be identical to those provided during candidate gathering (i.e., MUST NOT contain private host IP addresses). </ins> 2.2.  <ins> For any remote ICE candidate received by the ICE agent, the following procedure is used: </ins> If the connection-address field value of the ICE candidate does not end with ".local" or if the value contains more than one ".", Otherwise, resolve the candidate using mDNS.  <ins> If it resolves to an IP address, replace the mDNS hostname of the ICE candidate with the resolved IP address and continue processing of the candidate. </ins> Otherwise, ignore the candidate. An ICE agent may use a hostname resolver that transparently supports both Multicast and Unicast DNS.  In this case the resolution of a  <ins> ".local" name may happen through Unicast DNS as noted in RFC6762, Section 3. </ins> An ICE agent that supports mDNS candidates MUST support the situation where the hostname resolution results in more than one IP address. use the first IPv6 address resolved, otherwise the first IPv4 address.  3.  <ins> In this example, mDNS candidates are exchanged between peers and resolved to obtain the corresponding IP addresses. </ins>  <ins> The following two examples indicate how peer-reflexive candidates for host IP addresses can be created due to timing differences. </ins>  <ins> In this example, a peer-reflexive candidate is generated because the mDNS candidate is signaled after the STUN checks begin. </ins>  <ins> In this example, a peer-reflexive candidate is generated because the mDNS resolution for name N2 does not complete until after the STUN checks are received. </ins>  <ins> 4. </ins>  <ins> The goal of this mechanism is to keep knowledge of private host IP addresses within the ICE agent while continuing to allow the application to transmit ICE candidates.  Besides keeping private host IP addresses out of ICE candidates, implementations must take steps to prevent these IP addresses from being exposed to web applications through other means. 4.1. Statistics related to ICE candidates that are accessible to the web application MUST NOT contain the IP address of a local or remote mDNS candidate; the mDNS name SHOULD be used instead. In addition, a peer-reflexive remote candidate may be constructed from a remote host IP address as a result of an ICE connectivity check, as described in Section 7.3.1.3 of RFC8445.  This check may arrive before the candidate due to signaling or mDNS resolution delays, as shown in the examples above. To prevent disclosure of the host IP address to the application in this scenario, statistics related to ICE candidates MUST NOT contain the IP address of any peer-reflexive candidate, unless that IP has already been learned through signaling of a candidate with the same address and either the same or a different port; this includes cases where the signaled candidate is discarded as redundant according to Section 5.1.3 of RFC8445. 4.2. When sending data to a TURN RFC5766 server, the sending client tells the server the destination IP and port for the data.  This means that if the client uses TURN to send to an IP that was obtained by mDNS resolution, the TURN server will learn the underlying host IP and port, and this information can then be relayed to the web application, defeating the value of the mDNS wrapping. To prevent disclosure of the host IP address to a TURN server, the ICE agent MUST NOT form candidate pairs between its own relay candidates and remote mDNS candidates.  Note that the converse is not an issue; the ICE agent MAY form candidate pairs between its own mDNS candidates and remote relay candidates, as in this situation host IPs will not be sent directly to the TURN server. This restriction has no effect on connectivity; in the cases where host IP addresses are private and need to be wrapped with mDNS names, they will be unreachable from the TURN server, and as noted above, the reverse path will continue to work normally. 4.3. When sending data to a TURN RFC5766 server, the sending client tells the server the destination IP and port for the data.  This means that if the client uses TURN to send to an IP that was obtained by mDNS resolution, the TURN server will learn the underlying host IP and port, and this information can then be relayed to the web application, defeating the value of the mDNS wrapping. To prevent disclosure of the host IP address to a TURN server, the ICE agent MUST NOT form candidate pairs between its own relay candidates and remote mDNS candidates.  Note that the converse is not an issue; the ICE agent MAY form candidate pairs between its own mDNS candidates and remote relay candidates, as in this situation host IPs will not be sent directly to the TURN server. This restriction has no effect on connectivity; in the cases where host IP addresses are private and need to be wrapped with mDNS names, they will be unreachable from the TURN server, and as noted above, the reverse path will continue to work normally. 4.4. </ins> It is important that use of registered mDNS hostnames is limited in time and/or scope.  Indefinitely reusing the same mDNS hostname candidate would provide applications an even more reliable tracking mechanism than the private IP addresses that this specification is designed to hide.  The use of registered mDNS hostnames SHOULD be  <ins> scoped by origin, and SHOULD have the lifetime of the page. </ins>  <ins> 4.5. </ins> As noted in IPHandling, privacy may be breached if a web application  <ins> running in two browsing contexts can determine whether it is running </ins> 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 are running on the same device. To avoid this issue, browsers SHOULD NOT register mDNS names for  <ins> WebRTC applications running in a third-party browsing context (i.e., a context that has a different origin than the top-level browsing context), or a private browsing context. 5. 5.1. The implementation of this proposal requires the mDNS querying capability of the browser for registering mDNS names or adding remote ICE host candidates with such names.  It also requires the mDNS responding capability of either the browser or the operating platform of the browser for registering, removing or resolving mDNS names.  In particular, the registration of name requires optional probing queries and mandatory announcing responses (RFC6762, Section 8), and this is performed at the beginning of ICE gathering; the addition of remote ICE host candidates with mDNS names generates mDNS queries for names of each candidate; the removal of names could happen when the browsing context of the ICE agent is destroyed in an implementation, and goodbye responses should be sent to invalidate records generated by the ICE agent in the local network (RFC6762, Section 10.1). A malicious Web application could flood the local network with mDNS messages by: creating browsing contexts that create ICE agents and start gathering of local ICE host candidates; destroying these local candidates soon after the name registration is done; adding fictitious remote ICE host candidates with mDNS names. RFC6762 defines a per-record multicast rate limiting rule, in which a given record on a given interface cannot be sent less than one second since its last transmission.  This rate limiting rule however does not mitigate the above attacks, in which new names, hence new records, are constantly created and sent.  A browser-wide mDNS message rate limit MUST be provided for all messages that can be indirectly dispatched by a web application, namely the probing queries, announcement responses, resolution queries, and goodbye responses associated with mDNS. 5.2. If the optional probing queries are implemented for the name registration, a malicious endpoint in the local network, which is capable of responding mDNS queries, could send responses to block the use of the generated names.  This would lead to the discarding of this ICE host candidate as in Step 5 in gathering. The above attack can be mitigated by skipping the probing when registering a name, which also conforms to Section 8 in RFC6762, given that the name is randomly generated for the probabilistic uniqueness (e.g. a version 4 UUID) in Step 3 in gathering.  However, a similar attack can be performed by exploiting the negative responses (defined in RFC6762, Section 8.1), in which NSEC resource records are sent to claim the nonexistence of records related to the gathered ICE host candidates. The existence of malicious endpoints in the local network poses a generic threat, and requires dedicated protocol suites to mitigate, which is beyond the scope of this proposal. 5.3. A malicious endpoint in the local network may also record other endpoints who are registering, unregistering, and resolving mDNS names.  By doing so, they can create a session log that shows which endpoints are communicating, and for how long.  If both endpoints in the session are on the same network, the fact they are communicating can be discovered. As above, mitigation of this threat is beyond the scope of this proposal. 6. </ins> The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP