draft-ietf-rtcweb-mdns-ice-candidates-01.txt		draft-ietf-rtcweb-mdns-ice-candidates-02.txt
	RTCWEB Y. Fablet		RTCWEB Y. Fablet
	Internet-Draft Apple Inc.		Internet-Draft Apple Inc.
	Intended status: Informational J. de Borst		Intended status: Informational J. de Borst
	Expires: April 25, 2019 J. Uberti		Expires: April 25, 2019 J. Uberti
	Q. Wang		Q. Wang
	Google		Google
	October 22, 2018		October 22, 2018
	Using Multicast DNS to protect privacy when exposing ICE candidates		Using Multicast DNS to protect privacy when exposing ICE candidates
	draft-ietf-rtcweb-mdns-ice-candidates-01		draft-ietf-rtcweb-mdns-ice-candidates-02
	Abstract		Abstract
	WebRTC applications collect ICE candidates as part of the process of		WebRTC applications collect ICE candidates as part of the process of
	creating peer-to-peer connections. To maximize the probability of a		creating peer-to-peer connections. To maximize the probability of a
	direct peer-to-peer connection, client private IP addresses are		direct peer-to-peer connection, client private IP addresses are
	included in this candidate collection. However, disclosure of these		included in this candidate collection. However, disclosure of these
	addresses has privacy implications. This document describes a way to		addresses has privacy implications. This document describes a way to
	share local IP addresses with other clients while preserving client		share local IP addresses with other clients while preserving client
	privacy. This is achieved by obfuscating IP addresses with		privacy. This is achieved by obfuscating IP addresses with
	skipping to change at page 2, line 14 ¶		skipping to change at page 2, line 14 ¶
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Principle . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. ICE Candidate Gathering . . . . . . . . . . . . . . . . . 3		3. Principle . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.2. ICE Candidate Processing . . . . . . . . . . . . . . . . 4		3.1. ICE Candidate Gathering . . . . . . . . . . . . . . . . . 3
	2.2.1. Handling of Peer-Reflexive Remote Candidate . . . . . 4		3.2. ICE Candidate Processing . . . . . . . . . . . . . . . . 4
	3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Privacy Guidelines . . . . . . . . . . . . . . . . . . . . . 6		5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
	4.1. APIs Leaking IP Addresses . . . . . . . . . . . . . . . . 6		5.1. Statistics . . . . . . . . . . . . . . . . . . . . . . . 6
	4.2. Interactions With TURN Servers . . . . . . . . . . . . . 6		5.2. Interactions With TURN Servers . . . . . . . . . . . . . 6
	4.3. Generated Names Reuse . . . . . . . . . . . . . . . . . . 7		5.3. Generated Names Reuse . . . . . . . . . . . . . . . . . . 7
	4.4. Specific Browsing Contexts . . . . . . . . . . . . . . . 7		5.4. Specific Browsing Contexts . . . . . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	5.1. mDNS Message Flooding . . . . . . . . . . . . . . . . . . 7		6.1. mDNS Message Flooding . . . . . . . . . . . . . . . . . . 7
	5.2. Malicious Responses to Deny Name Registration . . . . . . 8		6.2. Malicious Responses to Deny Name Registration . . . . . . 8
	5.3. Monitoring of Sessions . . . . . . . . . . . . . . . . . 9		6.3. Monitoring of Sessions . . . . . . . . . . . . . . . . . 9
	6. Specification Requirements . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	7. Informative References . . . . . . . . . . . . . . . . . . . 9		8. Specification Requirements . . . . . . . . . . . . . . . . . 9
			9. Informative References . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	As detailed in [IPHandling], exposing client private IP addresses by		As detailed in [IPHandling], exposing client private IP addresses by
	default maximizes the probability of successfully creating direct		default maximizes the probability of successfully creating direct
	peer-to-peer connection between two clients, but creates a		peer-to-peer connection between two clients, but creates a
	significant surface for user fingerprinting. [IPHandling] recognizes		significant surface for user fingerprinting. [IPHandling] recognizes
	this issue, but also admits that there is no current solution to this		this issue, but also admits that there is no current solution to this
	problem; implementations that choose to use Mode 3 to address the		problem; implementations that choose to use Mode 3 to address the
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 7 ¶
	not be supported.		not be supported.
	This document proposes an overall solution to this problem by		This document proposes an overall solution to this problem by
	registering ephemeral mDNS names for each local private IP address,		registering ephemeral mDNS names for each local private IP address,
	and then providing those names, rather than the IP addresses, to the		and then providing those names, rather than the IP addresses, to the
	web application when it gathers ICE candidates. WebRTC		web application when it gathers ICE candidates. WebRTC
	implementations resolve these names to IP addresses and perform ICE		implementations resolve these names to IP addresses and perform ICE
	processing as usual, but the actual IP addresses are not exposed to		processing as usual, but the actual IP addresses are not exposed to
	the web application.		the web application.
	2. Principle		2. Terminology
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
			3. Principle
	This section uses the concept of ICE agent as defined in [RFC8445].		This section uses the concept of ICE agent as defined in [RFC8445].
	In the remainder of the document, it is assumed that each browsing		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		context (as defined in Section 7.1 of [HTMLSpec]) has its own ICE
	agent.		agent.
	2.1. ICE Candidate Gathering		3.1. ICE Candidate Gathering
	For any host candidate gathered by an ICE agent as part of [RFC8445]		For any host candidate gathered by an ICE agent as part of [RFC8445],
	section 5.1.1, the candidate is processed as follows:		Section 5.1.1, the candidate is handled as follows:
	1. Check whether the ICE agent has a usable registered mDNS hostname		1. Check whether the ICE agent has a usable registered mDNS hostname
	resolving to the ICE candidate's IP address. If one exists, skip		resolving to the ICE candidate's IP address. If one exists, skip
	ahead to Step 6.		ahead to Step 6.
	2. Generate a unique mDNS hostname. The unique name MUST consist of		2. Generate a unique mDNS hostname. The unique name MUST consist of
	a version 4 UUID as defined in [RFC4122], followed by ".local".		a version 4 UUID as defined in [RFC4122], followed by ".local".
	3. Register the candidate's mDNS hostname as defined in [RFC6762].		3. Register the candidate's mDNS hostname as defined in [RFC6762].
	4. If registering of the mDNS hostname fails, abort these steps.		4. If registering of the mDNS hostname fails, abort these steps.
	The candidate is not exposed.		The candidate is not exposed.
	5. Store the mDNS hostname and its related IP address in the ICE		5. Store the mDNS hostname and its related IP address in the ICE
	agent for future reuse.		agent for future reuse.
	6. Replace the IP address of the ICE candidate with its mDNS		6. Replace the IP address of the ICE candidate with its mDNS
	hostname, and expose the candidate as usual.		hostname and provide the candidate to the web application.
	An ICE agent can implement this procedure in any way so long as it		An ICE agent can implement this procedure in any way so long as it
	produces equivalent results to this procedure.		produces equivalent results to this procedure.
	An implementation may for instance pre-register mDNS hostnames by		An implementation may for instance pre-register mDNS hostnames by
	executing steps 3 to 5 and prepopulate an ICE agent accordingly. 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		doing so, only step 6 of the above procedure will be executed at the
	time of gathering candidates.		time of gathering candidates.
	An implementation may also detect that mDNS is not supported by the		An implementation may also detect that mDNS is not supported by the
	available network interfaces. The ICE agent may skip steps 2 and 3		available network interfaces. The ICE agent may skip steps 2 and 3
	and directly decide to not expose the host candidate.		and directly decide to not expose the host candidate.
	This procedure ensures that a mDNS name is used to replace only one		This procedure ensures that an mDNS name is used to replace only one
	IP address. Specifically, an ICE agent using an interface with both		IP address. Specifically, an ICE agent using an interface with both
	IPv4 and IPv6 addresses MUST expose a different mDNS name for each		IPv4 and IPv6 addresses MUST expose a different mDNS name for each
	address.		address.
	2.2. ICE Candidate Processing		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).
			3.2. ICE Candidate Processing
	For any remote ICE candidate received by the ICE agent, the following		For any remote ICE candidate received by the ICE agent, the following
	procedure is used:		procedure is used:
	1. If the connection-address field value of the ICE candidate does		1. If the connection-address field value of the ICE candidate does
	not end with ".local" or if the value contains more than one ".",		not end with ".local" or if the value contains more than one ".",
	then process the candidate as defined in [RFC8445].		then process the candidate as defined in [RFC8445].
	2. Otherwise, resolve the candidate using mDNS.		2. Otherwise, resolve the candidate using mDNS.
	3. If it resolves to an IP address, replace the mDNS hostname of the		3. If it resolves to an IP address, replace the mDNS hostname of the
	ICE candidate with the resolved IP address and continue		ICE candidate with the resolved IP address and continue
	processing of the candidate.		processing of the candidate.
	4. Otherwise, ignore the candidate.		4. Otherwise, ignore the candidate.
	An ICE agent may use a hostname resolver that transparently supports		An ICE agent may use a hostname resolver that transparently supports
	both Multicast and Unicast DNS. In this case the resolution of a		both Multicast and Unicast DNS. In this case the resolution of a
	".local" name may happen through Unicast DNS, see [RFC6762] section		".local" name may happen through Unicast DNS as noted in [RFC6762],
	3.		Section 3.
	An ICE agent that supports mDNS candidates MUST support the situation		An ICE agent that supports mDNS candidates MUST support the situation
	where the hostname resolution results in more than one IP address.		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		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,		addresses and ignore the others. The ICE agent SHOULD, if available,
	use the first IPv6 address resolved, otherwise the first IPv4		use the first IPv6 address resolved, otherwise the first IPv4
	address.		address.
	2.2.1. Handling of Peer-Reflexive Remote Candidate		4. Examples
	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 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 4.
	3. Examples
	In this example, mDNS candidates are exchanged between peers and		In this example, mDNS candidates are exchanged between peers and
	resolved to obtain the corresponding IP addresses.		resolved to obtain the corresponding IP addresses.
	ICE Agent 1 (1.1.1.1) ICE Agent 2 (2.2.2.2)		ICE Agent 1 (1.1.1.1) ICE Agent 2 (2.2.2.2)
	<Register | |		<Register | |
	mDNS name N1 | |		mDNS name N1 | |
	for 1.1.1.1> | |		for 1.1.1.1> | |
	|----------- mDNS Candidate N1 ---------->|		|------- mDNS Candidate N1 ------>|
	| | <Register		| | <Register
	| | mDNS name N2		| | mDNS name N2
	| | for 2.2.2.2>		| | for 2.2.2.2>
	|<---------- mDNS Candidate N2 -----------|		|<------ mDNS Candidate N2 -------|
	<Resolve | | <Resolve		<Resolve | | <Resolve
	mDNS name N2> | | mDNS name N1>		mDNS name N2> | | mDNS name N1>
	|<======== STUN check to 1.1.1.1 =========|		|<==== STUN check to 1.1.1.1 =====|
	|========= STUN check to 2.2.2.2 ========>|		|===== STUN check to 2.2.2.2 ====>|
	| |		| |
	The following two examples indicate how peer-reflexive candidates for		The following two examples indicate how peer-reflexive candidates for
	host IP addresses can be created due to timing differences.		host IP addresses can be created due to timing differences.
	In this example, a peer-reflexive candidate is generated because the		In this example, a peer-reflexive candidate is generated because the
	mDNS candidate is signaled after the STUN checks begin.		mDNS candidate is signaled after the STUN checks begin.
	ICE Agent 1 (1.1.1.1) ICE Agent 2 (2.2.2.2)		ICE Agent 1 (1.1.1.1) ICE Agent 2 (2.2.2.2)
	<Register | |		<Register | |
	mDNS name N1 | |		mDNS name N1 | |
	for 1.1.1.1> | |		for 1.1.1.1> | |
	|----------- mDNS Candidate N1 ---------->|		|------- mDNS Candidate N1 ------>|
	| | <Resolve		| | <Resolve
	| | mDNS name N1>		| | mDNS name N1>
	|<======== STUN check to 1.1.1.1 =========|		|<==== STUN check to 1.1.1.1 =====|
	prflx candidate | | <Register		prflx candidate | | <Register
	2.2.2.2 created | | mDNS name N2		2.2.2.2 created | | mDNS name N2
	| | for 2.2.2.2>		| | for 2.2.2.2>
	|<---------- mDNS Candidate N2 -----------|		|<------ mDNS Candidate N2 -------|
	| |		| |
	In this example, a peer-reflexive candidate is generated because the		In this example, a peer-reflexive candidate is generated because the
	mDNS resolution for name N2 does not complete until after the STUN		mDNS resolution for name N2 does not complete until after the STUN
	checks are received.		checks are received.
	ICE Agent 1 (1.1.1.1) ICE Agent 2 (2.2.2.2)		ICE Agent 1 (1.1.1.1) ICE Agent 2 (2.2.2.2)
	<Register | | <Register		<Register | | <Register
	mDNS name N1 | | mDNS name N2		mDNS name N1 | | mDNS name N2
	for 1.1.1.1> | | for 2.2.2.2>		for 1.1.1.1> | | for 2.2.2.2>
	|----------- mDNS Candidate N1 ---------->|		|------- mDNS Candidate N1 ------>|
	|<---------- mDNS Candidate N2 -----------|		|<------ mDNS Candidate N2 -------|
	<Resolve | | <Resolve		<Resolve | | <Resolve
	... | | mDNS name N1>		... | | mDNS name N1>
	mDNS |<======== STUN check to 1.1.1.1 =========|		mDNS |<==== STUN check to 1.1.1.1 =====|
	... prflx candidate | |		... prflx candidate | |
	name 2.2.2.2 created | |		name 2.2.2.2 created | |
	... | |		... | |
	N2> | |		N2> | |
	4. Privacy Guidelines
	4.1. APIs Leaking IP Addresses		5. Privacy Considerations
	When there is no user consent, the following filtering should be done		The goal of this mechanism is to keep knowledge of private host IP
	to prevent private IP address leakage:		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.
	1. ICE candidates with an IP address are not exposed as ICE		5.1. Statistics
	candidate events.
	2. Server reflexive ICE candidate raddr field is set to 0.0.0.0 and		Statistics related to ICE candidates that are accessible to the web
	rport to 0.		application MUST NOT contain the IP address of a local or remote mDNS
			candidate; the mDNS name SHOULD be used instead.
	3. SDP does not expose any a=candidate line corresponding to an ICE		In addition, a peer-reflexive remote candidate may be constructed
	candidate which contains an IP address.		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.
	4. Statistics related to ICE candidates MUST NOT contain the		To prevent disclosure of the host IP address to the application in
	resolved IP address of a remote mDNS candidate or the IP address		this scenario, statistics related to ICE candidates MUST NOT contain
	of a peer-reflexive candidate, unless that IP address has already		the IP address of any peer-reflexive candidate, unless that IP has
	been learned through other means, e.g., receiving it in a		already been learned through signaling of a candidate with the same
	separate server-reflexive remote candidate.		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. Interactions With TURN Servers		5.2. Interactions With TURN Servers
	When sending data to a TURN [RFC5766] server, the sending client		When sending data to a TURN [RFC5766] server, the sending client
	tells the server the destination IP and port for the data. This		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		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		by mDNS resolution, the TURN server will learn the underlying host IP
	and port, and this information can then be relayed to the web		and port, and this information can then be relayed to the web
	application, defeating the value of the mDNS wrapping.		application, defeating the value of the mDNS wrapping.
	To prevent disclosure of the host IP address to a TURN server, the		To prevent disclosure of the host IP address to a TURN server, the
	ICE agent MUST NOT form candidate pairs between its own relay		ICE agent MUST NOT form candidate pairs between its own relay
	candidates and remote mDNS candidates. Note that the converse is not		candidates and remote mDNS candidates. Note that the converse is not
	an issue; the ICE agent MAY form candidate pairs between its own mDNS		an issue; the ICE agent MAY form candidate pairs between its own mDNS
	candidates and remote relay candidates, as in this situation host IPs		candidates and remote relay candidates, as in this situation host IPs
	will not be sent directly to the TURN server.		will not be sent directly to the TURN server.
	This restriction has no effect on connectivity; in the cases where		This restriction has no effect on connectivity; in the cases where
	host IP addresses are private and need to be wrapped with mDNS names,		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,		they will be unreachable from the TURN server, and as noted above,
	the reverse path will continue to work normally.		the reverse path will continue to work normally.
	4.3. Generated Names Reuse		5.3. Generated Names Reuse
	It is important that use of registered mDNS hostnames is limited in		It is important that use of registered mDNS hostnames is limited in
	time and/or scope. Indefinitely reusing the same mDNS hostname		time and/or scope. Indefinitely reusing the same mDNS hostname
	candidate would provide applications an even more reliable tracking		candidate would provide applications an even more reliable tracking
	mechanism than the private IP addresses that this specification is		mechanism than the private IP addresses that this specification is
	designed to hide. The use of registered mDNS hostnames SHOULD be		designed to hide. The use of registered mDNS hostnames SHOULD be
	scoped by origin, and SHOULD have the lifetime of the page.		scoped by origin, and SHOULD have the lifetime of the page.
	4.4. Specific Browsing Contexts		5.4. Specific Browsing Contexts
	As noted in [IPHandling], privacy may be breached if a web		As noted in [IPHandling], privacy may be breached if a web
	application running in two browsing contexts can determine whether it		application running in two browsing contexts can determine whether it
	is running on the same device. While the approach in this document		is running on the same device. While the approach in this document
	prevents the application from directly comparing local private IP		prevents the application from directly comparing local private IP
	addresses, a successful local WebRTC connection can also present a		addresses, a successful local WebRTC connection can also present a
	threat to user privacy. Specifically, when the latency of a WebRTC		threat to user privacy. Specifically, when the latency of a WebRTC
	connection latency is close to zero, the probability is high that the		connection latency is close to zero, the probability is high that the
	two peers are running on the same device.		two peers are running on the same device.
	To avoid this issue, browsers SHOULD NOT register mDNS names for		To avoid this issue, browsers SHOULD NOT register mDNS names for
	WebRTC applications running in a third-party browsing context (i.e.,		WebRTC applications running in a third-party browsing context (i.e.,
	a context that has a different origin than the top-level browsing		a context that has a different origin than the top-level browsing
	context), or a private browsing context.		context), or a private browsing context.
	5. Security Considerations		6. Security Considerations
	5.1. mDNS Message Flooding		6.1. mDNS Message Flooding
	The implementation of this proposal requires the mDNS querying		The implementation of this proposal requires the mDNS querying
	capability of the browser for registering mDNS names or adding remote		capability of the browser for registering mDNS names or adding remote
	ICE host candidates with such names. It also requires the mDNS		ICE host candidates with such names. It also requires the mDNS
	responding capability of either the browser or the operating platform		responding capability of either the browser or the operating platform
	of the browser for registering, removing or resolving mDNS names. In		of the browser for registering, removing or resolving mDNS names. In
	particular,		particular,
	o the registration of name requires optional probing queries and		o the registration of name requires optional probing queries and
	mandatory announcing responses ([RFC6762], Section 8), and this is		mandatory announcing responses ([RFC6762], Section 8), and this is
	skipping to change at page 8, line 34 ¶		skipping to change at page 8, line 41 ¶
	[RFC6762] defines a per-record multicast rate limiting rule, in which		[RFC6762] defines a per-record multicast rate limiting rule, in which
	a given record on a given interface cannot be sent less than one		a given record on a given interface cannot be sent less than one
	second since its last transmission. This rate limiting rule however		second since its last transmission. This rate limiting rule however
	does not mitigate the above attacks, in which new names, hence new		does not mitigate the above attacks, in which new names, hence new
	records, are constantly created and sent. A browser-wide mDNS		records, are constantly created and sent. A browser-wide mDNS
	message rate limit MUST be provided for all messages that can be		message rate limit MUST be provided for all messages that can be
	indirectly dispatched by a web application, namely the probing		indirectly dispatched by a web application, namely the probing
	queries, announcement responses, resolution queries, and goodbye		queries, announcement responses, resolution queries, and goodbye
	responses associated with mDNS.		responses associated with mDNS.
	5.2. Malicious Responses to Deny Name Registration		6.2. Malicious Responses to Deny Name Registration
	If the optional probing queries are implemented for the name		If the optional probing queries are implemented for the name
	registration, a malicious endpoint in the local network, which is		registration, a malicious endpoint in the local network, which is
	capable of responding mDNS queries, could send responses to block the		capable of responding mDNS queries, could send responses to block the
	use of the generated names. This would lead to the discarding of		use of the generated names. This would lead to the discarding of
	this ICE host candidate as in Step 5 in Section 2.1.		this ICE host candidate as in Step 5 in Section 3.1.
	The above attack can be mitigated by skipping the probing when		The above attack can be mitigated by skipping the probing when
	registering a name, which also conforms to Section 8 in [RFC6762],		registering a name, which also conforms to Section 8 in [RFC6762],
	given that the name is randomly generated for the probabilistic		given that the name is randomly generated for the probabilistic
	uniqueness (e.g. a version 4 UUID) in Step 3 in Section 2.1.		uniqueness (e.g. a version 4 UUID) in Step 3 in Section 3.1.
	However, a similar attack can be performed by exploiting the negative		However, a similar attack can be performed by exploiting the negative
	responses (defined in [RFC6762], Section 8.1), in which NSEC resource		responses (defined in [RFC6762], Section 8.1), in which NSEC resource
	records are sent to claim the nonexistence of records related to the		records are sent to claim the nonexistence of records related to the
	gathered ICE host candidates.		gathered ICE host candidates.
	The existence of malicious endpoints in the local network poses a		The existence of malicious endpoints in the local network poses a
	generic threat, and requires dedicated protocol suites to mitigate,		generic threat, and requires dedicated protocol suites to mitigate,
	which is beyond the scope of this proposal.		which is beyond the scope of this proposal.
	5.3. Monitoring of Sessions		6.3. Monitoring of Sessions
	A malicious endpoint in the local network may also record other		A malicious endpoint in the local network may also record other
	endpoints who are registering, unregistering, and resolving mDNS		endpoints who are registering, unregistering, and resolving mDNS
	names. By doing so, they can create a session log that shows which		names. By doing so, they can create a session log that shows which
	endpoints are communicating, and for how long. If both endpoints in		endpoints are communicating, and for how long. If both endpoints in
	the session are on the same network, the fact they are communicating		the session are on the same network, the fact they are communicating
	can be discovered.		can be discovered.
	As above, mitigation of this threat is beyond the scope of this		As above, mitigation of this threat is beyond the scope of this
	proposal.		proposal.
	6. Specification Requirements		7. IANA Considerations
			This document requires no actions from IANA.
			8. Specification Requirements
	The proposal relies on identifying and resolving any mDNS-based ICE		The proposal relies on identifying and resolving any mDNS-based ICE
	candidates as part of adding/processing a remote candidate. [ICESDP]		candidates as part of adding/processing a remote candidate. [ICESDP]
	section 4.1 could be updated to explicitly allow mDNS names in the		section 4.1 could be updated to explicitly allow mDNS names in the
	connection-address field.		connection-address field.
	The proposal relies on adding the ability to register mDNS names at		The proposal relies on adding the ability to register mDNS names at
	ICE gathering time. This could be described in [ICESDP] and/or		ICE gathering time. This could be described in [ICESDP] and/or
	[WebRTCSpec].		[WebRTCSpec].
	The proposal allows updating [IPHandling] so that mode 2 is not the		The proposal allows updating [IPHandling] so that mode 2 is not the
	mode used by default when user consent is not required. Instead, the		mode used by default when user consent is not required. Instead, the
	default mode could be defined as mode 3 with mDNS-based ICE		default mode could be defined as mode 3 with mDNS-based ICE
	candidates.		candidates.
	7. Informative References		9. Informative References
	[HTMLSpec]		[HTMLSpec]
	"HTML Living Standard", n.d.,		"HTML Living Standard", n.d.,
	<https://html.spec.whatwg.org>.		<https://html.spec.whatwg.org>.
	[ICESDP] Keranen, A., "Session Description Protocol (SDP) Offer/		[ICESDP] Keranen, A., "Session Description Protocol (SDP) Offer/
	Answer procedures for Interactive Connectivity		Answer procedures for Interactive Connectivity
	Establishment (ICE)", April 2018,		Establishment (ICE)", April 2018,
	<https://tools.ietf.org/html/		<https://tools.ietf.org/html/
	draft-ietf-mmusic-ice-sip-sdp>.		draft-ietf-mmusic-ice-sip-sdp>.
	[IPHandling]		[IPHandling]
	Shieh, G., "WebRTC IP Address Handling Requirements",		Shieh, G., "WebRTC IP Address Handling Requirements",
	April 2018, <https://tools.ietf.org/html/		April 2018, <https://tools.ietf.org/html/
	draft-ietf-rtcweb-ip-handling>.		draft-ietf-rtcweb-ip-handling>.
	[IPLeak] "IP/DNS Detect", n.d., <https://ipleak.net>.		[IPLeak] "IP/DNS Detect", n.d., <https://ipleak.net>.
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally		[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
	Unique IDentifier (UUID) URN Namespace", RFC 4122,		Unique IDentifier (UUID) URN Namespace", RFC 4122,
	DOI 10.17487/RFC4122, July 2005,		DOI 10.17487/RFC4122, July 2005,
	<https://www.rfc-editor.org/info/rfc4122>.		<https://www.rfc-editor.org/info/rfc4122>.
	[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using		[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
	Relays around NAT (TURN): Relay Extensions to Session		Relays around NAT (TURN): Relay Extensions to Session
	Traversal Utilities for NAT (STUN)", RFC 5766,		Traversal Utilities for NAT (STUN)", RFC 5766,
	DOI 10.17487/RFC5766, April 2010,		DOI 10.17487/RFC5766, April 2010,
	<https://www.rfc-editor.org/info/rfc5766>.		<https://www.rfc-editor.org/info/rfc5766>.
End of changes. 31 change blocks.
	108 lines changed or deleted		125 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/