draft-ietf-dnssd-prireq-04.txt   draft-ietf-dnssd-prireq-05.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: July 31, 2020 University of Luxembourg Expires: August 24, 2020 University of Luxembourg
January 28, 2020 February 21, 2020
DNS-SD Privacy and Security Requirements DNS-SD Privacy and Security Requirements
draft-ietf-dnssd-prireq-04 draft-ietf-dnssd-prireq-05
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 at a public hotspot, serious privacy engage in DNS Service Discovery at a public hotspot, serious privacy
problems arise. We analyze the requirements of a privacy respecting problems arise. We analyze the requirements 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 July 31, 2020. This Internet-Draft will expire on August 24, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . 8
3.2.1. Information made available via DNS-SD Resource 3.2.1. Information made available via DNS-SD Resource
Records . . . . . . . . . . . . . . . . . . . . . . . 8 Records . . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . 10 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 . . . . . . . . . . . . . . . . 11
3.2.6. Privacy Implication of Discovering Services . . . . . 11 3.2.6. Privacy Implication of Discovering Services . . . . . 12
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 . . . . . . . . . . 13
3.3.4. Resistance to Denial-of-Service Attacks . . . . . . . 12 3.3.4. Resistance to Denial-of-Service Attacks . . . . . . . 13
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 . . . . . . . . . . . . . . . . . 14
3.4.3. Secure Initialization and Trust Models . . . . . . . 14 3.4.3. Secure Initialization and Trust Models . . . . . . . 14
3.4.4. External Dependencies . . . . . . . . . . . . . . . . 14 3.4.4. External Dependencies . . . . . . . . . . . . . . . . 15
4. Requirements for a DNS-SD Privacy Extension . . . . . . . . . 14 4. Requirements for a DNS-SD Privacy Extension . . . . . . . . . 15
4.1. Private Client Requirements . . . . . . . . . . . . . . . 15 4.1. Private Client Requirements . . . . . . . . . . . . . . . 15
4.2. Private Server Requirements . . . . . . . . . . . . . . . 15 4.2. Private Server Requirements . . . . . . . . . . . . . . . 16
4.3. Security and Operation . . . . . . . . . . . . . . . . . 16 4.3. Security and Operation . . . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
7. Informative References . . . . . . . . . . . . . . . . . . . 17 7. Informative References . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
DNS-SD [RFC6763] over mDNS [RFC6762] enables zero-configuration DNS Service Discovery (DNS-SD) [RFC6763] over Multicast DNS (mDNS)
service discovery in local networks. It is very convenient for [RFC6762] enables zero-configuration service discovery in local
users, but it requires the public exposure of the offering and networks. It is very convenient for users, but it requires the
requesting identities along with information about the offered and public exposure of the offering and requesting identities along with
requested services. Parts of the published information can seriously information about the offered and requested services. Parts of the
breach the user's privacy. These privacy issues and potential published information can seriously breach the user's privacy. These
solutions are discussed in [KW14a], [KW14b] and [K17]. While the privacy issues and potential solutions are discussed in [KW14a],
multicast nature of mDNS makes these risks obvious, most risks derive [KW14b] and [K17]. While the multicast nature of mDNS makes these
from the observability of transactions, and also need to be mitigated risks obvious, most risks derive from the observability of
when using server-based variants of DNS-SD. transactions. These risks 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 over mDNS. One of the devices will publish the
publish the availability of a service, such as a picture library or a availability of a service, such as a picture library or a file store
file store in our examples. The user of the other device will in our examples. The user of the other device will discover this
discover this service, and then connect to it. 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.1, 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.
Identity In this document, the term "identity" refers to the Identity In this document, the term "identity" refers to the
identity of the entity (legal person) operating a device. identity of the entity (legal person) operating a device.
Disclosing an Identity In this document "disclosing an identity" 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
skipping to change at page 7, line 6 skipping to change at page 7, line 6
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.
3.1.3. Wearable Client and Server 3.1.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
___ o ___ ___ o ___
/ \ _|___|_ / \ _|___|_
| | client |* *| | | client |* *|
\_/ \_/ \_/ \_/
| _/ | | _/ |
/|\ // /|\ /|\ // /|\
/ | \__/ ^ / | \ / | \__/ ^ / | \
skipping to change at page 7, line 43 skipping to change at page 7, line 43
between the devices. There is also an added emphasis on hiding the between the devices. There is also an added emphasis on hiding the
type of devices that the person wears. 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 in the characteristics of the devices, such adversary is interested in 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.
This scenario also represents the general case of bringing private
IoT devices into public places. A wearable IoT device might act as a
DNS-SD/mDNS client which allows attackers to infer information about
devices' owners. While the attacker might be a person as in the
example figure, this could also be abused for large scale data
collection installing stationary IoT-device-tracking servers in
frequented public places.
3.2. DNS-SD Privacy Considerations 3.2. DNS-SD Privacy Considerations
While the discovery process illustrated in the scenarios in Section 2 While the discovery process illustrated in the scenarios in
most likely would be based on [RFC6762] as a means for making service Section 3.1 most likely would be based on [RFC6762] as a means for
information available, this document considers all kinds of means for making service information available, this document considers all
making DNS-SD resource records available. These means comprise but kinds of means for making DNS-SD resource records available. These
are not limited to mDNS [RFC6762], DNS servers ([RFC1033] [RFC1034], means comprise but are not limited to mDNS [RFC6762], DNS servers
[RFC1035]), e.g. using SRP [I-D.ietf-dnssd-srp], and multi-link ([RFC1033] [RFC1034], [RFC1035]), e.g. using SRP
[RFC7558] networks. [I-D.ietf-dnssd-srp], and multi-link [RFC7558] networks.
The discovery scenarios in Section 3.1 illustrate three separate The discovery scenarios in Section 3.1 illustrate three separate
abstract privacy requirements that vary based on the use case. These abstract privacy requirements that vary based on the use case. These
are not limited to mDNS. are not limited to mDNS.
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-entity, mutual client and server identity privacy: Neither 2. Multi-entity, 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-entity, mutual client and server identity privacy: 3. Single-entity, 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
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. requirements difficult to achieve in practice. While it is intended
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, while unicast messages are only obtained by an on-link attacker, while unicast messages are only
available to MITM attackers. Using multi-link service discovery available to MITM attackers. Using multi-link service discovery
solutions [RFC7558], external attackers have to be taken into solutions [RFC7558], external attackers have to be taken into
consideration as well, e.g., when relaying multicast messages to consideration as well, e.g., when relaying multicast messages to
other links. other links.
skipping to change at page 11, line 16 skipping to change at page 11, line 29
o Port numbers used by the services. o Port numbers used by the services.
o Priority and weight attributes in the SRV records. o Priority and weight attributes in the SRV records.
This combination of services and attributes will often be sufficient This combination of services and attributes will often be sufficient
to identify the version of the software running on a device. If a to identify the version of the software running on a device. If a
device publishes many services with rich sets of attributes, the device publishes many services with rich sets of attributes, the
combination may be sufficient to identify the specific device. combination may be sufficient to identify the specific device.
A sometimes heard argument is that devices providing services can be An argument is sometimes made that devices providing services can be
identified by observing the local traffic, and that trying to hide identified by observing the local traffic, and that trying to hide
the presence of the service is futile. However, the presence of the service is futile. However,
1. Providing privacy at the discovery layer is of the essence for 1. Providing privacy at the discovery layer is of the essence for
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.
skipping to change at page 12, line 16 skipping to change at page 12, line 28
service types. Of course, just as we noted in Section 3.2.5, traffic service types. Of course, just as we noted in Section 3.2.5, traffic
analysis can often reveal the service. analysis can often reveal the service.
3.3. Security Considerations 3.3. Security Considerations
For each of the operations described above, we must also consider For each of the operations described above, we must also consider
security threats we are concerned about. security threats we are concerned about.
3.3.1. Authenticity, Integrity & Freshness 3.3.1. Authenticity, Integrity & Freshness
Can we trust the information we receive? Has it been modified in Can devices (both servers and clients) trust the information they
flight by an adversary? Do we trust the source of the information? receive? Has it been modified in flight by an adversary? Can
Is the source of information fresh, i.e., not replayed? Freshness devices trust the source of the information? Is the source of
may or may not be required depending on whether the discovery process information fresh, i.e., not replayed? Freshness may or may not be
is meant to be online. In some cases, publishing discovery required depending on whether the discovery process is meant to be
information to a shared directory or registry, rather than to each online. In some cases, publishing discovery information to a shared
online recipient through a broadcast channel, may suffice. directory or registry, rather than to each online recipient through a
broadcast channel, may suffice.
3.3.2. Confidentiality 3.3.2. Confidentiality
Confidentiality is about restricting information access to only Confidentiality is about restricting information access to only
authorized individuals. Ideally this should only be the appropriate authorized individuals. Ideally this should only be the appropriate
trusted parties, though it can be challenging to define who are "the trusted parties, though it can be challenging to define who are "the
appropriate trusted parties." In some uses cases, this may mean that appropriate trusted parties." In some use cases, this may mean that
only mutually authenticated and trusting clients and servers can read only mutually authenticated and trusting clients and servers can read
messages sent for one another. The "Discover" operation in messages sent for one another. The process of service discovery in
particular is often used to discover new entities that the device did particular is often used to discover new entities that the device did
not previously know about. It may be tricky to work out how a device not previously know about. It may be tricky to work out how a device
can have an established trust relationship with a new entity it has can have an established trust relationship with a new entity it has
never previously communicated with. never previously communicated with.
3.3.3. Resistance to Dictionary Attacks 3.3.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
skipping to change at page 14, line 33 skipping to change at page 15, line 7
Protocol designers should consider a specific usability pitfall when Protocol designers should consider a specific usability pitfall when
trust is established immediately prior to performing discovery. trust is established immediately prior to performing discovery.
Users will have a tendency to "click OK" in order to achieve their Users will have a tendency to "click OK" in order to achieve their
task. This implicit vulnerability is avoided if the trust task. This implicit vulnerability is avoided if the trust
establishment requires active participation of the user, such as establishment requires active participation of the user, such as
entering a password or PIN. entering a password or PIN.
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 parties. Optionally, this
parties. Systems which have such a dependency may be attacked by might involve synchronous communication. Systems which have such a
interfering with communication to external dependencies. Where dependency may be attacked by interfering with communication to
possible, such dependencies should be minimized. Local trust models external dependencies. Where possible, such dependencies should be
are best for secure initialization in the presence of active minimized. Local trust models are best for secure initialization in
attackers. the presence of active attackers.
4. Requirements for a DNS-SD Privacy Extension 4. 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. subsections.
Defining a solution according to these requirements will lead to a Defining a solution according to these requirements is intended to
solution that does not transmit privacy violating DNS-SD messages and lead to a solution that does not transmit privacy violating DNS-SD
further does not open pathways to new attacks against the operation messages and further does not open pathways to new attacks against
of DNS-SD. the operation of DNS-SD.
However, while this document gives advice on which privacy protecting However, while this document gives advice on which privacy protecting
mechanisms should be used on deeper layer network protocols and on mechanisms should be used on deeper layer network protocols and on
how to actually connect to services in a privacy preserving way, how to actually connect to services in a privacy preserving way,
stating corresponding requirements is out of the scope of this stating corresponding requirements is out of the scope of this
document. To mitigate attacks against privacy on lower layers, both document. To mitigate attacks against privacy on lower layers, both
servers and clients must use privacy options available at lower servers and clients must use privacy options available at lower
layers, and for example avoid publishing static IPv4 or IPv6 layers, and for example avoid publishing static IPv4 or IPv6
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
skipping to change at page 15, line 25 skipping to change at page 15, line 48
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 For all three scenarios described in Section 3.1, client privacy
requires DNS-SD messages to: requires DNS-SD messages to:
1. Avoid disclosure of the client's identity, either directly or via 1. Avoid disclosure of the client's identity, either directly or via
inference, to nodes other than select servers. inference, to nodes other than select servers.
1.
2. Avoid exposure of linkable identifiers that allow tracing client 2. Avoid exposure of linkable identifiers that allow tracing client
devices. devices.
2.
3. Avoid disclosure of the client's interest in specific service 3. Avoid disclosure of the client's interest in specific service
instances or service types to nodes other than select servers. instances or service types to nodes other than select servers.
3. When listing and resolving services via current DNS-SD deployments,
clients typically disclose their interest in specific services types
Listing and resolving services via DNS-SD, clients typically disclose and specific instances of these types, respectively.
their interest in specific services types and specific instances of
these types, respectively.
In addition to the exposure and disclosure risks noted above, In addition to the exposure and disclosure risks noted above,
protocols and implementations will have to consider fingerprinting protocols and implementations will have to consider fingerprinting
attacks (see Section 3.2.5) that could retrieve similar information. 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.
Server privacy requires DNS-SD messages to: Server privacy requires DNS-SD messages to:
1. Avoid disclosure of the server's identity, either directly or via 1. Avoid disclosure of the server's identity, either directly or via
inference, to nodes other than authorized clients. In inference, to nodes other than authorized clients. In
particular, Servers must avoid publishing static identifiers such particular, Servers must avoid publishing static identifiers such
as host names or service names. When those fields are required as host names or service names. When those fields are required
by the protocol, servers should publish randomized values. (See by the protocol, servers should publish randomized values. (See
[RFC8117] for a discussion of host names.) [RFC8117] for a discussion of host names.)
1.
2. Avoid exposure of linkable identifiers that allow tracing 2. Avoid exposure of linkable identifiers that allow tracing
servers. servers.
2.
3. Avoid disclosure of service instance names or service types of 3. Avoid disclosure of service instance names or service types of
offered services to unauthorized clients. offered services to unauthorized clients.
3.
4. Avoid disclosure of information about the services they offer to 4. Avoid disclosure of information about the services they offer to
unauthorized clients. unauthorized clients.
4.
5. Avoid disclosure of static IPv4 or IPv6 addresses. 5. Avoid disclosure of static IPv4 or IPv6 addresses.
5. When offering services via current DNS-SD deployments, servers
typically disclose their hostnames (SRV, A/AAAA), instance names of
Offering services via DNS-SD, servers typically disclose their offered services (PRT, SRV), and information about services (TXT).
hostnames (SRV, A/AAAA), instance names of offered services (PRT, Heeding these requirements protects a server's privacy on the DNS-SD
SRV), and information about services (TXT). Heeding these 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 needs In order to be secure and feasible, a DNS-SD privacy extension needs
to consider security and operational requirements including: to consider security and operational requirements including:
1. Avoiding significant CPU overhead on nodes or significantly 1. Avoiding significant CPU overhead on nodes or significantly
higher network load, because such overhead or load would make higher network load. Such overhead or load would make nodes
nodes vulnerables to denial of service attacks. vulnerable to denial of service attacks. Further, it would
increase power consumption which is critical for IoT devices.
2. Avoiding designs in which a small message can trigger a large 2. Avoiding designs in which a small message can trigger a large
amount of traffic towards an unverified address, as this could be amount of traffic towards an unverified address, as this could be
exploited in amplification attacks. exploited in amplification attacks.
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
 End of changes. 33 change blocks. 
84 lines changed or deleted 81 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/