draft-ietf-dnssd-prireq-00.txt   draft-ietf-dnssd-prireq-01.txt 
Network Working Group C. Huitema Network Working Group C. Huitema
Internet-Draft Private Octopus Inc. Internet-Draft Private Octopus Inc.
Intended status: Informational September 30, 2018 Intended status: Informational D. Kaiser
Expires: April 3, 2019 Expires: January 26, 2020 University of Luxembourg
July 25, 2019
DNS-SD Privacy and Security Requirements DNS-SD Privacy and Security Requirements
draft-ietf-dnssd-prireq-00 draft-ietf-dnssd-prireq-01
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 over Multicast DNS at a public
hotspot, serious privacy problems arise. We analyze the requirements hotspot, serious privacy problems arise. We analyze the requirements
of a privacy respecting discovery service. of a privacy respecting discovery service.
skipping to change at page 1, line 36 skipping to change at page 1, line 37
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 April 3, 2019. This Internet-Draft will expire on January 26, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
2. DNS-SD Discovery Scenarios . . . . . . . . . . . . . . . . . 3 2. Service Discovery Scenarios . . . . . . . . . . . . . . . . . 3
2.1. Private client and public server . . . . . . . . . . . . 3 2.1. Private Client and Public Server . . . . . . . . . . . . 3
2.2. Private client and private server . . . . . . . . . . . . 4 2.2. Private Client and Private Server . . . . . . . . . . . . 4
2.3. Wearable client and server . . . . . . . . . . . . . . . 5 2.3. Wearable Client and Server . . . . . . . . . . . . . . . 5
3. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 3. DNS-SD Privacy Considerations . . . . . . . . . . . . . . . . 6
3.1. Privacy Implication of Publishing Service Instance Names 7 3.1. Privacy Implication of Publishing Service Instance Names 7
3.2. Privacy Implication of Publishing Node Names . . . . . . 7 3.2. Privacy Implication of Publishing Node Names . . . . . . 8
3.3. Privacy Implication of Publishing Service Attributes . . 8 3.3. Privacy Implication of Publishing Service Attributes . . 8
3.4. Device Fingerprinting . . . . . . . . . . . . . . . . . . 8 3.4. Device Fingerprinting . . . . . . . . . . . . . . . . . . 9
3.5. Privacy Implication of Discovering Services . . . . . . . 9 3.5. Privacy Implication of Discovering Services . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
4.1. Authenticity, Integrity & Freshness . . . . . . . . . . . 10 4.1. Authenticity, Integrity & Freshness . . . . . . . . . . . 10
4.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 10 4.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 10
4.3. Resistance to Dictionary Attacks . . . . . . . . . . . . 10 4.3. Resistance to Dictionary Attacks . . . . . . . . . . . . 11
4.4. Resistance to Denial-of-Service Attack . . . . . . . . . 10 4.4. Resistance to Denial-of-Service Attacks . . . . . . . . . 11
4.5. Resistance to Sender Impersonation . . . . . . . . . . . 11 4.5. Resistance to Sender Impersonation . . . . . . . . . . . 11
4.6. Sender Deniability . . . . . . . . . . . . . . . . . . . 11 4.6. Sender Deniability . . . . . . . . . . . . . . . . . . . 11
5. Operational Considerations . . . . . . . . . . . . . . . . . 11 5. Operational Considerations . . . . . . . . . . . . . . . . . 11
5.1. Power Management . . . . . . . . . . . . . . . . . . . . 11 5.1. Power Management . . . . . . . . . . . . . . . . . . . . 11
5.2. Protocol Efficiency . . . . . . . . . . . . . . . . . . . 11 5.2. Protocol Efficiency . . . . . . . . . . . . . . . . . . . 12
5.3. Secure Initialization and Trust Models . . . . . . . . . 12 5.3. Secure Initialization and Trust Models . . . . . . . . . 12
5.4. External Dependencies . . . . . . . . . . . . . . . . . . 13 5.4. External Dependencies . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Requirements for a DNS-SD Privacy Extension . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Client Privacy . . . . . . . . . . . . . . . . . . . . . 14
8. Informative References . . . . . . . . . . . . . . . . . . . 13 6.2. Server Privacy . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 6.3. Security and Operation . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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].
skipping to change at page 3, line 15 skipping to change at page 3, line 20
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, we find that the DNS-SD When analyzing these scenarios in Section 3, we find that the DNS-SD
messages leak identifying information such as the instance name, the messages leak identifying information such as the service instance
host name or service properties. name, the host name, or service properties.
1.1. Requirements 1.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. DNS-SD Discovery Scenarios 2. Service Discovery Scenarios
DNS-Based Service Discovery (DNS-SD) is defined in [RFC6763]. It
allows nodes to publish the availability of an instance of a service
by inserting specific records in the DNS ([RFC1033], [RFC1034],
[RFC1035]) or by publishing these records locally using multicast DNS
(mDNS) [RFC6762]. Available services are described using three types
of records:
PTR Record: Associates a service type in the domain with an
"instance" name of this service type.
SRV Record: Provides the node name, port number, priority and weight
associated with the service instance, in conformance with
[RFC2782].
TXT Record: Provides a set of attribute-value pairs describing
specific properties of the service instance.
In the remaining sections, we review common discovery scenarios In this section, we review common service discovery scenarios and
provided by DNS-SD and discuss their privacy requirements. discuss their privacy requirements.
2.1. Private client and public server 2.1. Private Client and Public Server
Perhaps the simplest private discovery scenario involves a single Perhaps the simplest private discovery scenario involves a single
client connecting to a public server through a public network. A client connecting to a public server through a public network. A
common example would be a traveler using a publicly available printer common example would be a traveler using a publicly available printer
in a business center, in an hotel or at an airport. in a business center, in an hotel, or at an airport.
( Taking notes: ( Taking notes:
( David is printing ( David is printing
( a document ( a document
~~~~~~~~~~~ ~~~~~~~~~~~
o o
___ o ___ ___ o ___
/ \ _|___|_ / \ _|___|_
| | |* *| | | |* *|
\_/ __ \_/ \_/ __ \_/
skipping to change at page 4, line 34 skipping to change at page 4, line 34
In that scenario, the server is public and wants to be discovered, In that scenario, the server is public and wants to be discovered,
but the client is private. The adversary will be listening to the but the client is private. The adversary will be listening to the
network traffic, trying to identify the visitors' devices and their network traffic, trying to identify the visitors' devices and their
activity. Identifying devices leads to identifying people, either activity. Identifying devices leads to identifying people, either
just for tracking people or as a preliminary to targeted attacks. just for tracking people or as a preliminary to targeted attacks.
The requirement in that scenario is that the discovery activity The requirement in that scenario is that the discovery activity
should not disclose the identity of the client. should not disclose the identity of the client.
2.2. Private client and private server 2.2. Private Client and Private Server
The second private discovery scenario involves private client The second private discovery scenario involves a private client
connecting to a private server. A common example would be two people connecting to a private server. A common example would be two people
engaging in a collaborative application in a public place, such as engaging in a collaborative application in a public place, such as
for example an airport's lounge. for example an airport's lounge.
( Taking notes: ( Taking notes:
( David is meeting ( David is meeting
( with Stuart ( with Stuart
~~~~~~~~~~~ ~~~~~~~~~~~
o o
___ ___ o ___ ___ ___ o ___
skipping to change at page 5, line 25 skipping to change at page 5, line 25
/|\ /_/ <-----------> \_\ /|\ /|\ /|\ /_/ <-----------> \_\ /|\ /|\
/ | \__/ \__/ | \ / | \ / | \__/ \__/ | \ / | \
/ | | \ / | \ / | | \ / | \
/ | | \ / | \ / | | \ / | \
/ \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \
In that scenario, the collaborative application on one of the device In that scenario, the collaborative application on one of the devices
will act as server, and the application on the other device will act will act as a server, and the application on the other device will
as client. The server wants to be discovered by the client, but has act as a client. The server wants to be discovered by the client,
no desire to be discovered by anyone else. The adversary will be but has no desire to be discovered by anyone else. The adversary
listening to network traffic, attempting to discover the identity of will be listening to network traffic, attempting to discover the
devices as in the first scenario, and also attempting to discover the identity of devices as in the first scenario, and also attempting to
patterns of traffic, as these patterns reveal the business and social discover the patterns of traffic, as these patterns reveal the
interactions between the owners of the devices. business and social interactions between the owners of the devices.
The requirement in that scenario is that the discovery activity The requirement in that scenario is that the discovery activity
should not disclose the identity of either the client or the server. should not disclose the identity of either the client or the server.
2.3. Wearable client and server 2.3. Wearable Client and Server
The third private discovery scenario involves wearable devices. A The third private discovery scenario involves wearable devices. A
typical example would be the watch on someone's wrist connecting to typical example would be the watch on someone's wrist connecting to
the phone in their pocket. the phone in their pocket.
( Taking notes: ( Taking notes:
( David' is here. His watch is ( David' is here. His watch is
( talking to his phone ( talking to his phone
~~~~~~~~~~~ ~~~~~~~~~~~
o o
skipping to change at page 6, line 41 skipping to change at page 6, line 41
relations between the device. There is also an added emphasis in relations between the device. There is also an added emphasis in
hiding the type of devices that the person wears. hiding the type of devices that the person wears.
In addition to tracking the identity of the owner of the devices, the In addition to tracking the identity of the owner of the devices, the
adversary is interested by the characteristics of the devices, such adversary is interested by the characteristics of the devices, such
as type, brand, and model. Identifying the type of device can lead as type, brand, and model. Identifying the type of device can lead
to further attacks, from theft to device specific hacking. The to further attacks, from theft to device specific hacking. The
combination of devices worn by the same person will also provide a combination of devices worn by the same person will also provide a
"fingerprint" of the person, allowing identification. "fingerprint" of the person, allowing identification.
3. Privacy Considerations 3. DNS-SD Privacy Considerations
The discovery scenarios in Section Section 2 illustrate three The discovery scenarios in Section Section 2 illustrate three
separate privacy requirements that vary based on use case: separate abstract privacy requirements that vary based on the use
case:
1. Client identity privacy: Client identities are not leaked during 1. Client identity privacy: Client identities are not leaked during
service discovery or use. service discovery or use.
2. Multi-owner, mutual client and server identity privacy: Neither 2. Multi-owner, mutual client and server identity privacy: Neither
client nor server identities are leaked during service discovery client nor server identities are leaked during service discovery
or use. or use.
3. Single-owner, mutual client and server identity privacy: 3. Single-owner, mutual client and server identity privacy:
Identities of clients and servers owned and managed by the same Identities of clients and servers owned and managed by the same
application, device, or user are not leaked during service application, device, or user are not leaked during service
discovery or use. discovery or use.
In the remaining subsections, we describe aspects of DNS-SD that make In the this section, we describe aspects of DNS-SD that make these
these requirements difficult to achieve in practice. requirements difficult to achieve in practice.
DNS-Based Service Discovery (DNS-SD) is defined in [RFC6763]. It
allows nodes to publish the availability of an instance of a service
by inserting specific records in the DNS ([RFC1033], [RFC1034],
[RFC1035]) or by publishing these records locally using multicast DNS
(mDNS) [RFC6762]. Available services are described using three types
of records:
PTR Record: Associates a service type in the domain with an
"instance" name of this service type.
SRV Record: Provides the node name, port number, priority and weight
associated with the service instance, in conformance with
[RFC2782].
TXT Record: Provides a set of attribute-value pairs describing
specific properties of the service instance.
3.1. Privacy Implication of Publishing Service Instance Names 3.1. Privacy Implication of Publishing Service Instance Names
In the first phase of discovery, client obtain all PTR records In the first phase of discovery, clients obtain all PTR records
associated with a service type in a given naming domain. Each PTR associated with a service type in a given naming domain. Each PTR
record contains a Service Instance Name defined in Section 4 of record contains a Service Instance Name defined in Section 4 of
[RFC6763]: [RFC6763]:
Service Instance Name = <Instance> . <Service> . <Domain> Service Instance Name = <Instance> . <Service> . <Domain>
The <Instance> portion of the Service Instance Name is meant to The <Instance> portion of the Service Instance Name is meant to
convey enough information for users of discovery clients to easily convey enough information for users of discovery clients to easily
select the desired service instance. Nodes that use DNS-SD over mDNS select the desired service instance. Nodes that use DNS-SD over mDNS
[RFC6762] in a mobile environment will rely on the specificity of the [RFC6762] in a mobile environment will rely on the specificity of the
skipping to change at page 10, line 41 skipping to change at page 11, line 15
never previously communicated with. never previously communicated with.
4.3. Resistance to Dictionary Attacks 4.3. Resistance to Dictionary Attacks
It can be tempting to use (publicly computable) hash functions to It can be tempting to use (publicly computable) hash functions to
obscure sensitive identifiers. This transforms a sensitive unique obscure sensitive identifiers. This transforms a sensitive unique
identifier such as an email address into a "scrambled" (but still identifier such as an email address into a "scrambled" (but still
unique) identifier. Unfortunately simple solutions may be vulnerable unique) identifier. Unfortunately simple solutions may be vulnerable
to offline dictionary attacks. to offline dictionary attacks.
4.4. Resistance to Denial-of-Service Attack 4.4. Resistance to Denial-of-Service Attacks
In any protocol where the receiver of messages has to perform In any protocol where the receiver of messages has to perform
cryptographic operations on those messages, there is a risk of a cryptographic operations on those messages, there is a risk of a
brute-force flooding attack causing the receiver to expend excessive brute-force flooding attack causing the receiver to expend excessive
amounts of CPU time (and battery power) just processing and amounts of CPU time (and battery power) just processing and
discarding those messages. discarding those messages.
4.5. Resistance to Sender Impersonation 4.5. Resistance to Sender Impersonation
Sender impersonation is an attack wherein messages such as service Sender impersonation is an attack wherein messages such as service
skipping to change at page 12, line 4 skipping to change at page 12, line 22
properties may result in a design that is not efficient. To perform properties may result in a design that is not efficient. To perform
the necessary operations the protocol may need to send and receive a the necessary operations the protocol may need to send and receive a
large number of network packets. This may consume an unreasonable large number of network packets. This may consume an unreasonable
amount of network capacity (particularly problematic when it's shared amount of network capacity (particularly problematic when it's shared
wireless spectrum), cause an unnecessary level of power consumption wireless spectrum), cause an unnecessary level of power consumption
(particularly problematic on battery devices) and may result in the (particularly problematic on battery devices) and may result in the
discovery process being slow. discovery process being slow.
It is a difficult challenge to design a discovery protocol that has It is a difficult challenge to design a discovery protocol that has
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 quickly and unauthorized observers, while also managing to do that efficiently.
efficiently.
5.3. Secure Initialization and Trust Models 5.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 One way to establish trust between two entities is to trust a third
party to make that determination for us. For example, the X.509 party to make that determination for us. For example, the X.509
certificates used by TLS and HTTPS web browsing are based on the certificates used by TLS and HTTPS web browsing are based on the
model of trusting a third party to tell us who to trust. There are model of trusting a third party to tell us whom to trust. There are
some difficulties in using this model for establishing trust for some difficulties in using this model for establishing trust for
service discovery uses. If we want to print our tax returns or service discovery uses. If we want to print our tax returns or
medical documents on "our" printer, then we need to know which 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 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 printers we discover on the network may be legitimate printers made
by legitimate printer manufacturers, but not all of them are "our" by legitimate printer manufacturers, but not all of them are "our"
printer. A third-party certificate authority cannot tell us which printer. A third-party certificate authority cannot tell us which
one of the printers is ours. one of the printers is ours.
Another common way to establish a trust relationship is Trust On 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 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 Faith, but after that public keys are exchanged and at least we can
confirm that subsequent communications are with the same entity. In confirm that subsequent communications are with the same entity. In
today's world, where there may be attackers present even at that 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 first use, it would be preferable to be able to establish a trust
relationship without requiring an initial Leap Of Faith. relationship List of services published by the device, which can be
retrieved because the SRV records will point to the same host name.
Specific attributes describing these services. Port numbers used by
the services. Priority and weight attributes in the SRV records.
without requiring an initial Leap Of Faith.
Techniques now exist for securely establishing a trust relationship Techniques now exist for securely establishing a trust relationship
without requiring an initial Leap Of Faith. Trust can be established without requiring an initial Leap Of Faith. Trust can be established
securely using a short passphrase or PIN with cryptographic 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 Such techniques require a user to enter the correct passphrase or PIN
in order for the cryptographic algorithms to establish working in order for the cryptographic algorithms to establish working
skipping to change at page 13, line 26 skipping to change at page 13, line 48
5.4. External Dependencies 5.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.
6. IANA Considerations 6. Requirements for a DNS-SD Privacy Extension
Given the considerations discussed in the previous sections, we state
requirements for privacy preserving DNS-SD in the following
subsections. Defining a solution according to these requirements
will lead to a solution that does not transmit privacy violating DNS-
SD messages and further does not open pathways to new attacks against
the operation of DNS-SD. However, while this document gives advice
on which privacy protecting mechanisms should be used on deeper layer
network protocols and on how to actually connect to services in a
privacy preserving way, stating corresponding requirements is out of
the scope of this document.
[[TODO: relate to the abstract requirements stated in 2 and the
beginning of 3]]
6.1. Client Privacy
For all three scenarios described in Section 2, client privacy is a
requirement. Client privacy, as a requirement, can be subdivided
into:
1. DNS-SD messages transmitted by clients MUST NOT disclose the
client's identity, either directly or via inference, to nodes
other than select servers.
2. DNS-SD messages transmitted by clients MUST NOT disclose the
client's interest in specific service instances or service types
to nodes other than select servers.
3. DNS-SD messages transmitted by clients MUST NOT contain linkable
identifiers that allow tracing client devices.
DNS-SD, without privacy protection, discloses both service instance
names and the service types of the service instances a client is
interested in. Further, clients using DNS-SD disclose their host
name and network parameters.
6.2. Server Privacy
Scenarios 2 and 3, further have server privacy as a requirement,
which can be subdivided into:
1. Servers MUST neither publish their true hostnames nor any static
substitute. Published host names must be randomly chosen as
stated in [RFC8117]. This needs to be heeded for both SRV
service records and A/AAAA service records.
2. Servers MUST NOT disclose service instance names of offered
services to unauthorized clients.
3. Servers MUST NOT disclose information about about the services
they offer to unauthorized clients.
Offering services via DNS-SD, servers typically disclose their
hostnames (SRV, A/AAAA), instance names of offered services (PRT,
SRV), and information about services (TXT). Heeding all three
service privacy requirements makes servers immune to fingerprinting
attacks on the DNS-SD level.
[[TODO: what about the service type? Declaring protecting the
service type as a MUST might be to strict.]]
6.3. Security and Operation
In order to be secure and feasible, a DNS-SD privacy extension must
also heed the following security and operational requirements.
All scenarios require:
1. DoS resistance: The privacy protecting measures added to DNS-SD
MUST neither add a significant CPU overhead on nodes, nor cause
significantly higher network load. Further, amplification
attacks MUST NOT be allowed.
7. IANA Considerations
This draft does not require any IANA action. This draft does not require any IANA action.
7. Acknowledgments 8. Acknowledgments
This draft incorporates many contributions from Stuart Cheshire and This draft incorporates many contributions from Stuart Cheshire and
Chris Wood. Chris Wood.
8. Informative References 9. Informative References
[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", 2017, Networks", 2017,
<http://nbn-resolving.de/urn:nbn:de:bsz:352-0-422757>. <http://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,
2014, <http://ieeexplore.ieee.org/xpl/ 2014, <http://ieeexplore.ieee.org/xpl/
articleDetails.jsp?arnumber=7011331>. articleDetails.jsp?arnumber=7011331>.
skipping to change at page 15, line 5 skipping to change at page 17, line 5
<https://www.rfc-editor.org/info/rfc8117>. <https://www.rfc-editor.org/info/rfc8117>.
[RFC8235] Hao, F., Ed., "Schnorr Non-interactive Zero-Knowledge [RFC8235] Hao, F., Ed., "Schnorr Non-interactive Zero-Knowledge
Proof", RFC 8235, DOI 10.17487/RFC8235, September 2017, Proof", RFC 8235, DOI 10.17487/RFC8235, September 2017,
<https://www.rfc-editor.org/info/rfc8235>. <https://www.rfc-editor.org/info/rfc8235>.
[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>.
Author's Address Authors' Addresses
Christian Huitema Christian Huitema
Private Octopus Inc. Private Octopus Inc.
Friday Harbor, WA 98250 Friday Harbor, WA 98250
U.S.A. U.S.A.
Email: huitema@huitema.net Email: huitema@huitema.net
URI: http://privateoctopus.com/ URI: http://privateoctopus.com/
Daniel Kaiser
University of Luxembourg
6, avenue de la Fonte
Esch-sur-Alzette 4364
Luxembourg
Email: daniel.kaiser@uni.lu
URI: https://secan-lab.uni.lu/
 End of changes. 32 change blocks. 
69 lines changed or deleted 154 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/