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>  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>  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. 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 follows: </del>  <del> Check whether the context ICE agent registered a name resolving to the ICE host candidate IP address. </del>  <del> If the ICE agent registered the name, replace the IP address of the ICE host candidate with the name with ".local" appended to it. Expose the candidate and abort these steps. </del>  <del> Generate a random unique name, typically a version 4 UUID as defined in RFC4122. </del>  <del> Register the unique name using Multicast DNS. </del>  <del> If registering of the unique name fails, abort these steps.  The </del>  candidate is not exposed. <del> Store the name and its related IP address in the ICE agent for future reuse. </del>  <del> Replace the IP address of the ICE host candidate with the name with ".local" appended to it.  Expose the candidate. </del>  <del> 3.2. </del>  For any remote host ICE candidate received by the ICE agent, the following procedure is used: If the connection-address field value of the ICE candidate does <del> not finish by ".local", process the candidate as defined in RFC8445. </del>  <del> Otherwise, remove the ".local" suffix to the value and resolve it using Multicast DNS. </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 Otherwise, ignore the candidate. <del> Multicast DNS resolution might end up retrieving both an IPv4 and IPv6 address.  In that case, the IPv6 address may be used preferably to the IPv4 address. </del>  <del> 4. </del>  <del> 4.1. </del>  When there is no user consent, the following filtering should be done to prevent private IP address leakage: 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>  4.2. <del> 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> 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: A third-party browser execution context, i.e. a context that is not same origin as the top level execution context. </del>  <del> A private browsing execution context. </del>  5. <del> The proposal relies on identifying and resolving any Multicast DNS based ICE candidates as part of adding/processing a remote candidate. ICESDP section 4.1 could be updated to explicitly allow Multicast DNS names in the connection-address field. </del>  <del> The proposal relies on adding the ability to register Multicast DNS names at ICE gathering time.  This could be described in ICESDP and/ or WebRTCSpec. </del>  The proposal allows updating IPHandling so that mode 2 is not the mode used by default when user consent is not required.  Instead, the <del> default mode could be defined as mode 3 with Multicast DNS based ICE </del>  candidates.

Attacks by message flooding and name registration blocking are detailed.
This PR is doing some renaming. Maybe it should be done in a separate commit PR. Also, the mention of a mdns name per browsing context might conflict with another PR.
LGTM with change to make limit browser-wide.
LGTM

Abstract  <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 (mDNS) RFC6762 names. </ins> 1.  <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 mDNS 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.  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.  <ins> 2.1. </ins>  <ins> For any host candidate gathered by an ICE agent as part of RFC8445 section 5.1.1, the candidate is processed as follows: </ins>  <ins> Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE host candidate's IP address.  If one exists, skip ahead to Step 6. </ins>  <ins> Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local". </ins>  <ins> Register the candidate's mDNS hostname as defined in RFC6762. </ins>  <ins> If registering of the mDNS hostname fails, abort these steps.  The </ins> candidate is not exposed.  <ins> Store the mDNS hostname and its related IP address in the ICE agent for future reuse. </ins>  <ins> Replace the IP address of the ICE host candidate with its mDNS hostname, and expose the candidate as usual. </ins>  <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 doing so, only step 6 of the above procedure will be executed at the time of gathering candidates. An implementation may also detect that mDNS is not supported by the available network interfaces.  The ICE agent may skip steps 2 and 3 and directly decide to not expose the host candidate. This procedure ensures that a mDNS name is used to replace only one IP address.  Specifically, an ICE agent using an interface with both IPv4 and IPv6 addresses MUST expose a different mDNS name for each address. 2.2. </ins> For any remote host ICE candidate received by the ICE agent, the following procedure is used: If the connection-address field value of the ICE candidate does  <ins> not end with ".local" or if the value contains more than one ".", then process the candidate as defined in RFC8445. </ins>  <ins> Otherwise, resolve the candidate using mDNS. </ins> If it resolves to an IP address, replace the value of the ICE host candidate by the resolved IP address and continue processing of Otherwise, ignore the candidate.  <ins> An ICE agent may use a hostname resolver that transparently supports both Multicast and Unicast DNS.  In this case the resolution of a ".local" name may happen through Unicast DNS, see RFC6762 section 3. An ICE agent that supports mDNS candidates MUST support the situation where the hostname resolution results in more than one IP address. In this case, the ICE agent MUST take exactly one of the resolved IP addresses and ignore the others.  The ICE agent SHOULD, if available, use the first IPv6 address resolved, otherwise the first IPv4 address. 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. </ins>  <ins> 3. </ins>  <ins> 3.1. </ins> When there is no user consent, the following filtering should be done to prevent private IP address leakage: SDP does not expose any a=candidate line corresponding to a host ICE candidate which contains an IP address.  <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. 3.2. 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 scoped by origin, and SHOULD have the lifetime of the page. 3.3. 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. To avoid this issue, browsers SHOULD NOT register mDNS 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. 4. 4.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 execution 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 execution 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. </ins> 4.2.  <ins> 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 Section #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 Section #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. </ins> 4.3.  <ins> 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. </ins>  <ins> As above, mitigation of this threat is beyond the scope of this proposal. </ins> 5.  <ins> The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP section 4.1 could be updated to explicitly allow mDNS names in the connection-address field. </ins>  <ins> The proposal relies on adding the ability to register mDNS names at ICE gathering time.  This could be described in ICESDP and/or WebRTCSpec. </ins> The proposal allows updating IPHandling so that mode 2 is not the mode used by default when user consent is not required.  Instead, the  <ins> default mode could be defined as mode 3 with mDNS-based ICE </ins> candidates.


