draft-ietf-dnssd-prireq-03.txt		draft-ietf-dnssd-prireq-04.txt
	Network Working Group C. Huitema		Network Working Group C. Huitema
	Internet-Draft Private Octopus Inc.		Internet-Draft Private Octopus Inc.
	Intended status: Informational D. Kaiser		Intended status: Informational D. Kaiser
	Expires: June 22, 2020 University of Luxembourg		Expires: July 31, 2020 University of Luxembourg
	December 20, 2019		January 28, 2020
	DNS-SD Privacy and Security Requirements		DNS-SD Privacy and Security Requirements
	draft-ietf-dnssd-prireq-03		draft-ietf-dnssd-prireq-04
	Abstract		Abstract
	DNS-SD (DNS Service Discovery) normally discloses information about		DNS-SD (DNS Service Discovery) normally discloses information about
	devices offering and requesting services. This information includes		devices offering and requesting services. This information includes
	host names, network parameters, and possibly a further description of		host names, network parameters, and possibly a further description of
	the corresponding service instance. Especially when mobile devices		the corresponding service instance. Especially when mobile devices
	engage in DNS Service Discovery over Multicast DNS at a public		engage in DNS Service Discovery at a public hotspot, serious privacy
	hotspot, serious privacy problems arise. We analyze the requirements		problems arise. We analyze the requirements of a privacy respecting
	of a privacy respecting discovery service.		discovery service.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 22, 2020.		This Internet-Draft will expire on July 31, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 4		3. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Service Discovery Scenarios . . . . . . . . . . . . . . . 4		3.1. Service Discovery Scenarios . . . . . . . . . . . . . . . 4
	3.1.1. Private Client and Public Server . . . . . . . . . . 4		3.1.1. Private Client and Public Server . . . . . . . . . . 4
	3.1.2. Private Client and Private Server . . . . . . . . . . 5		3.1.2. Private Client and Private Server . . . . . . . . . . 5
	3.1.3. Wearable Client and Server . . . . . . . . . . . . . 6		3.1.3. Wearable Client and Server . . . . . . . . . . . . . 6
	3.2. DNS-SD Privacy Considerations . . . . . . . . . . . . . . 7		3.2. DNS-SD Privacy Considerations . . . . . . . . . . . . . . 7
	3.2.1. Information made available via DNS-SD Resource		3.2.1. Information made available via DNS-SD Resource
	Records . . . . . . . . . . . . . . . . . . . . . . . 8		Records . . . . . . . . . . . . . . . . . . . . . . . 8
	3.2.2. Privacy Implication of Publishing Service Instance		3.2.2. Privacy Implication of Publishing Service Instance
	Names . . . . . . . . . . . . . . . . . . . . . . . . 9		Names . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.2.3. Privacy Implication of Publishing Node Names . . . . 9		3.2.3. Privacy Implication of Publishing Node Names . . . . 10
	3.2.4. Privacy Implication of Publishing Service Attributes 10		3.2.4. Privacy Implication of Publishing Service Attributes 10
	3.2.5. Device Fingerprinting . . . . . . . . . . . . . . . . 10		3.2.5. Device Fingerprinting . . . . . . . . . . . . . . . . 10
	3.2.6. Privacy Implication of Discovering Services . . . . . 11		3.2.6. Privacy Implication of Discovering Services . . . . . 11
	3.3. Security Considerations . . . . . . . . . . . . . . . . . 12		3.3. Security Considerations . . . . . . . . . . . . . . . . . 12
	3.3.1. Authenticity, Integrity & Freshness . . . . . . . . . 12		3.3.1. Authenticity, Integrity & Freshness . . . . . . . . . 12
	3.3.2. Confidentiality . . . . . . . . . . . . . . . . . . . 12		3.3.2. Confidentiality . . . . . . . . . . . . . . . . . . . 12
	3.3.3. Resistance to Dictionary Attacks . . . . . . . . . . 12		3.3.3. Resistance to Dictionary Attacks . . . . . . . . . . 12
	3.3.4. Resistance to Denial-of-Service Attacks . . . . . . . 12		3.3.4. Resistance to Denial-of-Service Attacks . . . . . . . 12
	3.3.5. Resistance to Sender Impersonation . . . . . . . . . 13		3.3.5. Resistance to Sender Impersonation . . . . . . . . . 13
	3.3.6. Sender Deniability . . . . . . . . . . . . . . . . . 13		3.3.6. Sender Deniability . . . . . . . . . . . . . . . . . 13
	3.4. Operational Considerations . . . . . . . . . . . . . . . 13		3.4. Operational Considerations . . . . . . . . . . . . . . . 13
	3.4.1. Power Management . . . . . . . . . . . . . . . . . . 13		3.4.1. Power Management . . . . . . . . . . . . . . . . . . 13
	3.4.2. Protocol Efficiency . . . . . . . . . . . . . . . . . 13		3.4.2. Protocol Efficiency . . . . . . . . . . . . . . . . . 13
	3.4.3. Secure Initialization and Trust Models . . . . . . . 14		3.4.3. Secure Initialization and Trust Models . . . . . . . 14
	3.4.4. External Dependencies . . . . . . . . . . . . . . . . 15		3.4.4. External Dependencies . . . . . . . . . . . . . . . . 14
	4. Requirements for a DNS-SD Privacy Extension . . . . . . . . . 15		4. Requirements for a DNS-SD Privacy Extension . . . . . . . . . 14
	4.1. Private Client Requirements . . . . . . . . . . . . . . . 16		4.1. Private Client Requirements . . . . . . . . . . . . . . . 15
	4.2. Private Server Requirements . . . . . . . . . . . . . . . 16		4.2. Private Server Requirements . . . . . . . . . . . . . . . 15
	4.3. Security and Operation . . . . . . . . . . . . . . . . . 17		4.3. Security and Operation . . . . . . . . . . . . . . . . . 16
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
	7. Informative References . . . . . . . . . . . . . . . . . . . 18		7. Informative References . . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	DNS-SD [RFC6763] over mDNS [RFC6762] enables zero-configuration		DNS-SD [RFC6763] over mDNS [RFC6762] enables zero-configuration
	service discovery in local networks. It is very convenient for		service discovery in local networks. It is very convenient for
	users, but it requires the public exposure of the offering and		users, but it requires the public exposure of the offering and
	requesting identities along with information about the offered and		requesting identities along with information about the offered and
	requested services. Parts of the published information can seriously		requested services. Parts of the published information can seriously
	breach the user's privacy. These privacy issues and potential		breach the user's privacy. These privacy issues and potential
	solutions are discussed in [KW14a], [KW14b] and [K17].		solutions are discussed in [KW14a], [KW14b] and [K17]. While the
			multicast nature of mDNS makes these risks obvious, most risks derive
			from the observability of transactions, and also need to be mitigated
			when using server-based variants of DNS-SD.
	There are cases when nodes connected to a network want to provide or		There are cases when nodes connected to a network want to provide or
	consume services without exposing their identity to the other parties		consume services without exposing their identity to the other parties
	connected to the same network. Consider for example a traveler		connected to the same network. Consider for example a traveler
	wanting to upload pictures from a phone to a laptop when connected to		wanting to upload pictures from a phone to a laptop when connected to
	the Wi-Fi network of an Internet cafe, or two travelers who want to		the Wi-Fi network of an Internet cafe, or two travelers who want to
	share files between their laptops when waiting for their plane in an		share files between their laptops when waiting for their plane in an
	airport lounge.		airport lounge.
	We expect that these exchanges will start with a discovery procedure		We expect that these exchanges will start with a discovery procedure
	using DNS-SD [RFC6763] over mDNS [RFC6762]. One of the devices will		using DNS-SD [RFC6763] over mDNS [RFC6762]. One of the devices will
	publish the availability of a service, such as a picture library or a		publish the availability of a service, such as a picture library or a
	file store in our examples. The user of the other device will		file store in our examples. The user of the other device will
	discover this service, and then connect to it.		discover this service, and then connect to it.
	When analyzing these scenarios in Section 3.2, we find that the DNS-		When analyzing these scenarios in Section 3.2, we find that the DNS-
	SD messages leak identifying information such as the service instance		SD messages leak identifying information such as the service instance
	name, the host name, or service properties.		name, the host name, or service properties.
	1.1. 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].
	Identity In this document, the term "identity" refers to the		Identity In this document, the term "identity" refers to the
	identity of the entitiy (legal person) operating a device.		identity of the entity (legal person) operating a device.
	Disclosing an Identity In this document "disclosing an identiy"		Disclosing an Identity In this document "disclosing an identity"
	means showing the identity of operating entities to devices		means showing the identity of operating entities to devices
	external to the discovery process; e.g., devices on the same		external to the discovery process; e.g., devices on the same
	network link that are listening to the network traffic but are not		network link that are listening to the network traffic but are not
	actually involved in the discovery process. This document focuses		actually involved in the discovery process. This document focuses
	on identity disclosure by data conveyed via messages on the		on identity disclosure by data conveyed via messages on the
	service discovery protocol layer. Still, identity leaks on deeper		service discovery protocol layer. Still, identity leaks on deeper
	layers, e.g., the IP layer, are mentioned.		layers, e.g., the IP layer, are mentioned.
	Disclosing Information In this document "disclosing information" is		Disclosing Information In this document "disclosing information" is
	also focused on disclosure by data conveyed via messages on the		also focused on disclosure by data conveyed via messages on the
	skipping to change at page 4, line 34 ¶		skipping to change at page 4, line 23 ¶
	MITM A Man in the Middle (MITM) attacker either controls (parts of)		MITM A Man in the Middle (MITM) attacker either controls (parts of)
	a network link or can trick two parties to send traffic via him;		a network link or can trick two parties to send traffic via him;
	thus, the MITM attacker has access to unicast traffic between		thus, the MITM attacker has access to unicast traffic between
	devices engaging in service discovery. This attacker can also		devices engaging in service discovery. This attacker can also
	mount all attacks an on-link attacker can mount.		mount all attacks an on-link attacker can mount.
	3. Threat Analysis		3. Threat Analysis
	In this section we analyse how the attackers described in the		In this section we analyse how the attackers described in the
	previous section might threaten the privacy of legal persons		previous section might threaten the privacy of entities operating
	operating devices engaging in service discovery. We focus on attacks		devices engaging in service discovery. We focus on attacks
	leveraging data transmitted in service discovery protocol messages.		leveraging data transmitted in service discovery protocol messages.
	3.1. Service Discovery Scenarios		3.1. Service Discovery Scenarios
	In this section, we review common service discovery scenarios and		In this section, we review common service discovery scenarios and
	discuss privacy threats and their privacy requirements. In all three		discuss privacy threats and their privacy requirements. In all three
	of these common scenarios the attacker is of the type passive on-		of these common scenarios the attacker is of the type passive on-
	link.		link.
	3.1.1. Private Client and Public Server		3.1.1. Private Client and Public Server
	skipping to change at page 9, line 37 ¶		skipping to change at page 9, line 37 ¶
	Internet Cafe, the list of available service instances may look like:		Internet Cafe, the list of available service instances may look like:
	Alice's Images . _imageStore._tcp . local		Alice's Images . _imageStore._tcp . local
	Alice's Mobile Phone . _presence._tcp . local		Alice's Mobile Phone . _presence._tcp . local
	Alice's Notebook . _presence._tcp . local		Alice's Notebook . _presence._tcp . local
	Bob's Notebook . _presence._tcp . local		Bob's Notebook . _presence._tcp . local
	Carol's Notebook . _presence._tcp . local		Carol's Notebook . _presence._tcp . local
	Alice will see the list on her phone and understand intuitively that		Alice will see the list on her phone and understand intuitively that
	she should pick the first item. The discovery will "just work".		she should pick the first item. The discovery will "just work".
			(Note that our examples of service names conform to the specification
			in section 4.1 of [RFC6763], but may require some character escaping
			when entered in conventional DNS software.)
	However, DNS-SD/mDNS will reveal to anybody that Alice is currently		However, DNS-SD/mDNS will reveal to anybody that Alice is currently
	visiting the Internet Cafe. It further discloses the fact that she		visiting the Internet Cafe. It further discloses the fact that she
	uses two devices, shares an image store, and uses a chat application		uses two devices, shares an image store, and uses a chat application
	supporting the _presence protocol on both of her devices. She might		supporting the _presence protocol on both of her devices. She might
	currently chat with Bob or Carol, as they are also using a _presence		currently chat with Bob or Carol, as they are also using a _presence
	supporting chat application. This information is not just available		supporting chat application. This information is not just available
	to devices actively browsing for and offering services, but to		to devices actively browsing for and offering services, but to
	anybody passively listening to the network traffic, i.e. a passive		anybody passively listening to the network traffic, i.e. a passive
	on-link attacker.		on-link attacker.
	skipping to change at page 13, line 29 ¶		skipping to change at page 13, line 33 ¶
	3.4. Operational Considerations		3.4. Operational Considerations
	3.4.1. Power Management		3.4.1. Power Management
	Many modern devices, especially battery-powered devices, use power		Many modern devices, especially battery-powered devices, use power
	management techniques to conserve energy. One such technique is for		management techniques to conserve energy. One such technique is for
	a device to transfer information about itself to a proxy, which will		a device to transfer information about itself to a proxy, which will
	act on behalf of the device for some functions, while the device		act on behalf of the device for some functions, while the device
	itself goes to sleep to reduce power consumption. When the proxy		itself goes to sleep to reduce power consumption. When the proxy
	determines that some action is required which only the device itself		determines that some action is required which only the device itself
	can perform, the proxy may have some way, such as Ethernet "Magic		can perform, the proxy may have some way to wake the device, as
	Packet", to wake the device.		implied in RFC6762 [RFC6762]
	In many cases, the device may not trust the network proxy		In many cases, the device may not trust the network proxy
	sufficiently to share all its confidential key material with the		sufficiently to share all its confidential key material with the
	proxy. This poses challenges for combining private discovery that		proxy. This poses challenges for combining private discovery that
	relies on per-query cryptographic operations, with energy-saving		relies on per-query cryptographic operations, with energy-saving
	techniques that rely on having (somewhat untrusted) network proxies		techniques that rely on having (somewhat untrusted) network proxies
	answer queries on behalf of sleeping devices.		answer queries on behalf of sleeping devices.
	3.4.2. Protocol Efficiency		3.4.2. Protocol Efficiency
	skipping to change at page 14, line 12 ¶		skipping to change at page 14, line 16 ¶
	the property of obscuring the details of what it is doing from		the property of obscuring the details of what it is doing from
	unauthorized observers, while also managing to do that efficiently.		unauthorized observers, while also managing to do that efficiently.
	3.4.3. Secure Initialization and Trust Models		3.4.3. Secure Initialization and Trust Models
	One of the challenges implicit in the preceding discussions is that		One of the challenges implicit in the preceding discussions is that
	whenever we discuss "trusted entities" versus "untrusted entities",		whenever we discuss "trusted entities" versus "untrusted entities",
	there needs to be some way that trust is initially established, to		there needs to be some way that trust is initially established, to
	convert an "untrusted entity" into a "trusted entity".		convert an "untrusted entity" into a "trusted entity".
	One way to establish trust between two entities is to trust a third		The purpose of this document is not to define the specific way in
	party to make that determination for us. For example, the X.509		which trust can be established. Protocol designers may rely on a
	certificates used by TLS and HTTPS web browsing are based on the		number of existing technologies, including PKI, Trust On First Use
	model of trusting a third party to tell us whom to trust. There are		(TOFU), or using a short passphrase or PIN with cryptographic
	some difficulties in using this model for establishing trust for
	service discovery uses. If we want to print our tax returns or
	medical documents on "our" printer, then we need to know which
	printer on the network we can trust be be "our" printer. All of the
	printers we discover on the network may be legitimate printers made
	by legitimate printer manufacturers, but not all of them are "our"
	printer. A third-party certificate authority cannot tell us which
	one of the printers is ours.
	Another common way to establish a trust relationship is Trust On
	First Use (TOFU), as used by ssh. The first usage is a Leap Of
	Faith, but after that public keys are exchanged and at least we can
	confirm that subsequent communications are with the same entity. In
	today's world, where there may be attackers present even at that
	first use, it would be preferable to be able to establish a trust
	relationship without requiring an initial Leap Of Faith.
	Techniques now exist for securely establishing a trust relationship
	without requiring an initial Leap Of Faith. Trust can be established
	securely using a short passphrase or PIN with cryptographic
	algorithms such as Secure Remote Password (SRP) [RFC5054] or a		algorithms such as Secure Remote Password (SRP) [RFC5054] or a
	Password Authenticated Key Exchange like J-PAKE [RFC8236] using a		Password Authenticated Key Exchange like J-PAKE [RFC8236] using a
	Schnorr Non-interactive Zero-Knowledge Proof [RFC8235].		Schnorr Non-interactive Zero-Knowledge Proof [RFC8235].
	Such techniques require a user to enter the correct passphrase or PIN		Protocol designers should consider a specific usability pitfall when
	in order for the cryptographic algorithms to establish working		trust is established immediately prior to performing discovery.
	communication. This avoids the human tendency to simply press the		Users will have a tendency to "click OK" in order to achieve their
	"OK" button when asked if they want to do something on their		task. This implicit vulnerability is avoided if the trust
	electronic device. It removes the human fallibility element from the		establishment requires active participation of the user, such as
	equation, and avoids the human users inadvertently sabotaging their		entering a password or PIN.
	own security.
	Without these techniques, users who try to print their tax return on
	a printer they've never used before will be tempted to just go ahead
	if the name looks right. With these techniques they'll be prompted
	to enter a pairing PIN, and *cannot* ignore that warning. They can't
	just press an "OK" button. They have to walk to the printer and read
	the displayed PIN and enter it. And if the intended printer is not
	displaying a pairing PIN, or is displaying a different pairing PIN,
	that means the user may be being spoofed, and the connection will not
	succeed, and the failure will not reveal any secret information to
	the attacker. As much as the human desires to "just give me an OK
	button to make it print", and the attacker desires them to click that
	OK button, too, the cryptographic algorithms do not give the user the
	ability to opt out of the security, and consequently do not give the
	attacker any way to persuade the user to opt out of the security
	protections.
	3.4.4. External Dependencies		3.4.4. External Dependencies
	Trust establishment may depend on external, and optionally online,		Trust establishment may depend on external, and optionally online,
	parties. Systems which have such a dependency may be attacked by		parties. Systems which have such a dependency may be attacked by
	interfering with communication to external dependencies. Where		interfering with communication to external dependencies. Where
	possible, such dependencies should be minimized. Local trust models		possible, such dependencies should be minimized. Local trust models
	are best for secure initialization in the presence of active		are best for secure initialization in the presence of active
	attackers.		attackers.
	skipping to change at page 16, line 7 ¶		skipping to change at page 15, line 19 ¶
	addresses, or static IEEE 802 MAC addresses. For services advertised		addresses, or static IEEE 802 MAC addresses. For services advertised
	on a single network link, link local IP addresses should be used; see		on a single network link, link local IP addresses should be used; see
	[RFC3927] and [RFC4291] for IPv4 and IPv6, respectively. Static		[RFC3927] and [RFC4291] for IPv4 and IPv6, respectively. Static
	servers advertising services globally via DNS can hide their IP		servers advertising services globally via DNS can hide their IP
	addresses from unauthorized clients using the split mode topology		addresses from unauthorized clients using the split mode topology
	shown in [I-D.ietf-tls-esni]. Hiding static MAC addresses can be		shown in [I-D.ietf-tls-esni]. Hiding static MAC addresses can be
	achieved via MAC address randomization (see [RFC7844]).		achieved via MAC address randomization (see [RFC7844]).
	4.1. Private Client Requirements		4.1. Private Client Requirements
	For all three scenarios described in Section 3.1, client privacy is a		For all three scenarios described in Section 3.1, client privacy
	requirement. Client privacy, as a requirement, can be subdivided		requires DNS-SD messages to:
	into:
	1. DNS-SD messages transmitted by clients MUST NOT disclose the		1. Avoid disclosure of the client's identity, either directly or via
	client's identity, either directly or via inference, to nodes		inference, to nodes other than select servers.
	other than select servers.
	1.		1.
	2. DNS-SD messages transmitted by clients MUST NOT contain linkable		2. Avoid exposure of linkable identifiers that allow tracing client
	identifiers that allow tracing client devices.		devices.
	2.		2.
	3. DNS-SD messages transmitted by clients MUST NOT disclose the		3. Avoid disclosure of the client's interest in specific service
	client's interest in specific service instances or service types		instances or service types to nodes other than select servers.
	to nodes other than select servers.
	3.		3.
	Listing and resolving services via DNS-SD, clients typically disclose		Listing and resolving services via DNS-SD, clients typically disclose
	their interest in specific services types and specific instances of		their interest in specific services types and specific instances of
	these types, respectively.		these types, respectively.
	Privacy solutions fulfilling these requirements must be resilient to		In addition to the exposure and disclosure risks noted above,
	fingerprinting attacks (see Section 3.2.5) that could be used for		protocols and implementations will have to consider fingerprinting
	breaching these requirements.		attacks (see Section 3.2.5) that could retrieve similar information.
	4.2. Private Server Requirements		4.2. Private Server Requirements
	Servers like the "printer" discussed in scenario 1 are public, but		Servers like the "printer" discussed in scenario 1 are public, but
	the servers discussed in scenarios 2 and 3 are by essence private.		the servers discussed in scenarios 2 and 3 are by essence private.
	Private servers have server privacy as a requirement, which can be		Server privacy requires DNS-SD messages to:
	subdivided into:
	1. DNS-SD messages transmitted by servers MUST NOT disclose the		1. Avoid disclosure of the server's identity, either directly or via
	server's identity, either directly or via inference, to nodes		inference, to nodes other than authorized clients. In
	other than authorized clients. In particular, Servers MUST NOT		particular, Servers must avoid publishing static identifiers such
	publish static identifiers such as host names or service names.		as host names or service names. When those fields are required
	When those fields are required by the protocol, servers should		by the protocol, servers should publish randomized values. (See
	publish randomized values. (See [RFC8117] for a discussion of		[RFC8117] for a discussion of host names.)
	host names.)
	1.		1.
	2. DNS-SD messages transmitted by servers MUST NOT contain linkable		2. Avoid exposure of linkable identifiers that allow tracing
	identifiers that allow tracing servers.		servers.
	2.		2.
	3. DNS-SD messages transmitted by servers MUST NOT disclose service		3. Avoid disclosure of service instance names or service types of
	instance names or service types of offered services to		offered services to unauthorized clients.
	unauthorized clients.
	3.		3.
	4. DNS-SD messages transmitted by servers MUST NOT disclose		4. Avoid disclosure of information about the services they offer to
	information about the services they offer to unauthorized		unauthorized clients.
	clients.
	4.		4.
	5. DNS-SD messages transmitted by servers MUST NOT disclose static		5. Avoid disclosure of static IPv4 or IPv6 addresses.
	IPv4 or IPv6 addresses.
	5.		5.
	Offering services via DNS-SD, servers typically disclose their		Offering services via DNS-SD, servers typically disclose their
	hostnames (SRV, A/AAAA), instance names of offered services (PRT,		hostnames (SRV, A/AAAA), instance names of offered services (PRT,
	SRV), and information about services (TXT). Heeding these		SRV), and information about services (TXT). Heeding these
	requirements protects a server's privacy on the DNS-SD level.		requirements protects a server's privacy on the DNS-SD level.
	4.3. Security and Operation		4.3. Security and Operation
	In order to be secure and feasible, a DNS-SD privacy extension must		In order to be secure and feasible, a DNS-SD privacy extension needs
	also heed the following security and operational requirements.		to consider security and operational requirements including:
	All scenarios require:		1. Avoiding significant CPU overhead on nodes or significantly
			higher network load, because such overhead or load would make
			nodes vulnerables to denial of service attacks.
	1. DoS resistance: The privacy protecting measures added to DNS-SD		2. Avoiding designs in which a small message can trigger a large
	MUST neither add a significant CPU overhead on nodes, nor cause		amount of traffic towards an unverified address, as this could be
	significantly higher network load. Further, amplification		exploited in amplification attacks.
	attacks MUST NOT be allowed.
	5. IANA Considerations		5. IANA Considerations
	This draft does not require any IANA action.		This draft does not require any IANA action.
	6. Acknowledgments		6. Acknowledgments
	This draft incorporates many contributions from Stuart Cheshire and		This draft incorporates many contributions from Stuart Cheshire and
	Chris Wood. Thanks to Florian Adamsky for extensive review and		Chris Wood. Thanks to Florian Adamsky for extensive review and
	suggestions on the organization of the threat model.		suggestions on the organization of the threat model.
	skipping to change at page 18, line 45 ¶		skipping to change at page 18, line 9 ¶
	<https://www.rfc-editor.org/info/rfc1033>.		<https://www.rfc-editor.org/info/rfc1033>.
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,		STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
	<https://www.rfc-editor.org/info/rfc1034>.		<https://www.rfc-editor.org/info/rfc1034>.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
	November 1987, <https://www.rfc-editor.org/info/rfc1035>.		November 1987, <https://www.rfc-editor.org/info/rfc1035>.
	[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>.
	[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for		[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
	specifying the location of services (DNS SRV)", RFC 2782,		specifying the location of services (DNS SRV)", RFC 2782,
	DOI 10.17487/RFC2782, February 2000,		DOI 10.17487/RFC2782, February 2000,
	<https://www.rfc-editor.org/info/rfc2782>.		<https://www.rfc-editor.org/info/rfc2782>.
	[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic		[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
	Configuration of IPv4 Link-Local Addresses", RFC 3927,		Configuration of IPv4 Link-Local Addresses", RFC 3927,
	DOI 10.17487/RFC3927, May 2005,		DOI 10.17487/RFC3927, May 2005,
	<https://www.rfc-editor.org/info/rfc3927>.		<https://www.rfc-editor.org/info/rfc3927>.
End of changes. 33 change blocks.
	124 lines changed or deleted		74 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/