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/