Using Multicast DNS to protect privacy when exposing ICE candidates <del> draft-ietf-rtcweb-mdns-ice-candidates-latest </del>  Abstract

LGTM but travis does not seem happy, not sure why: git -C /tmp/ghpages5574 push -q URL gh-pages 684make: * [ghpages] Error 128
I think the bot doesn't have push credentials on this repo. I'll look into it.
LGTM. The travis failure may render https://rtcweb-URL unavailable but shouldn't impact other parts. I wonder if the failure is caused by name mismatch somewhere in the config.

Using Multicast DNS to protect privacy when exposing ICE candidates  <ins> draft-ietf-mmusic-mdns-ice-candidates-latest </ins> Abstract


For the most part, backward compatibility does not present a significant issue for the mDNS technique.  When an endpoint that <del> supports mDNS communicates with an endpoint that does not, the legacy endpoint will still provide its local IP addresses, and accordingly a direct connection can still be attempted, even though the legacy endpoint cannot resolve the mDNS names provided by the new endpoint. In the event the legacy endpoint attempts to resolve mDNS names using Unicast DNS, this may cause ICE to take somewhat longer to fully complete, but should not have any effect on connectivity or connection setup time. </del>  However, some legacy endpoints are not fully spec-compliant and can behave unpredictably in the presence of ICE candidates that contain a <del> hostname, potentially leading to ICE failure.  Some endpoints may also fail to handle a connectivity check from an address that they have not received in signaling.  During the aforementioned experimental testing, the connection rate when interacting with endpoints that provided raw IP addresses (and therefore should be unaffected) decreased by 3% (relative), presumably for these reasons. </del>  6.

Legacy parsers may not be able to parse non-IP-addresses. It might be worth mentioning this issue in that section. Also: Section 5.3 says: "When an endpoint that supports mDNS communicates with an endpoint that does not, the legacy endpoint will still provide its local IP addresses, and accordingly a direct connection can still be attempted, even though the legacy endpoint cannot resolve the mDNS names provided by the new endpoint." Please make it more clear that the legacy endpoint is the one that does not support mDNS. Something like: "When an endpoint that supports mDNS communicates with a legacy endpoint that does not, the..." Taken from Christer review at URL
Seems reasonable, I think just inserting that one additional word is sufficient.
made one other comment: "We have seen one issue with a particular endpoint that did not implement ICE prflx candidates and could not follow the guidance in the text. This is already alluded to in S 4.3, but we may want to explicitly use the phrase "peer-reflexive" to make clear what behavior is needed from the legacy ICE agent." It seems like I added some of the Q4 text to Q3. Here is a corrected version of my question: Q1: I think it needs to be more clear that mDNS domain names (.local) can only be resolved by remote peers within the same local network. Section 5.1 does talk about this, and it may be an implicit assumption, but I think it should be pointed out in the beginning of the document. Q2: Related to Q1, think it needs to be more clear that the mechanism prevents IP address leaking to peers outside the local network. Inside the local network I assume that web apps can still find out about the local address simply by performing an mDNS lookup on the mDNS domain name. Q3: The draft makes an assumption that the mDNS domain names are unique. Why making that assumption? If the local network supports multicast, there may even be non-WebRTC applications using mDNS, which increases the risk for collision. Q4: Section 3.1.1 says that an ICE agent, when it gathers candidates, generates a UNIQUE mDNS domain name. I assume that means that the mDNS domain name will only be valid for the duration of the ICE session. Doesn't that mean that there is no need for other ICE agents to cache the mDNS domain name:IP address mapping for "future use", because the mDNS domain name won't be used in future anyway? Also, I am not sure whether ICE implementations should cache mappings to begin with. That's the task of the mDNS client of the host. Q5: Section 5.3 says: "When an endpoint that supports mDNS communicates with an endpoint that does not, the legacy endpoint will still provide its local IP addresses, and accordingly a direct connection can still be attempted, even though the legacy endpoint cannot resolve the mDNS names provided by the new endpoint." Please make it more clear that the legacy endpoint is the one that does not support mDNS. Something like: "When an endpoint that supports mDNS communicates with a legacy endpoint that does not, the..." Q6: If I remember correctly, people have raised issues with legacy parsers not being able to parse non-IP-addresses. If so, shouldn't that be mentioned in Section 5.3? (NOTE: Eventhough the draft updates RFC 8839, to support mDNS domain names, it does not solve the issue for legacy parsers.) Q7: The draft does not give any guidance regarding how long an ICE agent can safely cache an mDNS Regards, Christer

