Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: Followup from , as discussed today 
 Will wait for LGTM from before merging . 
 Rethought my approach here and rewrote the section accordingly . PTAL . 
 LGTM 
 Sorry for the delay .  did not let me see any diffs over the weekend .
Paragraph (version B):
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.
Paragraph (version B):
Replace the IP address of the ICE candidate with its mDNS hostname
and provide the candidate to the web application.
Paragraph (version B):
This procedure ensures that an 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.
Paragraph (version B):
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.
Paragraph (version B):
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).
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
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 as noted in RFC6762,
Section 3.
Paragraph (version A):
host ICE candidates with an IP address are not exposed as ICE
candidate events.
Paragraph (version A):
Server reflexive ICE candidate raddr field is set to 0.0.0.0 and
rport to 0.
Paragraph (version A):
SDP does not expose any a=candidate line corresponding to a host
ICE candidate which contains an IP address.
Paragraph (version B):
In this example, a peer-reflexive candidate is generated because the
mDNS candidate is signaled after the STUN checks begin.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
As noted in IPHandling, privacy may be breached if a web application
running in two browsing 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.
Paragraph (version B):
To avoid this issue, browsers SHOULD NOT register mDNS names for
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.
Paragraph (version B):
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,
Paragraph (version B):
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).
Paragraph (version B):
adding fictitious remote ICE host candidates with mDNS names.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.