draft-ietf-dnssd-prireq-01.txt   draft-ietf-dnssd-prireq-02.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: January 26, 2020 University of Luxembourg Expires: January 26, 2020 University of Luxembourg
July 25, 2019 July 25, 2019
DNS-SD Privacy and Security Requirements DNS-SD Privacy and Security Requirements
draft-ietf-dnssd-prireq-01 draft-ietf-dnssd-prireq-02
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 2, line 35 skipping to change at page 2, line 35
4.3. Resistance to Dictionary Attacks . . . . . . . . . . . . 11 4.3. Resistance to Dictionary Attacks . . . . . . . . . . . . 11
4.4. Resistance to Denial-of-Service Attacks . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . 12 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. Requirements for a DNS-SD Privacy Extension . . . . . . . . . 13 6. Requirements for a DNS-SD Privacy Extension . . . . . . . . . 13
6.1. Client Privacy . . . . . . . . . . . . . . . . . . . . . 14 6.1. Private Client requirements . . . . . . . . . . . . . . . 14
6.2. Server Privacy . . . . . . . . . . . . . . . . . . . . . 14 6.2. Private Server Requirements . . . . . . . . . . . . . . . 14
6.3. Security and Operation . . . . . . . . . . . . . . . . . 15 6.3. Security and Operation . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. Informative References . . . . . . . . . . . . . . . . . . . 15 9. Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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
skipping to change at page 12, line 50 skipping to change at page 12, line 50
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 List of services published by the device, which can be relationship without requiring an initial Leap Of Faith.
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 52 skipping to change at page 13, line 48
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. Requirements for a DNS-SD Privacy Extension 6. Requirements for a DNS-SD Privacy Extension
Given the considerations discussed in the previous sections, we state Given the considerations discussed in the previous sections, we state
requirements for privacy preserving DNS-SD in the following requirements for privacy preserving DNS-SD in the following
subsections. Defining a solution according to these requirements subsections.
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 Defining a solution according to these requirements will lead to a
beginning of 3]] 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.
6.1. Client Privacy 6.1. Private Client requirements
For all three scenarios described in Section 2, client privacy is a For all three scenarios described in Section 2, client privacy is a
requirement. Client privacy, as a requirement, can be subdivided requirement. Client privacy, as a requirement, can be subdivided
into: into:
1. DNS-SD messages transmitted by clients MUST NOT disclose the 1. DNS-SD messages transmitted by clients MUST NOT disclose the
client's identity, either directly or via inference, to nodes client's identity, either directly or via inference, to nodes
other than select servers. other than select servers.
2. DNS-SD messages transmitted by clients MUST NOT disclose the 2. DNS-SD messages transmitted by clients MUST NOT disclose the
skipping to change at page 14, line 37 skipping to change at page 14, line 32
to nodes other than select servers. to nodes other than select servers.
3. DNS-SD messages transmitted by clients MUST NOT contain linkable 3. DNS-SD messages transmitted by clients MUST NOT contain linkable
identifiers that allow tracing client devices. identifiers that allow tracing client devices.
DNS-SD, without privacy protection, discloses both service instance DNS-SD, without privacy protection, discloses both service instance
names and the service types of the service instances a client is names and the service types of the service instances a client is
interested in. Further, clients using DNS-SD disclose their host interested in. Further, clients using DNS-SD disclose their host
name and network parameters. name and network parameters.
6.2. Server Privacy 6.2. Private Server Requirements
Scenarios 2 and 3, further have server privacy as a requirement, Servers like the "printer" discussed in scenario 1 are public, but
which can be subdivided into: the servers discussed in scenarios 2 and 3 are by essence private.
Private servers have server privacy as a requirement, which can be
subdivided into:
1. Servers MUST neither publish their true hostnames nor any static 1. Servers MUST neither publish static identifiers such as host
substitute. Published host names must be randomly chosen as names or service names. When those fields are required by the
stated in [RFC8117]. This needs to be heeded for both SRV protocol, servers should publish randomized values. (See
service records and A/AAAA service records. [RFC8117] for a discussion of host names.).
2. Servers MUST NOT disclose service instance names of offered 2. Servers MUST use privacy options available at lower layers, and
for example avoid publishing static IPv4 or IPv6 addresses, or
static IEEE 802 MAC addresses.
3. Servers MUST NOT disclose service instance names of offered
services to unauthorized clients. services to unauthorized clients.
3. Servers MUST NOT disclose information about about the services 4. Servers MUST NOT disclose information about about the services
they offer to unauthorized clients. they offer to unauthorized clients.
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 all three SRV), and information about services (TXT). Heeding all three
service privacy requirements makes servers immune to fingerprinting service privacy requirements makes servers immune to fingerprinting
attacks on the DNS-SD level. 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 6.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 must
also heed the following security and operational requirements. also heed the following security and operational requirements.
All scenarios require: All scenarios require:
1. DoS resistance: The privacy protecting measures added to DNS-SD 1. DoS resistance: The privacy protecting measures added to DNS-SD
MUST neither add a significant CPU overhead on nodes, nor cause MUST neither add a significant CPU overhead on nodes, nor cause
significantly higher network load. Further, amplification significantly higher network load. Further, amplification
 End of changes. 12 change blocks. 
32 lines changed or deleted 29 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/