For the most part, backward compatibility does not present a significant issue for the mDNS technique.  When an endpoint that  <ins> supports mDNS communicates with a legacy endpoint that does not, the legacy endpoint will still provide its local IP addresses, allowing the new endpoint to attempt direct connections to those addresses. Through the process of learning peer-reflexive candidates described in RFC8445, the legacy endpoint will also learn the IP addresses of the mDNS-aware endpoint, allowing ICE to succeed even though the legacy endpoint cannot resolve the mDNS names.  In the event the legacy endpoint attempts to resolve the mDNS names using Unicast DNS, this may cause ICE to take somewhat longer to fully complete, but should not have any effect on connectivity or connection setup time. </ins> However, some legacy endpoints are not fully spec-compliant and can behave unpredictably in the presence of ICE candidates that contain a  <ins> hostname, potentially leading to ICE failure.  Specifically, the SDP parsers in these endpoints may raise a fatal error when receiving such candidates, rather than simply ignoring them. Some endpoints may also fail to handle a connectivity check from an address that they have not received in signaling (i.e., they do not support learning peer-reflexive candidates as described above), leading to ICE failure.  During the aforementioned experimental testing, the connection rate when interacting with endpoints that provided raw IP addresses (and therefore should be unaffected) decreased by 3% (relative), presumably for these reasons. </ins> 6.


WebRTC applications collect ICE candidates as part of the process of creating peer-to-peer connections.  To maximize the probability of a <del> 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 concealing IP addresses with dynamically generated Multicast DNS (mDNS) names. </del>  1. <del> As detailed in IPHandling, exposing client private IP addresses by </del>  default to web applications maximizes the probability of successfully creating direct peer-to-peer connections between clients, but creates a significant surface for user fingerprinting.  IPHandling recognizes This document proposes an overall solution to this problem by extending ICESDP to allow ICE implementations to register ephemeral <del> mDNS RFC6762 names for local private IP addresses, and then provide those names, rather than the IP addresses, in their ICE candidates. While this technique is intended to benefit WebRTC implementations in web browsers, by preventing collection of private IP addresses by </del>  arbitrary web pages, it can also be used by any endpoint that wants to avoid disclosing information about its local network to remote peers on other networks. resolution internally and will not disclose the actual IP addresses to the application.  2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Addresses part of .
Nils reviewed the document at URL There are a number of clarification points that could be made from the draft Makes sense to me. Right, I would tend to go with private IP addresses given RFC1918. We could refer to section 3.1.2.2 and refer to IP handling modes as well. We might want to further clarify that generating mDNS candidates ahead of time is an optimization. Makes sense to me.
Section 5.1 assumes that devices are on the same network. It might be good to be more explicit (maybe in the introduction) that local candidates are mostly useful when two devices are on the same network, which is where mDNS is actually useful.
Taken from Christer review at URL
Agree, this seems worth of its own paragraph in the intro, and probably also a brief mention at the start of Section 5. Hello, I was asked to review URL Here are my comment and questions: Abstract: “To maximize the probability of a direct peer-to-peer connection, client private IP addresses are included in this candidate collection.” I think it would make sense to replace “client” with ICE agent here, as client and server in the pure ICE context doesn’t make too much sense. I would suggest to change it to “..., private IP addresses of the ICE agent are included…”. In the abstract the terms “private IP addresses” and “local IP addresses” are used. I would suggest sticking to just one term for consistency. Section 1. “Introduction” has the same mix of local vs private in it. Section 3.1.1 point 1 I think it would be helpful if this draft at least offers the suggestion to replace all RFC1918 addresses, or put a reference to section 3.1.2.2 as a recommendation on how to determine which addresses to replace. Section 3.1.2.2 3rd paragraph “Regardless of results, …” confuses me. The last sentence in the paragraph before talks about the case of a public candidate. If I’m not mistaken in the case of a public address there shouldn’t be a server reflexive candidate generated. Section 3.1.2.2 4th paragraph While I agree that caching the result might be useful it can become dangerous in case the set of STUN servers changes. As the new STUN servers might return different results, cached results should be invalidated. Would it be worth adding a warning about this? Section 6.4 I’m confused by the diagram showing that both agents send over their mDNS candidates before having checked with the STUN server if the interface IP addresses need to be filtered or not. I understand that section 3.1.2.2 recommends to first wait for the STUN binding response from the STUN server before deciding which addresses should be filtered and which not. Why is this example showing it differently? Best regards Nils Ohlmeier
It seems like I added some of the Q4 text to Q3. Here is a corrected version of my question: Q1: I think it needs to be more clear that mDNS domain names (.local) can only be resolved by remote peers within the same local network. Section 5.1 does talk about this, and it may be an implicit assumption, but I think it should be pointed out in the beginning of the document. Q2: Related to Q1, think it needs to be more clear that the mechanism prevents IP address leaking to peers outside the local network. Inside the local network I assume that web apps can still find out about the local address simply by performing an mDNS lookup on the mDNS domain name. Q3: The draft makes an assumption that the mDNS domain names are unique. Why making that assumption? If the local network supports multicast, there may even be non-WebRTC applications using mDNS, which increases the risk for collision. Q4: Section 3.1.1 says that an ICE agent, when it gathers candidates, generates a UNIQUE mDNS domain name. I assume that means that the mDNS domain name will only be valid for the duration of the ICE session. Doesn't that mean that there is no need for other ICE agents to cache the mDNS domain name:IP address mapping for "future use", because the mDNS domain name won't be used in future anyway? Also, I am not sure whether ICE implementations should cache mappings to begin with. That's the task of the mDNS client of the host. Q5: Section 5.3 says: "When an endpoint that supports mDNS communicates with an endpoint that does not, the legacy endpoint will still provide its local IP addresses, and accordingly a direct connection can still be attempted, even though the legacy endpoint cannot resolve the mDNS names provided by the new endpoint." Please make it more clear that the legacy endpoint is the one that does not support mDNS. Something like: "When an endpoint that supports mDNS communicates with a legacy endpoint that does not, the..." Q6: If I remember correctly, people have raised issues with legacy parsers not being able to parse non-IP-addresses. If so, shouldn't that be mentioned in Section 5.3? (NOTE: Eventhough the draft updates RFC 8839, to support mDNS domain names, it does not solve the issue for legacy parsers.) Q7: The draft does not give any guidance regarding how long an ICE agent can safely cache an mDNS Regards, Christer

