rfc8882v1.txt		rfc8882.txt
	Internet Engineering Task Force (IETF) C. Huitema		Internet Engineering Task Force (IETF) C. Huitema
	Request for Comments: 8882 Private Octopus Inc.		Request for Comments: 8882 Private Octopus Inc.
	Category: Informational D. Kaiser		Category: Informational D. Kaiser
	ISSN: 2070-1721 University of Luxembourg		ISSN: 2070-1721 University of Luxembourg
	August 2020		September 2020
	DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements		DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements
	Abstract		Abstract
	DNS-SD (DNS-based Service Discovery) normally discloses information		DNS-SD (DNS-based Service Discovery) normally discloses information
	about devices offering and requesting services. This information		about devices offering and requesting services. This information
	includes hostnames, network parameters, and possibly a further		includes hostnames, network parameters, and possibly a further
	description of the corresponding service instance. Especially when		description of the corresponding service instance. Especially when
	mobile devices engage in DNS-based Service Discovery at a public		mobile devices engage in DNS-based Service Discovery at a public
	skipping to change at line 141 ¶		skipping to change at line 141 ¶
	discovery process, e.g., devices on the same network link that are		discovery process, e.g., devices on the same network link that are
	listening to the network traffic but are not actually involved in		listening to the network traffic but are not actually involved in
	the discovery process. This document focuses on identity		the discovery process. This document focuses on identity
	disclosure by data conveyed via messages on the service discovery		disclosure by data conveyed via messages on the service discovery
	protocol layer. Still, identity leaks on deeper layers, e.g., the		protocol layer. Still, identity leaks on deeper layers, e.g., the
	IP layer, are mentioned.		IP layer, are mentioned.
	Disclosing Information		Disclosing Information
	In this document, "disclosing information" is also focused on		In this document, "disclosing information" is also focused on
	disclosure of data conveyed via messages on the service discovery		disclosure of data conveyed via messages on the service discovery
	protocol layer, such as generic nonidentity but still potentially		protocol layer, including both identity-revealing information and
	sensitive data.		other still potentially sensitive data.
	2. Threat Model		2. Threat Model
	This document considers the following attacker types sorted by		This document considers the following attacker types sorted by
	increasing power. All these attackers can either be passive (they		increasing power. All these attackers can either be passive (they
	just listen to network traffic they have access to) or active (they		just listen to network traffic they have access to) or active (they
	additionally can craft and send malicious packets).		additionally can craft and send malicious packets).
	external		external
	An external attacker is not on the same network link as victim		An external attacker is not on the same network link as victim
	skipping to change at line 353 ¶		skipping to change at line 353 ¶
	legal person are not leaked during service discovery or use.		legal person are not leaked during service discovery or use.
	In this section, we describe aspects of DNS-SD that make these		In this section, we describe aspects of DNS-SD that make these
	requirements difficult to achieve in practice. While it is intended		requirements difficult to achieve in practice. While it is intended
	to be thorough, it is not possible to be exhaustive.		to be thorough, it is not possible to be exhaustive.
	Client identity privacy, if not addressed properly, can be thwarted		Client identity privacy, if not addressed properly, can be thwarted
	by a passive attacker (see Section 2). The type of passive attacker		by a passive attacker (see Section 2). The type of passive attacker
	necessary depends on the means of making service information		necessary depends on the means of making service information
	available. Information conveyed via multicast messages can be		available. Information conveyed via multicast messages can be
	obtained by an on-link attacker. Unicast messages are easy to access		obtained by an on-link attacker. Unicast messages are harder to
	if the transmission is not encrypted but could still be accessed by		access, but if the transmission is not encrypted they could still be
	an attacker with access to network routers or bridges. Using multi-		accessed by an attacker with access to network routers or bridges.
	link service discovery solutions [RFC7558], external attackers have		Using multi-link service discovery solutions [RFC7558], external
	to be taken into consideration as well, e.g., when relaying multicast		attackers have to be taken into consideration as well, e.g., when
	messages to other links.		relaying multicast messages to other links.
	Server identity privacy can be thwarted by a passive attacker in the		Server identity privacy can be thwarted by a passive attacker in the
	same way as client identity privacy. Additionally, active attackers		same way as client identity privacy. Additionally, active attackers
	querying for information have to be taken into consideration as well.		querying for information have to be taken into consideration as well.
	This is mainly relevant for unicast-based discovery, where listening		This is mainly relevant for unicast-based discovery, where listening
	to discovery traffic requires a MITM attacker; however, an external		to discovery traffic requires a MITM attacker; however, an external
	active attacker might be able to learn the server identity by just		active attacker might be able to learn the server identity by just
	querying for service information, e.g., via DNS.		querying for service information, e.g., via DNS.
	3.2.1. Information Made Available Via DNS-SD Resource Records		3.2.1. Information Made Available Via DNS-SD Resource Records
	skipping to change at line 510 ¶		skipping to change at line 510 ¶
	enabling automatically configured privacy-preserving network		enabling automatically configured privacy-preserving network
	applications. Application layer protocols are not forced to		applications. Application layer protocols are not forced to
	leverage the offered privacy, but if device tracking is not		leverage the offered privacy, but if device tracking is not
	prevented at the deeper layers, including the service discovery		prevented at the deeper layers, including the service discovery
	layer, obfuscating a certain service's protocol at the		layer, obfuscating a certain service's protocol at the
	application layer is futile.		application layer is futile.
	2. Further, in the case of mDNS-based discovery, even if the		2. Further, in the case of mDNS-based discovery, even if the
	application layer does not protect privacy, services are		application layer does not protect privacy, services are
	typically provided via unicast, which requires a MITM attacker,		typically provided via unicast, which requires a MITM attacker,
	while identifying services based on multicast discovery messages		whereas identifying services based on multicast discovery
	just require an on-link attacker.		messages just requires an on-link attacker.
	The same argument can be extended to say that the pattern of services		The same argument can be extended to say that the pattern of services
	offered by a device allows for fingerprinting the device. This may		offered by a device allows for fingerprinting the device. This may
	or may not be true, since we can expect that services will be		or may not be true, since we can expect that services will be
	designed or updated to avoid leaking fingerprints. In any case, the		designed or updated to avoid leaking fingerprints. In any case, the
	design of the discovery service should avoid making a bad situation		design of the discovery service should avoid making a bad situation
	worse and should, as much as possible, avoid providing new		worse and should, as much as possible, avoid providing new
	fingerprinting information.		fingerprinting information.
	3.2.6. Privacy Implication of Discovering Services		3.2.6. Privacy Implication of Discovering Services
	skipping to change at line 783 ¶		skipping to change at line 783 ¶
	[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,		[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
	DOI 10.17487/RFC6762, February 2013,		DOI 10.17487/RFC6762, February 2013,
	<https://www.rfc-editor.org/info/rfc6762>.		<https://www.rfc-editor.org/info/rfc6762>.
	[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service		[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
	Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,		Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
	<https://www.rfc-editor.org/info/rfc6763>.		<https://www.rfc-editor.org/info/rfc6763>.
	6.2. Informative References		6.2. Informative References
	[ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. Wood,		[ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
	"Encrypted Server Name Indication for TLS 1.3", Work in		Encrypted Client Hello", Work in Progress, Internet-Draft,
	Progress, Internet-Draft, draft-ietf-tls-esni-06, 9 March		draft-ietf-tls-esni-07, June 1, 2020,
	2020,		<https://tools.ietf.org/html/draft-ietf-tls-esni-07>.
	<https://tools.ietf.org/html/draft-ietf-tls-esni-06>.
	[K17] Kaiser, D., "Efficient Privacy-Preserving		[K17] Kaiser, D., "Efficient Privacy-Preserving
	Configurationless Service Discovery Supporting Multi-Link		Configurationless Service Discovery Supporting Multi-Link
	Networks", August 2017,		Networks", August 2017,
	<https://nbn-resolving.de/urn:nbn:de:bsz:352-0-422757>.		<https://nbn-resolving.de/urn:nbn:de:bsz:352-0-422757>.
	[KW14a] Kaiser, D. and M. Waldvogel, "Adding Privacy to Multicast		[KW14a] Kaiser, D. and M. Waldvogel, "Adding Privacy to Multicast
	DNS Service Discovery", DOI 10.1109/TrustCom.2014.107,		DNS Service Discovery", DOI 10.1109/TrustCom.2014.107,
	September 2014, <https://ieeexplore.ieee.org/xpl/		September 2014, <https://ieeexplore.ieee.org/xpl/
	articleDetails.jsp?arnumber=7011331>.		articleDetails.jsp?arnumber=7011331>.
	skipping to change at line 865 ¶		skipping to change at line 864 ¶
	[RFC8236] Hao, F., Ed., "J-PAKE: Password-Authenticated Key Exchange		[RFC8236] Hao, F., Ed., "J-PAKE: Password-Authenticated Key Exchange
	by Juggling", RFC 8236, DOI 10.17487/RFC8236, September		by Juggling", RFC 8236, DOI 10.17487/RFC8236, September
	2017, <https://www.rfc-editor.org/info/rfc8236>.		2017, <https://www.rfc-editor.org/info/rfc8236>.
	[SLEEP-PROXY]		[SLEEP-PROXY]
	Cheshire, S., "Understanding Sleep Proxy Service",		Cheshire, S., "Understanding Sleep Proxy Service",
	December 2009,		December 2009,
	<http://stuartcheshire.org/SleepProxy/index.html>.		<http://stuartcheshire.org/SleepProxy/index.html>.
	[SRP] Cheshire, S. and T. Lemon, "Service Registration Protocol		[SRP] Lemon, T. and S. Cheshire, "Service Registration Protocol
	for DNS-Based Service Discovery", Work in Progress,		for DNS-Based Service Discovery", Work in Progress,
	Internet-Draft, draft-ietf-dnssd-srp-02, 8 July 2019,		Internet-Draft, draft-ietf-dnssd-srp-04, July 13, 2020,
	<https://tools.ietf.org/html/draft-ietf-dnssd-srp-02>.		<https://tools.ietf.org/html/draft-ietf-dnssd-srp-04>.
	Acknowledgments		Acknowledgments
	This document incorporates many contributions from Stuart Cheshire		This document incorporates many contributions from Stuart Cheshire
	and Chris Wood. Thanks to Florian Adamsky for extensive review and		and Chris Wood. Thanks to Florian Adamsky for extensive review and
	suggestions on the organization of the threat model. Thanks to Barry		suggestions on the organization of the threat model. Thanks to Barry
	Leiba for an extensive review. Thanks to Roman Danyliw, Ben Kaduk,		Leiba for an extensive review. Thanks to Roman Danyliw, Ben Kaduk,
	Adam Roach, and Alissa Cooper for their comments during IESG review.		Adam Roach, and Alissa Cooper for their comments during IESG review.
	Authors' Addresses		Authors' Addresses
End of changes. 7 change blocks.
	19 lines changed or deleted		18 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/