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

Discussion:
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.