WebRTC applications collect ICE candidates as part of the process of creating peer-to-peer connections.  To maximize the probability of a  <ins> direct peer-to-peer connection, the endpoint's local IP addresses are included in this candidate collection.  However, these addresses are typically private and, as such, their disclosure has privacy implications.  This document describes a privacy-preserving way to share local IP addresses with other endpoints by concealing the addresses with dynamically generated Multicast DNS (mDNS) names. </ins> 1.  <ins> As detailed in IPHandling, exposing client local IP addresses by </ins> default to web applications maximizes the probability of successfully creating direct peer-to-peer connections between clients, but creates a significant surface for user fingerprinting.  IPHandling recognizes This document proposes an overall solution to this problem by extending ICESDP to allow ICE implementations to register ephemeral  <ins> mDNS RFC6762 names for local IP addresses, and then provide those names, rather than the IP addresses, in their ICE candidates.  While this technique is intended to benefit WebRTC implementations in web browsers, by preventing collection of private IP addresses by </ins> arbitrary web pages, it can also be used by any endpoint that wants to avoid disclosing information about its local network to remote peers on other networks. resolution internally and will not disclose the actual IP addresses to the application. <ins> While mDNS names are usually only valid within a local network, the same is true for private IP addresses, and therefore this does not limit the effectiveness of this technique. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",


is handled as described below. Check whether this IP address satisfies the ICE agent's policy <del> regarding whether an address is safe to expose.  If so, expose the candidate and abort this process. </del>  Check whether the ICE agent has previously generated, registered, and stored an mDNS hostname for this IP address as per steps 3 to IPv4 and IPv6 local addresses, provided that the application has configured both IPv4 and IPv6 STUN servers.  If the STUN response returns the same value as the local IP address, this indicates the <del> address is in fact public. Regardless of the result, a server-reflexive candidate will be generated; the transport address of this candidate is an IP address and therefore distinct from the hostname transport address of the associated mDNS candidate, and as such MUST NOT be considered redundant per the guidance in RFC8445, Section 5.1.3.  To avoid accidental IP address disclosure, this server-reflexive candidate MUST have its raddr field set to "0.0.0.0"/"::" and its rport field set to "9", as discussed in ICESDP, Section 9.1. Once an address has been identified as public, the ICE agent MAY cache this information and omit mDNS protection for that address in future ICE gathering phases. </del>  3.1.2.3.

Nils reviewed the document at URL There are a number of clarification points that could be made from the draft Makes sense to me. Right, I would tend to go with private IP addresses given RFC1918. We could refer to section 3.1.2.2 and refer to IP handling modes as well. We might want to further clarify that generating mDNS candidates ahead of time is an optimization. Makes sense to me. Hello, I was asked to review URL Here are my comment and questions: Abstract: “To maximize the probability of a direct peer-to-peer connection, client private IP addresses are included in this candidate collection.” I think it would make sense to replace “client” with ICE agent here, as client and server in the pure ICE context doesn’t make too much sense. I would suggest to change it to “..., private IP addresses of the ICE agent are included…”. In the abstract the terms “private IP addresses” and “local IP addresses” are used. I would suggest sticking to just one term for consistency. Section 1. “Introduction” has the same mix of local vs private in it. Section 3.1.1 point 1 I think it would be helpful if this draft at least offers the suggestion to replace all RFC1918 addresses, or put a reference to section 3.1.2.2 as a recommendation on how to determine which addresses to replace. Section 3.1.2.2 3rd paragraph “Regardless of results, …” confuses me. The last sentence in the paragraph before talks about the case of a public candidate. If I’m not mistaken in the case of a public address there shouldn’t be a server reflexive candidate generated. Section 3.1.2.2 4th paragraph While I agree that caching the result might be useful it can become dangerous in case the set of STUN servers changes. As the new STUN servers might return different results, cached results should be invalidated. Would it be worth adding a warning about this? Section 6.4 I’m confused by the diagram showing that both agents send over their mDNS candidates before having checked with the STUN server if the interface IP addresses need to be filtered or not. I understand that section 3.1.2.2 recommends to first wait for the STUN binding response from the STUN server before deciding which addresses should be filtered and which not. Why is this example showing it differently? Best regards Nils Ohlmeier

is handled as described below. Check whether this IP address satisfies the ICE agent's policy  <ins> regarding whether an address is safe to expose (typically, following the advice from address-privacy below).  If so, expose the candidate and abort this process. </ins> Check whether the ICE agent has previously generated, registered, and stored an mDNS hostname for this IP address as per steps 3 to IPv4 and IPv6 local addresses, provided that the application has configured both IPv4 and IPv6 STUN servers.  If the STUN response returns the same value as the local IP address, this indicates the  <ins> address is in fact public, although processing will continue as described below. Regardless of whether the address turns out to be public or private, a server-reflexive candidate will be generated; the transport address of this candidate will be an IP address and therefore distinct from the hostname transport address of the associated mDNS candidate, and as such MUST NOT be considered redundant per the guidance in RFC8445, Section 5.1.3.  To avoid accidental IP address disclosure, this server-reflexive candidate MUST have its raddr field set to "0.0.0.0"/"::" and its rport field set to "9", as discussed in ICESDP, Section 9.1. Because a new candidate is always generated by the STUN query, the ICE agent SHOULD initially provide mDNS-wrapped candidates to the application and then follow with server-reflexive candidates once they are obtained, unless it has a priori knowledge that a given address is public and does not require mDNS wrapping. To that end, once an address has been identified as public, the ICE agent MAY cache this information and skip mDNS protection for that address in future ICE gathering phases.  Note that if the set of STUN servers changes, any cached information SHOULD be discarded, as the new set may return different results. </ins> 3.1.2.3.


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 <del> dynamically generated Multicast DNS RFC6763 names. </del>  1. Replace the IP address of the ICE host candidate with the name with ".local" appended to it.  Expose the candidate.  2.2. For any remote host ICE candidate received by the ICE agent, the Otherwise, ignore the candidate. <del> Multicast DNS resolution might end up retrieving both an IPv4 and IPv6 address.  In that case, the IPv6 address may be used preferably to the IPv4 address. </del>  3.

Some additional comments may be needed in the prflx section?
NAME I went ahead and added a commit for my proposed changes. Let me know if the proposed changes are fine with you.
NAME Did you only commit the html changes? Can you include the markdown?
Oh, I probably messed up with the commit. I was expecting to commit only the markdown. I'll fix it.
It is conceivable that a server would implement ICE with mDNS candidates. There should be nothing in the ICE candidate processing that prevents this from working. Therefore we should call out what should happen when an mDNS query returns multiple IP addresses. E.g. use the 'best' on (where IPv6 is better than IPv4)?
This is a complex area. A simpler option could be that we mandate 1:1 for mDNS, and/or pick the first address of the expected type.
Mandating 1:1 for mDNS in the context of WebRTC is probably the straightforward approach. We should probably also define the behavior in the case of multiple responses, picking the first record makes sense to me. This requirement causes a potential issue when using MDNS for non default route though: it creates a fingerprinting vector by counting the number of different MDNS names for a given peer connection. I am not sure what reliable means we have to know the expected type of the address and whether this is a requirement at all. The easy solution would be to include this information in the MDNS name.
Good point about type not being known a priori, and we could put a hint in the name. Another option could be to resolve the name before forming pairs, take the first record found, and then only pair the resolved address with local candidates of the appropriate family.
Fixed by
LGTM with one comment

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  <ins> dynamically generated Multicast DNS RFC6762 names. </ins> 1. Replace the IP address of the ICE host candidate with the name with ".local" appended to it.  Expose the candidate. <ins> This procedure ensures that a mDNS name is used to replace only one IP address.  Specifically an ICE agent using an interface with both IPv4 and IPv6 addresses MUST expose a different mDNS name for each address. </ins> 2.2. For any remote host ICE candidate received by the ICE agent, the Otherwise, ignore the candidate.  <ins> An ICE agent may use a hostname resolver that transparently supports both Multicast and Unicast DNS.  In this case the resolution of a ".local" name may happen through Unicast DNS, see RFC6762 section 3. An ICE agent that supports mDNS candidates MUST support the situation where the hostname resolution results in more than one IP address. In this case, the ICE agent MUST take exactly one of the resolved IP addresses and ignore the others.  The ICE agent SHOULD, if available, use the first IPv6 address resolved, otherwise the first IPv4 address. </ins> 3.


3.1. <del> 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 follows: </del>  <del> Check whether the context ICE agent registered a name resolving to the ICE host candidate IP address. </del>  <del> If the ICE agent registered the name, replace the IP address of the ICE host candidate with the name with ".local" appended to it. Expose the candidate and abort these steps. </del>  <del> Generate a random unique name, typically a version 4 UUID as defined in RFC4122. </del>  <del> Register the unique name using Multicast DNS. </del>  <del> If registering of the unique name fails, abort these steps.  The </del>  candidate is not exposed. <del> Store the name and its related IP address in the ICE agent for future reuse. </del>  <del> Replace the IP address of the ICE host candidate with the name with ".local" appended to it.  Expose the candidate. </del>  3.2. following procedure is used: If the connection-address field value of the ICE candidate does <del> not finish by ".local", process the candidate as defined in RFC8445. </del>  <del> Otherwise, remove the ".local" suffix to the value and resolve it using Multicast DNS. </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 4.2. <del> 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.

NAME I tried to address your comments without splitting the procedure. Splitting the procedure makes a bit awkward to handle the error case and the mDNS registration is then only two steps really. Let me know what you think.
We found Microsoft recommended using “.local.” as a pseudo-TLD for small private networks with internal DNS servers (here is an article that is still accessible, URL(v=ws.10), and the Wiki page URL covers some legacy recommendations made by Microsoft, though some I think have been removed). We also note that Apple provided guidance on how to configure OS X to look up “.local” hostnames using both mDNS and DNS (URL, I am not sure if this is still the case for newer OS X). Hostnames containing only one level (label) in addition to “.local” are resolved using mDNS by default. Names containing two or more labels in addition to local will be resolved using DNS by default. For this reason, our current implementation only generates names containing one additional label (also recommended by RFC 6762 I think). I understand this section is more about the principle, but I am wondering how we/or if we should define failure here. Since we use the random UUID for hostnames, name conflicts are likely avoided with minimum retries.
I agree the exposed unique name should end with '.local' which is what step 7 is doing. It is fine to append '.local' in step 4 if that makes things clearer. As of 5, if registering the unique name fails to name conflicts, the issue is that we might detect that conflict after exposing the candidate. An implementation is probably free to decide to wait so as to ensure that there is no name conflict but there is no such guarantee.
NAME do you think we should have a stronger statement about UUIDs requirements. Would something like the following fix the first part of the issue: Step 3 of section 3.1: Generate a random unique name. The unique name SHOULD be a version 4 UUID as defined in [RFC4122].
As of the second issue about the error case, there might be cases where there will be an error case right away. Maybe no interface with simulcast support for instance.
The "should"-level requirement of "URL" sounds good to me. Do you think if it would be helpful to also refer to Section 3 in RFC6762? The second last paragraph there has a related discussion, and the above requirement conforms to that.
The blocking issue in the security consideration section may also be an example of failure here. I feel we may need to clarify the handling of failure (with limit of retries, for example).
This LGTM with the changes noted below.

3.1.  <ins> 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: </ins>  <ins> Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE host candidate's IP address.  If one exists, skip ahead to Step 6. </ins>  <ins> 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. </ins>  <ins> Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local". </ins>  <ins> Register the candidate's mDNS hostname using Multicast DNS. </ins>  <ins> If registering of the mDNS hostname fails, abort these steps.  The </ins> candidate is not exposed.  <ins> Store the mDNS hostname and its related IP address in the ICE agent for future reuse. </ins>  <ins> Replace the IP address of the ICE host candidate with its mDNS hostname.  Expose the candidate. 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 doing so, only steps 1 and 2 of the above procedure will be executed at the time of gathering candidates. An implementation may also detect that mDNS is not supported by the available network interfaces.  The ICE agent may skip step 3 and 4 and directly decide to not expose the host candidate. </ins> 3.2. following procedure is used: If the connection-address field value of the ICE candidate does  <ins> not end with ".local" or if the value contains more than one ".", then process the candidate as defined in RFC8445. </ins>  <ins> Otherwise, use the value and resolve it using Multicast DNS. </ins> If it resolves to an IP address, replace the value of the ICE host candidate by the resolved IP address and continue processing of 4.2.  <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 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. </ins> 4.3.


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>  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>  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>  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>  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>  <del> 4.1. </del>  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>  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>  <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>  <del> A third-party browser execution context, i.e. a context that is not same origin as the top level execution context. </del>  <del> A private browsing execution context. 5. </del>  The proposal relies on identifying and resolving any Multicast DNS based ICE candidates as part of adding/processing a remote candidate.

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

Abstract  <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.  <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.  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.  <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.  <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.  <ins> 3. </ins>  <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.  <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.  <ins> 3.3. </ins>  <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>  <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>  <ins> 4. </ins> The proposal relies on identifying and resolving any Multicast DNS based ICE candidates as part of adding/processing a remote candidate.


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 <del> dynamically generated Multicast DNS RFC6762 names. </del>  1. not be supported. This document proposes an overall solution to this problem by <del> 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. </del>  2. Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local". <del> Register the candidate's mDNS hostname using Multicast DNS. </del>  If registering of the mDNS hostname fails, abort these steps.  The candidate is not exposed. not end with ".local" or if the value contains more than one ".", then process the candidate as defined in RFC8445. <del> Otherwise, use the value and resolve it using Multicast DNS. </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 latency is close to zero, the probability is high that the two peers are running on the same device. <del> To avoid this issue, browsers SHOULD NOT register Multicast DNS names for WebRTC applications running in a third-party browser execution </del>  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 Multicast DNS based ICE candidates as part of adding/processing a remote candidate. ICESDP section 4.1 could be updated to explicitly allow Multicast DNS names in the connection-address field. </del>  <del> The proposal relies on adding the ability to register Multicast DNS names at ICE gathering time.  This could be described in ICESDP and/ or WebRTCSpec. </del>  The proposal allows updating IPHandling so that mode 2 is not the mode used by default when user consent is not required.  Instead, the <del> default mode could be defined as mode 3 with Multicast DNS based ICE </del>  candidates.

Or alternatively consistently use mDNS, but mention in the intro that this refers to Multicast DNS {{RFC6762}}
Yeah, I think we should do the latter. That's what 6762 does.

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  <ins> dynamically generated Multicast DNS (mDNS) RFC6762 names. </ins> 1. not be supported. This document proposes an overall solution to this problem by  <ins> registering ephemeral mDNS 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. Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local".  <ins> Register the candidate's mDNS hostname as defined in RFC6762. </ins> If registering of the mDNS hostname fails, abort these steps.  The candidate is not exposed. not end with ".local" or if the value contains more than one ".", then process the candidate as defined in RFC8445.  <ins> Otherwise, resolve the candidate using mDNS. </ins> If it resolves to an IP address, replace the value of the ICE host candidate by the resolved IP address and continue processing of latency is close to zero, the probability is high that the two peers are running on the same device.  <ins> To avoid this issue, browsers SHOULD NOT register mDNS names for WebRTC applications running in a third-party browser execution </ins> context (i.e., a context that has a different origin than the top- level execution context), or a private browser execution context. 4.  <ins> The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP section 4.1 could be updated to explicitly allow mDNS names in the connection-address field. </ins>  <ins> The proposal relies on adding the ability to register mDNS names at ICE gathering time.  This could be described in ICESDP and/or WebRTCSpec. </ins> The proposal allows updating IPHandling so that mode 2 is not the mode used by default when user consent is not required.  Instead, the  <ins> default mode could be defined as mode 3 with mDNS-based ICE </ins> candidates.


2.1. For any host candidate gathered by an ICE agent as part of RFC8445 <del> section 5.1.1, obfuscation of the candidate is done as follows: </del>  Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE host candidate's IP address.  If one exists, skip ahead to Step 6. <del> 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". agent for future reuse. Replace the IP address of the ICE host candidate with its mDNS <del> 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. This procedure ensures that a mDNS name is used to replace only one <del> 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. 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>  3.3.

Fingerprinting question will be tracked in a new issue.
Merging this one with Jeroen's approval.
LGTM

2.1. For any host candidate gathered by an ICE agent as part of RFC8445  <ins> section 5.1.1, the candidate is processed as follows: </ins> Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE host candidate's IP address.  If one exists, skip ahead to Step 6.  Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local". agent for future reuse. Replace the IP address of the ICE host candidate with its mDNS  <ins> hostname, and expose the candidate as usual. </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. This procedure ensures that a mDNS name is used to replace only one  <ins> 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. 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> 3.3.


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

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.

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


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 <del> same address as a remote mDNS ICE candidate whose name is in the process of being resolved.  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. </del>  When there is no user consent, the following filtering should be done to prevent private IP address leakage: learned through other means, e.g., receiving it in a separate server-reflexive remote candidate. <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 designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and SHOULD have the lifetime of the page. <del> 3.3. </del>  As noted in IPHandling, privacy may be breached if a web application running in two browsing contexts can determine whether it is running a context that has a different origin than the top-level browsing context), or a private browsing context. <del> 4. </del>  <del> 4.1. </del>  The implementation of this proposal requires the mDNS querying capability of the browser for registering mDNS names or adding remote queries, announcement responses, resolution queries, and goodbye responses associated with mDNS. <del> 4.2. </del>  If the optional probing queries are implemented for the name registration, a malicious endpoint in the local network, which is generic threat, and requires dedicated protocol suites to mitigate, which is beyond the scope of this proposal. <del> 4.3. </del>  A malicious endpoint in the local network may also record other endpoints who are registering, unregistering, and resolving mDNS As above, mitigation of this threat is beyond the scope of this proposal. <del> 5. </del>  The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP

PR of
Added a 'good' example as well, and put them all in an examples section. PTAL.
Will merge once I get a second approval.
Some of this stuff is complicated, example diagrams can help.
Great to have examples. Regenerating the html, the examples do not show up in full on the html version, probably not a big deal, the txt version is fine.
LGTM

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  <ins> same address as a remote mDNS candidate that is in the process of being signaled or 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. </ins> 3.  <ins> In this example, mDNS candidates are exchanged between peers and resolved to obtain the corresponding IP addresses. The following two examples indicate how peer-reflexive candidates for host IP addresses can be created due to timing differences. In this example, a peer-reflexive candidate is generated because the mDNS candidate is signaled after the STUN checks begin. 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. 4. 4.1. </ins> When there is no user consent, the following filtering should be done to prevent private IP address leakage: learned through other means, e.g., receiving it in a separate server-reflexive remote candidate.  <ins> 4.2. </ins> It is important that use of registered mDNS hostnames is limited in time and/or scope.  Indefinitely reusing the same mDNS hostname designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and SHOULD have the lifetime of the page.  <ins> 4.3. </ins> As noted in IPHandling, privacy may be breached if a web application running in two browsing contexts can determine whether it is running a context that has a different origin than the top-level browsing context), or a private browsing context.  <ins> 5. </ins>  <ins> 5.1. </ins> The implementation of this proposal requires the mDNS querying capability of the browser for registering mDNS names or adding remote queries, announcement responses, resolution queries, and goodbye responses associated with mDNS.  <ins> 5.2. </ins> If the optional probing queries are implemented for the name registration, a malicious endpoint in the local network, which is generic threat, and requires dedicated protocol suites to mitigate, which is beyond the scope of this proposal.  <ins> 5.3. </ins> A malicious endpoint in the local network may also record other endpoints who are registering, unregistering, and resolving mDNS As above, mitigation of this threat is beyond the scope of this proposal.  <ins> 6. </ins> The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP


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. 3.3. 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. </del>  4. the addition of remote ICE host candidates with mDNS names generates mDNS queries for names of each candidate; <del> the removal of names could happen when the execution 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). </del>  A malicious Web application could flood the local network with mDNS messages by: <del> creating execution contexts that create ICE agents and start </del>  gathering of local ICE host candidates; destroying these local candidates soon after the name registration

PR of
Anyone else want to take a look?
(browser) execution context -> browsing context
It was suggested to replace the name by "browsing context " in the PR of the security consideration. Execution or browser execution context is consistently used in the new commits, and I will create a PR for this if we decide to change the name.

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. 3.3. 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. </ins> 4. the addition of remote ICE host candidates with mDNS names generates mDNS queries for names of each candidate;  <ins> 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). </ins> A malicious Web application could flood the local network with mDNS messages by:  <ins> creating browsing contexts that create ICE agents and start </ins> gathering of local ICE host candidates; destroying these local candidates soon after the name registration


4.2.  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 designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and SHOULD have the lifetime of the page. <del> 4.3. </del>  As noted in IPHandling, privacy may be breached if a web application running in two browsing contexts can determine whether it is running

LGTM too, will resolve conflicts
If we resolve a name N1 to 1.1.1.1, should we pair it with relay candidates? If we do so, 1.1.1.1 will be sent to the TURN server, which seems like a leak (could be under the control of the web app). Probably need to add a section in the privacy considerations saying any remote mdns candidates MUST NOT be paired with local relay candidates (although the reverse should be OK).
I am thinking about the impact on the connectivity, and if we can ever resolve the remote mdns candidate, the chance of selecting relaymdns even if this is allowed could probably be low if the local side also gathers a host candidate. The MUST level lgtm.
yeah, and keep in mind that usually these host IPs will be things like 192.168.1.3 that are not even reachable by the outside world.
Well thought! Agreed, I always thought TURN and STUN were intertwined (TURN server is probably also a STUN server or at least hosted in the same network) so that we can use server reflexive candidates for TURN without losing much.
yeah - we already throw away private IPs for TURN to avoid creating connections that won't work, so the actual impact here is negligible.
LGTM

4.2. <ins> 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. </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 designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and SHOULD have the lifetime of the page.  <ins> 4.4. </ins> As noted in IPHandling, privacy may be breached if a web application running in two browsing contexts can determine whether it is running


4.3. <del> 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. </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 designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and SHOULD have the lifetime of the page. <del> 4.5. </del>  As noted in IPHandling, privacy may be breached if a web application running in two browsing contexts can determine whether it is running

PR of
I will upload a PR for this.
OK, bad merge, thanks for catching
Fixed by
E.g. "Step 5 in Section {{gathering}}" in .md becomes "Step 5 in Section Section 2.1" in .html or "Step 5 in Section Section 2.1" in the raw html source.
Was this fixed?
No, it looks to me an issue with the generator code. Or, can I fix it inline? I was assuming the html would be auto-generated, but if it is supposed to just upload a copy, I will fix it inline asap.
I was wrong. This issue is gone in the newly generated HTML (from the "here" link), but we probably need to regenerate it after merging PR
OK, will do as part of the upload
Resolved in latest HTML.

4.3.  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 designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and SHOULD have the lifetime of the page.  <ins> 4.4. </ins> As noted in IPHandling, privacy may be breached if a web application running in two browsing contexts can determine whether it is running