draft-ietf-dnssd-privacy-04.txt   draft-ietf-dnssd-privacy-05.txt 
Network Working Group C. Huitema Network Working Group C. Huitema
Internet-Draft Private Octopus Inc. Internet-Draft Private Octopus Inc.
Intended status: Standards Track D. Kaiser Intended status: Standards Track D. Kaiser
Expires: October 20, 2018 University of Konstanz Expires: April 18, 2019 University of Konstanz
April 18, 2018 October 15, 2018
Privacy Extensions for DNS-SD Privacy Extensions for DNS-SD
draft-ietf-dnssd-privacy-04 draft-ietf-dnssd-privacy-05
Abstract Abstract
DNS-SD (DNS Service Discovery) normally discloses information about DNS-SD (DNS Service Discovery) normally discloses information about
both the devices offering services and the devices requesting both the devices offering services and the devices requesting
services. This information includes host names, network parameters, services. This information includes host names, network parameters,
and possibly a further description of the corresponding service and possibly a further description of the corresponding service
instance. Especially when mobile devices engage in DNS Service instance. Especially when mobile devices engage in DNS Service
Discovery over Multicast DNS at a public hotspot, a serious privacy Discovery over Multicast DNS at a public hotspot, a serious privacy
problem arises. problem arises.
We propose to solve this problem by a two-stage approach. In the We propose to solve this problem by a two-stage approach. In the
first stage, hosts discover Private Discovery Service Instances via first stage, hosts discover Private Discovery Service Instances via
DNS-SD using special formats to protect their privacy. These service DNS-SD using special formats to protect their privacy. These service
instances correspond to Private Discovery Servers running on peers. instances correspond to Private Discovery Servers running on peers.
In the second stage, hosts directly query these Private Discovery In the second stage, hosts directly query these Private Discovery
Servers via DNS-SD over TLS. A pairwise shared secret necessary to Servers via DNS-SD over TLS. A pairwise shared secret necessary to
establish these connections is only known to hosts authorized by a establish these connections is only known to hosts authorized by a
pairing system. pairing system.
Revisions of this draft are currently considered in the DNSSD working
group.
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 October 20, 2018. This Internet-Draft will expire on April 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 4
2. Privacy Implications of DNS-SD . . . . . . . . . . . . . . . 4 2. Design of the Private DNS-SD Discovery Service . . . . . . . 4
2.1. Privacy Implication of Publishing Service Instance Names 4 2.1. Device Pairing . . . . . . . . . . . . . . . . . . . . . 5
2.2. Privacy Implication of Publishing Node Names . . . . . . 5 2.2. Discovery of the Private Discovery Service . . . . . . . 5
2.3. Privacy Implication of Publishing Service Attributes . . 5 2.2.1. Obfuscated Instance Names . . . . . . . . . . . . . . 5
2.4. Device Fingerprinting . . . . . . . . . . . . . . . . . . 6 2.2.2. Using a Predictable Nonce . . . . . . . . . . . . . . 6
2.5. Privacy Implication of Discovering Services . . . . . . . 7 2.2.3. Using a Short Proof . . . . . . . . . . . . . . . . . 7
3. Design of the Private DNS-SD Discovery Service . . . . . . . 7 2.2.4. Direct Queries . . . . . . . . . . . . . . . . . . . 8
3.1. Device Pairing . . . . . . . . . . . . . . . . . . . . . 8 2.3. Private Discovery Service . . . . . . . . . . . . . . . . 9
3.2. Discovery of the Private Discovery Service . . . . . . . 8 2.3.1. A Note on Private DNS Services . . . . . . . . . . . 10
3.2.1. Obfuscated Instance Names . . . . . . . . . . . . . . 9 2.4. Randomized Host Names . . . . . . . . . . . . . . . . . . 11
3.2.2. Using a Predictable Nonce . . . . . . . . . . . . . . 9 2.5. Timing of Obfuscation and Randomization . . . . . . . . . 11
3.2.3. Using a Short Proof . . . . . . . . . . . . . . . . . 10 3. Private Discovery Service Specification . . . . . . . . . . . 11
3.2.4. Direct Queries . . . . . . . . . . . . . . . . . . . 12 3.1. Host Name Randomization . . . . . . . . . . . . . . . . . 12
3.3. Private Discovery Service . . . . . . . . . . . . . . . . 12 3.2. Device Pairing . . . . . . . . . . . . . . . . . . . . . 12
3.3.1. A Note on Private DNS Services . . . . . . . . . . . 13 3.3. Private Discovery Server . . . . . . . . . . . . . . . . 12
3.4. Randomized Host Names . . . . . . . . . . . . . . . . . . 14 3.3.1. Establishing TLS Connections . . . . . . . . . . . . 12
3.5. Timing of Obfuscation and Randomization . . . . . . . . . 14 3.4. Publishing Private Discovery Service Instances . . . . . 13
4. Private Discovery Service Specification . . . . . . . . . . . 14 3.5. Discovering Private Discovery Service Instances . . . . . 14
4.1. Host Name Randomization . . . . . . . . . . . . . . . . . 15 3.6. Direct Discovery of Private Discovery Service Instances . 15
4.2. Device Pairing . . . . . . . . . . . . . . . . . . . . . 15 3.7. Using the Private Discovery Service . . . . . . . . . . . 16
4.3. Private Discovery Server . . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
4.3.1. Establishing TLS Connections . . . . . . . . . . . . 15 4.1. Attacks Against the Pairing System . . . . . . . . . . . 16
4.4. Publishing Private Discovery Service Instances . . . . . 16 4.2. Denial of Discovery of the Private Discovery Service . . 16
4.5. Discovering Private Discovery Service Instances . . . . . 17 4.3. Replay Attacks Against Discovery of the Private Discovery
4.6. Direct Discovery of Private Discovery Service Instances . 18 Service . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.7. Using the Private Discovery Service . . . . . . . . . . . 19 4.4. Denial of Private Discovery Service . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 4.5. Replay Attacks against the Private Discovery Service . . 17
5.1. Attacks Against the Pairing System . . . . . . . . . . . 19 4.6. Replay attacks and clock synchronization . . . . . . . . 18
5.2. Denial of Discovery of the Private Discovery Service . . 19 4.7. Fingerprinting the number of published instances . . . . 18
5.3. Replay Attacks Against Discovery of the Private Discovery
Service . . . . . . . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
5.4. Denial of Private Discovery Service . . . . . . . . . . . 20 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
5.5. Replay Attacks against the Private Discovery Service . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.6. Replay attacks and clock synchronization . . . . . . . . 21 7.1. Normative References . . . . . . . . . . . . . . . . . . 19
5.7. Fingerprinting the number of published instances . . . . 21 7.2. Informative References . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
DNS-SD [RFC6763] over mDNS [RFC6762] enables configurationless DNS-SD [RFC6763] over mDNS [RFC6762] enables configurationless
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] and [KW14b]. solutions are discussed in [KW14a] and [KW14b].
skipping to change at page 3, line 41 skipping to change at page 3, line 36
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 2, we find that the DNS-SD When analyzing these scenarios in [I-D.ietf-dnssd-prireq], we find
messages leak identifying information such as the instance name, the that the DNS-SD messages leak identifying information such as the
host name or service properties. We review the design constraint of instance name, the host name or service properties. We review the
a solution in Section 3, and describe the proposed solution in design constraint of a solution in Section 2, and describe the
Section 4. proposed solution in Section 3.
While we focus on a mDNS-based distribution of the DNS-SD resource While we focus on a mDNS-based distribution of the DNS-SD resource
records, our solution is agnostic about the distribution method and records, our solution is agnostic about the distribution method and
also works with other distribution methods, e.g. the classical also works with other distribution methods, e.g. the classical
hierarchical DNS. hierarchical DNS.
The solution presented here relies on 1-1 pairings between clients
and servers. Discussions during the IETF 101 in London showed that
this requirement of a full mesh of pairings poses some scalability
issues, as explained in [I-D.ietf-dnssd-privacyscaling]. The next
revision of this draft may propose a different mechanism.
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. Privacy Implications of DNS-SD 2. Design of the Private DNS-SD Discovery Service
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 subsections, we will review the privacy issues
related to publishing instance names, node names, service attributes
and other data, as well as review the implications of using the
discovery service as a client.
2.1. Privacy Implication of Publishing Service Instance Names
In the first phase of discovery, the client obtains all the PTR
records associated with a service type in a given naming domain.
Each PTR record contains a Service Instance Name defined in Section 4
of [RFC6763]:
Service Instance Name = <Instance> . <Service> . <Domain>
The <Instance> portion of the Service Instance Name is meant to
convey enough information for users of discovery clients to easily
select the desired service instance. Nodes that use DNS-SD over mDNS
[RFC6762] in a mobile environment will rely on the specificity of the
instance name to identify the desired service instance. In our
example of users wanting to upload pictures to a laptop in an
Internet Cafe, the list of available service instances may look like:
Alice's Images . _imageStore._tcp . local
Alice's Mobile Phone . _presence._tcp . local
Alice's Notebook . _presence._tcp . local
Bob's Notebook . _presence._tcp . local
Carol's Notebook . _presence._tcp . local
Alice will see the list on her phone and understand intuitively that
she should pick the first item. The discovery will "just work".
However, DNS-SD/mDNS will reveal to anybody that Alice is currently
visiting the Internet Cafe. It further discloses the fact that she
uses two devices, shares an image store, and uses a chat application
supporting the _presence protocol on both of her devices. She might
currently chat with Bob or Carol, as they are also using a _presence
supporting chat application. This information is not just available
to devices actively browsing for and offering services, but to
anybody passively listening to the network traffic.
2.2. Privacy Implication of Publishing Node Names
The SRV records contain the DNS name of the node publishing the
service. Typical implementations construct this DNS name by
concatenating the "host name" of the node with the name of the local
domain. The privacy implications of this practice are reviewed in
[RFC8117]. Depending on naming practices, the host name is either a
strong identifier of the device, or at a minimum a partial
identifier. It enables tracking of both the device, and, by
extension, the device's owner.
2.3. Privacy Implication of Publishing Service Attributes
The TXT record's attribute-value pairs contain information on the
characteristics of the corresponding service instance. This in turn
reveals information about the devices that publish services. The
amount of information varies widely with the particular service and
its implementation:
o Some attributes like the paper size available in a printer, are
the same on many devices, and thus only provide limited
information to a tracker.
o Attributes that have freeform values, such as the name of a
directory, may reveal much more information.
Combinations of attributes have more information power than specific
attributes, and can potentially be used for "fingerprinting" a
specific device.
Information contained in TXT records does not only breach privacy by
making devices trackable, but might directly contain private
information about the user. For instance the _presence service
reveals the "chat status" to everyone in the same network. Users
might not be aware of that.
Further, TXT records often contain version information about services
allowing potential attackers to identify devices running exploit-
prone versions of a certain service.
2.4. Device Fingerprinting
The combination of information published in DNS-SD has the potential
to provide a "fingerprint" of a specific device. Such information
includes:
o The list of services published by the device, which can be
retrieved because the SRV records will point to the same host
name.
o The specific attributes describing these services.
o The port numbers used by the services.
o The values of the priority and weight attributes in the SRV
records.
This combination of services and attributes will often be sufficient
to identify the version of the software running on a device. If a
device publishes many services with rich sets of attributes, the
combination may be sufficient to identify the specific device.
A sometimes heard argument is that devices providing services can be
identified by observing the local traffic, and that trying to hide
the presence of the service is futile. This argument, however, does
not carry much weight because
1. proving privacy at the discovery layer is of the essence for
enabling automatically configured privacy-preserving network
applications. Application layer protocols are not forced to
leverage the offered privacy, but if device tracking is not
prevented at the deeper layers, including the service discovery
layer, obfuscating a certain service's protocol at the
application layer is futile.
2. Further, even if the application layer does not protect privacy,
it is hard to record and analyse the unicast traffic (which most
applications will generate) compared to just listening to the
multicast messages sent by DNS-SD/mDNS.
The same argument can be extended to say that the pattern of services
offered by a device allows for fingerprinting the device. This may
or may not be true, since we can expect that services will be
designed or updated to avoid leaking fingerprints. In any case, the
design of the discovery service should avoid making a bad situation
worse, and should as much as possible avoid providing new
fingerprinting information.
2.5. Privacy Implication of Discovering Services
The consumers of services engage in discovery, and in doing so reveal
some information such as the list of services they are interested in
and the domains in which they are looking for the services. When the
clients select specific instances of services, they reveal their
preference for these instances. This can be benign if the service
type is very common, but it could be more problematic for sensitive
services, such as for example some private messaging services.
One way to protect clients would be to somehow encrypt the requested
service types. Of course, just as we noted in Section 2.4, traffic
analysis can often reveal the service.
3. Design of the Private DNS-SD Discovery Service
In this section, we present the design of a two-stage solution that In this section, we present the design of a two-stage solution that
enables private use of DNS-SD, without affecting existing users. The enables private use of DNS-SD, without affecting existing users. The
solution is largely based on the architecture proposed in [KW14b] and solution is largely based on the architecture proposed in [KW14b] and
[K17], which separates the general private discovery problem in three [K17], which separates the general private discovery problem in three
components. The first component is an offline pairing mechanism, components. The first component is an offline pairing mechanism,
which is performed only once per pair of users. It establishes a which is performed only once per pair of users. It establishes a
shared secret over an authenticated channel, allowing devices to shared secret over an authenticated channel, allowing devices to
authenticate using this secret without user interaction at any later authenticate using this secret without user interaction at any later
point in time. We use the pairing system proposed in point in time. We use the pairing system proposed in
skipping to change at page 8, line 20 skipping to change at page 5, line 5
In other words, the hosts first discover paired peers and then In other words, the hosts first discover paired peers and then
directly engage in privacy preserving service discovery. directly engage in privacy preserving service discovery.
The stages are independent with respect to means used for The stages are independent with respect to means used for
transmitting the necessary data. While in our extension the messages transmitting the necessary data. While in our extension the messages
for the first stage are transmitted using IP multicast, the messages for the first stage are transmitted using IP multicast, the messages
for the second stage are transmitted via unicast. One could also for the second stage are transmitted via unicast. One could also
imagine using a Distributed Hash Table for the first stage, being imagine using a Distributed Hash Table for the first stage, being
completely independent of multicast. completely independent of multicast.
3.1. Device Pairing 2.1. Device Pairing
Any private discovery solution needs to differentiate between Any private discovery solution needs to differentiate between
authorized devices, which are allowed to get information about authorized devices, which are allowed to get information about
discoverable entities, and other devices, which should not be aware discoverable entities, and other devices, which should not be aware
of the availability of private entities. The commonly used solution of the availability of private entities. The commonly used solution
to this problem is establishing a "device pairing". to this problem is establishing a "device pairing".
Device pairing has to be performed only once per pair of users. This Device pairing has to be performed only once per pair of users. This
is important for user-friendliness, as it is the only step that is important for user-friendliness, as it is the only step that
demands user-interaction. After this single pairing, privacy demands user-interaction. After this single pairing, privacy
preserving service discovery works fully automatically. In this preserving service discovery works fully automatically. In this
document, we utilize [I-D.ietf-dnssd-pairing] as the pairing document, we utilize [I-D.ietf-dnssd-pairing] as the pairing
mechanism. mechanism.
The pairing yields a mutually authenticated shared secret, and The pairing yields a mutually authenticated shared secret, and
optionally mutually authenticated public keys or certificates added optionally mutually authenticated public keys or certificates added
to a local web of trust. Public key technology has many advantages, to a local web of trust. Public key technology has many advantages,
but shared secrets are typically easier to handle on small devices. but shared secrets are typically easier to handle on small devices.
3.2. Discovery of the Private Discovery Service 2.2. Discovery of the Private Discovery Service
The first stage of service discovery is to check whether instances of The first stage of service discovery is to check whether instances of
compatible Private Discovery Services are available in the local compatible Private Discovery Services are available in the local
scope. The goal of that stage is to identify devices that share a scope. The goal of that stage is to identify devices that share a
pairing with the querier, and are available locally. The service pairing with the querier, and are available locally. The service
instances can be browsed using regular DNS-SD procedures, and then instances can be browsed using regular DNS-SD procedures, and then
filtered so that only instances offered by paired devices are filtered so that only instances offered by paired devices are
retained. retained.
3.2.1. Obfuscated Instance Names 2.2.1. Obfuscated Instance Names
The instance names for the Private Discovery Service are obfuscated, The instance names for the Private Discovery Service are obfuscated,
so that authorized peers can associate the instance with its so that authorized peers can associate the instance with its
publisher, but unauthorized peers can only observe what looks like a publisher, but unauthorized peers can only observe what looks like a
random name. To achieve this, the names are composed as the random name. To achieve this, the names are composed as the
concatenation of a nonce and a proof, which is composed by hashing concatenation of a nonce and a proof, which is composed by hashing
the nonce with a pairing key: the nonce with a pairing key:
PrivateInstanceName = <nonce>|<proof> PrivateInstanceName = <nonce>|<proof>
proof = hash(<nonce>|<key>) proof = hash(<nonce>|<key>)
skipping to change at page 9, line 28 skipping to change at page 6, line 9
pairings. pairings.
The discovering party that looks for instances of the service will The discovering party that looks for instances of the service will
receive lists of advertisements from nodes present on the network. receive lists of advertisements from nodes present on the network.
For each advertisement, it will parse the instance name, and then, For each advertisement, it will parse the instance name, and then,
for each available pairing key, compares the proof to the hash of the for each available pairing key, compares the proof to the hash of the
nonce concatenated with this pairing key. If there is no match, it nonce concatenated with this pairing key. If there is no match, it
discards the instance name. If there is a match, it has discovered a discards the instance name. If there is a match, it has discovered a
peer. peer.
3.2.2. Using a Predictable Nonce 2.2.2. Using a Predictable Nonce
Assume that there are N nodes on the local scope, and that each node Assume that there are N nodes on the local scope, and that each node
has on average M pairings. Each node will publish on average M has on average M pairings. Each node will publish on average M
records, and the node engaging in discovery may have to process on records, and the node engaging in discovery may have to process on
average N*M instance names. The discovering node will have to average N*M instance names. The discovering node will have to
compute on average M potential hashes for each nonce. The number of compute on average M potential hashes for each nonce. The number of
hash computations would scale as O(N*M*M), which means that it could hash computations would scale as O(N*M*M), which means that it could
cause a significant drain of resource in large networks. cause a significant drain of resource in large networks.
In order to minimize the amount of computing resource, we suggest In order to minimize the amount of computing resource, we suggest
skipping to change at page 10, line 43 skipping to change at page 7, line 27
stamp interval. If records can be created "on the fly", publishers stamp interval. If records can be created "on the fly", publishers
will only need to perform that computation upon receipt of the first will only need to perform that computation upon receipt of the first
query during a given interval, and cache the computed results for the query during a given interval, and cache the computed results for the
remainder of the interval. There are however scenarios in which remainder of the interval. There are however scenarios in which
records have to be produced in advance, for example when records are records have to be produced in advance, for example when records are
published within a scope defined by a domain name and managed by a published within a scope defined by a domain name and managed by a
"classic" DNS server. In such scenarios, publishers will need to "classic" DNS server. In such scenarios, publishers will need to
perform the computations and publication exactly once per time stamp perform the computations and publication exactly once per time stamp
interval. interval.
3.2.3. Using a Short Proof 2.2.3. Using a Short Proof
Devices will have to publish as many instance names as they have Devices will have to publish as many instance names as they have
peers. The instance names will have to be represented via a text peers. The instance names will have to be represented via a text
string, which means that the binary concatenation of nonce and proof string, which means that the binary concatenation of nonce and proof
will have to be encoded using a binary-to-text conversion such as will have to be encoded using a binary-to-text conversion such as
BASE64 ([RFC2045] section 6.8) or BASE32 ([RFC4648] section 6). BASE64 ([RFC2045] section 6.8) or BASE32 ([RFC4648] section 6).
Using long proofs, such as the full output of SHA256 [RFC4055], would Using long proofs, such as the full output of SHA256 [RFC4055], would
generate fairly long instance names: 48 characters using BASE64, or generate fairly long instance names: 48 characters using BASE64, or
56 using BASE32. These long names would inflate the network traffic 56 using BASE32. These long names would inflate the network traffic
required when discovering the privacy service. They would also limit required when discovering the privacy service. They would also limit
the number of DNS-SD PTR records that could be packed in a single the number of DNS-SD PTR records that could be packed in a single
1500 octet sized packet, to 23 or fewer with BASE64, or 20 or fewer 1500 octet sized packet, to 23 or fewer with BASE64, or 20 or fewer
with BASE32. with BASE32.
Shorter proofs lead to shorter messages, which is more efficient as Shorter proofs lead to shorter messages, which is more efficient as
long as we do not encounter too many collisions. A collision will long as we do not encounter too many collisions. A collision will
happen if the proof computed by the publisher using one key matches a happen if the proof computed by the publisher using one key matches a
proof computed by a receiver using another key. If a receiver proof computed by a receiver using another key. If a receiver
mistakenly believes that a proof fits one of its peers, it will mistakenly believes that a proof fits one of its peers, it will
attempt to connect to the service as explained in section Section 4.5 attempt to connect to the service as explained in section Section 3.5
but in the absence of the proper pairwise shared key, the connection but in the absence of the proper pairwise shared key, the connection
will fail. This will not create an actual error, but the probability will fail. This will not create an actual error, but the probability
of such events should be kept low. of such events should be kept low.
The following table provides the probability that a discovery agent The following table provides the probability that a discovery agent
maintaining 100 pairings will observe a collision after receiving maintaining 100 pairings will observe a collision after receiving
100000 advertisement records. It also provides the number of 100000 advertisement records. It also provides the number of
characters required for the encoding of the corresponding instance characters required for the encoding of the corresponding instance
name in BASE64 or BASE32, assuming 24 bit nonces. name in BASE64 or BASE32, assuming 24 bit nonces.
skipping to change at page 12, line 5 skipping to change at page 8, line 36
if the input is not a multiple of 40 bits. Given that, the desirable if the input is not a multiple of 40 bits. Given that, the desirable
proof lengths are thus 48 bits if using BASE64, or 56 bits if using proof lengths are thus 48 bits if using BASE64, or 56 bits if using
BASE32. The resulting instance name will be either 12 characters BASE32. The resulting instance name will be either 12 characters
long with BASE64, allowing 54 advertisements in an 1500 byte mDNS long with BASE64, allowing 54 advertisements in an 1500 byte mDNS
message, or 16 characters long with BASE32, allowing 47 message, or 16 characters long with BASE32, allowing 47
advertisements per message. advertisements per message.
In the specification section, we will assume BASE64, and 48 bit In the specification section, we will assume BASE64, and 48 bit
proofs composed of the first 6 bytes of a SHA256 hash. proofs composed of the first 6 bytes of a SHA256 hash.
3.2.4. Direct Queries 2.2.4. Direct Queries
The preceding sections assume that the discovery is performed using The preceding sections assume that the discovery is performed using
the classic DNS-SD process, in which a query for all available the classic DNS-SD process, in which a query for all available
"instance names" of a service provides a list of PTR records. The "instance names" of a service provides a list of PTR records. The
discoverer will then select the instance names that correspond to its discoverer will then select the instance names that correspond to its
peers, and request the SRV and TXT records corresponding to the peers, and request the SRV and TXT records corresponding to the
service instance, and then obtain the relevant A or AAAA records. service instance, and then obtain the relevant A or AAAA records.
This is generally required in DNS-SD because the instance names are This is generally required in DNS-SD because the instance names are
not known in advance, but for the Private Discovery Service the not known in advance, but for the Private Discovery Service the
instance names can be predicted, and a more efficient Direct Query instance names can be predicted, and a more efficient Direct Query
skipping to change at page 12, line 38 skipping to change at page 9, line 20
depending on the number of peers per node and the number of nodes depending on the number of peers per node and the number of nodes
publishing the presence discovery service in the desired scope. publishing the presence discovery service in the desired scope.
When using mDNS, it is possible to pack multiple queries in a single When using mDNS, it is possible to pack multiple queries in a single
broadcast message. Using name compression and 12 characters per broadcast message. Using name compression and 12 characters per
instance name, it is possible to pack 70 queries in a 1500 octet mDNS instance name, it is possible to pack 70 queries in a 1500 octet mDNS
multicast message. It is also possible to request unicast replies to multicast message. It is also possible to request unicast replies to
the queries, resulting in significant efficiency gains in wireless the queries, resulting in significant efficiency gains in wireless
networks. networks.
3.3. Private Discovery Service 2.3. Private Discovery Service
The Private Discovery Service discovery allows discovering a list of The Private Discovery Service discovery allows discovering a list of
available paired devices, and verifying that either party knows the available paired devices, and verifying that either party knows the
corresponding shared secret. At that point, the querier can engage corresponding shared secret. At that point, the querier can engage
in a series of directed discoveries. in a series of directed discoveries.
We have considered defining an ad-hoc protocol for the private We have considered defining an ad-hoc protocol for the private
discovery service, but found that just using TLS would be much discovery service, but found that just using TLS would be much
simpler. The directed Private Discovery Service is just a regular simpler. The directed Private Discovery Service is just a regular
DNS-SD service, accessed over TLS, using the encapsulation of DNS DNS-SD service, accessed over TLS, using the encapsulation of DNS
skipping to change at page 13, line 32 skipping to change at page 10, line 23
uint16 selected_identity; uint16 selected_identity;
} }
} PreSharedKeyExtension } PreSharedKeyExtension
According to the protocol, the PSK identity is passed in clear text According to the protocol, the PSK identity is passed in clear text
at the beginning of the key exchange. This is logical, since server at the beginning of the key exchange. This is logical, since server
and clients need to identify the secret that will be used to protect and clients need to identify the secret that will be used to protect
the connection. But if we used a static identifier for the key, the connection. But if we used a static identifier for the key,
adversaries could use that identifier to track server and clients. adversaries could use that identifier to track server and clients.
The solution is to use a time-varying identifier, constructed exactly The solution is to use a time-varying identifier, constructed exactly
like the "proof" described in Section 3.2, by concatenating a nonce like the "proof" described in Section 2.2, by concatenating a nonce
and the hash of the nonce with the shared secret. and the hash of the nonce with the shared secret.
3.3.1. A Note on Private DNS Services 2.3.1. A Note on Private DNS Services
Our solution uses a variant of the DNS over TLS protocol [RFC7858] Our solution uses a variant of the DNS over TLS protocol [RFC7858]
defined by the DNS Private Exchange working group (DPRIVE). DPRIVE defined by the DNS Private Exchange working group (DPRIVE). DPRIVE
further published an UDP variant, DNS over DTLS [RFC8094], which further published an UDP variant, DNS over DTLS [RFC8094], which
would also be a candidate. would also be a candidate.
DPRIVE and Private Discovery, however, solve two somewhat different DPRIVE and Private Discovery, however, solve two somewhat different
problems. While DPRIVE is concerned with the confidentiality of DNS problems. While DPRIVE is concerned with the confidentiality of DNS
transactions addressing the problems outlined in [RFC7626], DPRIVE transactions addressing the problems outlined in [RFC7626], DPRIVE
does not address the confidentiality or privacy issues with does not address the confidentiality or privacy issues with
skipping to change at page 14, line 15 skipping to change at page 11, line 9
o Information placed in the DNS is considered public. Even if the o Information placed in the DNS is considered public. Even if the
server does support DNS over TLS, third parties will still be able server does support DNS over TLS, third parties will still be able
to discover the content of PTR, SRV and TXT records. to discover the content of PTR, SRV and TXT records.
o Neither DNS over TLS nor DNS over DTLS applies to mDNS. o Neither DNS over TLS nor DNS over DTLS applies to mDNS.
In contrast, we propose using mutual authentication of the client and In contrast, we propose using mutual authentication of the client and
server as part of the TLS solution, to ensure that only authorized server as part of the TLS solution, to ensure that only authorized
parties learn the presence of a service. parties learn the presence of a service.
3.4. Randomized Host Names 2.4. Randomized Host Names
Instead of publishing their actual host names in the SRV records, Instead of publishing their actual host names in the SRV records,
nodes could publish randomized host names. That is the solution nodes could publish randomized host names. That is the solution
argued for in [RFC8117]. argued for in [RFC8117].
Randomized host names will prevent some of the tracking. Host names Randomized host names will prevent some of the tracking. Host names
are typically not visible by the users, and randomizing host names are typically not visible by the users, and randomizing host names
will probably not cause much usability issues. will probably not cause much usability issues.
3.5. Timing of Obfuscation and Randomization 2.5. Timing of Obfuscation and Randomization
It is important that the obfuscation of instance names is performed It is important that the obfuscation of instance names is performed
at the right time, and that the obfuscated names change in synchrony at the right time, and that the obfuscated names change in synchrony
with other identifiers, such as MAC Addresses, IP Addresses or host with other identifiers, such as MAC Addresses, IP Addresses or host
names. If the randomized host name changed but the instance name names. If the randomized host name changed but the instance name
remained constant, an adversary would have no difficulty linking the remained constant, an adversary would have no difficulty linking the
old and new host names. Similarly, if IP or MAC addresses changed old and new host names. Similarly, if IP or MAC addresses changed
but host names remained constant, the adversary could link the new but host names remained constant, the adversary could link the new
addresses to the old ones using the published name. addresses to the old ones using the published name.
The problem is handled in [RFC8117], which recommends to pick a new The problem is handled in [RFC8117], which recommends to pick a new
random host name at the time of connecting to a new network. New random host name at the time of connecting to a new network. New
instance names for the Private Discovery Services should be composed instance names for the Private Discovery Services should be composed
at the same time. at the same time.
4. Private Discovery Service Specification 3. Private Discovery Service Specification
The proposed solution uses the following components: The proposed solution uses the following components:
o Host name randomization to prevent tracking. o Host name randomization to prevent tracking.
o Device pairing yielding pairwise shared secrets. o Device pairing yielding pairwise shared secrets.
o A Private Discovery Server (PDS) running on each host. o A Private Discovery Server (PDS) running on each host.
o Discovery of the PDS instances using DNS-SD. o Discovery of the PDS instances using DNS-SD.
These components are detailed in the following subsections. These components are detailed in the following subsections.
4.1. Host Name Randomization 3.1. Host Name Randomization
Nodes publishing services with DNS-SD and concerned about their Nodes publishing services with DNS-SD and concerned about their
privacy MUST use a randomized host name. The randomized name MUST be privacy MUST use a randomized host name. The randomized name MUST be
changed when network connectivity changes, to avoid the correlation changed when network connectivity changes, to avoid the correlation
issues described in Section 3.5. The randomized host name MUST be issues described in Section 2.5. The randomized host name MUST be
used in the SRV records describing the service instance, and the used in the SRV records describing the service instance, and the
corresponding A or AAAA records MUST be made available through DNS or corresponding A or AAAA records MUST be made available through DNS or
mDNS, within the same scope as the PTR, SRV and TXT records used by mDNS, within the same scope as the PTR, SRV and TXT records used by
DNS-SD. DNS-SD.
If the link-layer address of the network connection is properly If the link-layer address of the network connection is properly
obfuscated (e.g. using MAC Address Randomization), the Randomized obfuscated (e.g. using MAC Address Randomization), the Randomized
Host Name MAY be computed using the algorithm described in section Host Name MAY be computed using the algorithm described in section
3.7 of [RFC7844]. If this is not possible, the randomized host name 3.7 of [RFC7844]. If this is not possible, the randomized host name
SHOULD be constructed by simply picking a 48 bit random number SHOULD be constructed by simply picking a 48 bit random number
meeting the Randomness Requirements for Security expressed in meeting the Randomness Requirements for Security expressed in
[RFC4075], and then use the hexadecimal representation of this number [RFC4075], and then use the hexadecimal representation of this number
as the obfuscated host name. as the obfuscated host name.
4.2. Device Pairing 3.2. Device Pairing
Nodes that want to leverage the Private Directory Service for private Nodes that want to leverage the Private Directory Service for private
service discovery among peers MUST share a secret with each of these service discovery among peers MUST share a secret with each of these
peers. Each shared secret MUST be a 256 bit randomly chosen number. peers. Each shared secret MUST be a 256 bit randomly chosen number.
We RECOMMEND using the pairing mechanism proposed in We RECOMMEND using the pairing mechanism proposed in
[I-D.ietf-dnssd-pairing] to establish these secrets. [I-D.ietf-dnssd-pairing] to establish these secrets.
4.3. Private Discovery Server 3.3. Private Discovery Server
A Private Discovery Server (PDS) is a minimal DNS server running on A Private Discovery Server (PDS) is a minimal DNS server running on
each host. Its task is to offer resource records corresponding to each host. Its task is to offer resource records corresponding to
private services only to authorized peers. These peers MUST share a private services only to authorized peers. These peers MUST share a
secret with the host (see Section 4.2). To ensure privacy of the secret with the host (see Section 3.2). To ensure privacy of the
requests, the service is only available over TLS [RFC5246], and the requests, the service is only available over TLS [RFC5246], and the
shared secrets are used to mutually authenticate peers and servers. shared secrets are used to mutually authenticate peers and servers.
The Private Name Server SHOULD support DNS push notifications The Private Name Server SHOULD support DNS push notifications
[I-D.ietf-dnssd-push], e.g. to facilitate an up-to-date contact list [I-D.ietf-dnssd-push], e.g. to facilitate an up-to-date contact list
in a chat application without polling. in a chat application without polling.
4.3.1. Establishing TLS Connections 3.3.1. Establishing TLS Connections
The PDS MUST only answer queries via DNS over TLS [RFC7858] and MUST The PDS MUST only answer queries via DNS over TLS [RFC7858] and MUST
use a PSK authenticated TLS handshake [RFC4279]. The client and use a PSK authenticated TLS handshake [RFC4279]. The client and
server SHOULD negotiate a forward secure cipher suite such as DHE-PSK server SHOULD negotiate a forward secure cipher suite such as DHE-PSK
or ECDHE-PSK when available. The shared secret exchanged during or ECDHE-PSK when available. The shared secret exchanged during
pairing MUST be used as PSK. To guarantee interoperability, pairing MUST be used as PSK. To guarantee interoperability,
implementations of the Private Name Server MUST support implementations of the Private Name Server MUST support
TLS_PSK_WITH_AES_256_GCM_SHA384. TLS_PSK_WITH_AES_256_GCM_SHA384.
When using the PSK based authentication, the "psk_identity" parameter When using the PSK based authentication, the "psk_identity" parameter
identifying the pre-shared key MUST be identical to the "Instance identifying the pre-shared key MUST be identical to the "Instance
Identifier" defined in Section 4.4, i.e. 24 bit nonce and 48 bit Identifier" defined in Section 3.4, i.e. 24 bit nonce and 48 bit
proof encoded in BASE64 as 12 character string. The server will use proof encoded in BASE64 as 12 character string. The server will use
the pairing key associated with this instance identifier. the pairing key associated with this instance identifier.
4.4. Publishing Private Discovery Service Instances 3.4. Publishing Private Discovery Service Instances
Nodes that provide the Private Discovery Service SHOULD advertise Nodes that provide the Private Discovery Service SHOULD advertise
their availability by publishing instances of the service through their availability by publishing instances of the service through
DNS-SD. DNS-SD.
The DNS-SD service type for the Private Discovery Service is The DNS-SD service type for the Private Discovery Service is
"_pds._tcp". "_pds._tcp".
Each published instance describes one server and one pairing. In the Each published instance describes one server and one pairing. In the
case where a node manages more than one pairing, it should publish as case where a node manages more than one pairing, it should publish as
skipping to change at page 17, line 5 skipping to change at page 14, line 5
set the 72 bit binary identifier as the concatenation set the 72 bit binary identifier as the concatenation
of nonce and proof of nonce and proof
set instance_name = BASE64(binary identifier) set instance_name = BASE64(binary identifier)
In this formula, HASH SHOULD be the function SHA256 defined in In this formula, HASH SHOULD be the function SHA256 defined in
[RFC4055], and BASE64 is defined in section 6.8 of [RFC2045]. The [RFC4055], and BASE64 is defined in section 6.8 of [RFC2045]. The
concatenation of a 24 bit nonce and 48 bit proof result in a 72 bit concatenation of a 24 bit nonce and 48 bit proof result in a 72 bit
string. The BASE64 conversion is 12 characters long per [RFC6763]. string. The BASE64 conversion is 12 characters long per [RFC6763].
4.5. Discovering Private Discovery Service Instances 3.5. Discovering Private Discovery Service Instances
Nodes that wish to discover Private Discovery Service Instances Nodes that wish to discover Private Discovery Service Instances
SHOULD issue a DNS-SD discovery request for the service type SHOULD issue a DNS-SD discovery request for the service type
"_pds._tcp". They MAY, as an alternative, use the Direct Discovery "_pds._tcp". They MAY, as an alternative, use the Direct Discovery
procedure defined in Section 4.6. When using the Direct Discovery procedure defined in Section 3.6. When using the Direct Discovery
procedure over mDNS, nodes SHOULD always set the QU-bit (unicast procedure over mDNS, nodes SHOULD always set the QU-bit (unicast
response requested, see [RFC6762] Section 5.4) because responses response requested, see [RFC6762] Section 5.4) because responses
related to a "_pds._tcp" instance are only relevant for the querying related to a "_pds._tcp" instance are only relevant for the querying
node itself. node itself.
When nodes send a DNS-SD discovery request, they will receive in When nodes send a DNS-SD discovery request, they will receive in
response a series of PTR records, each providing the name of one of response a series of PTR records, each providing the name of one of
the instances present in the scope. the instances present in the scope.
For each time interval, the querier SHOULD pre-calculate a hash table For each time interval, the querier SHOULD pre-calculate a hash table
skipping to change at page 18, line 40 skipping to change at page 15, line 40
Once a pairing has been marked available, the querier SHOULD try Once a pairing has been marked available, the querier SHOULD try
connecting to the corresponding instance, using the selected key. connecting to the corresponding instance, using the selected key.
The connection is likely to succeed, but it MAY fail for a variety of The connection is likely to succeed, but it MAY fail for a variety of
reasons. One of these reasons is the probabilistic nature of the reasons. One of these reasons is the probabilistic nature of the
proof, which entails a small chance of "false positive" match. This proof, which entails a small chance of "false positive" match. This
will occur if the hash of the nonce with two different keys produces will occur if the hash of the nonce with two different keys produces
the same result. In that case, the TLS connection will fail with an the same result. In that case, the TLS connection will fail with an
authentication error or a decryption error. authentication error or a decryption error.
4.6. Direct Discovery of Private Discovery Service Instances 3.6. Direct Discovery of Private Discovery Service Instances
Nodes that wish to discover Private Discovery Service Instances MAY Nodes that wish to discover Private Discovery Service Instances MAY
use the following Direct Discovery procedure instead of the regular use the following Direct Discovery procedure instead of the regular
DNS-SD Discovery explained in Section 4.5. DNS-SD Discovery explained in Section 3.5.
To perform Direct Discovery, nodes should compose a list of Private To perform Direct Discovery, nodes should compose a list of Private
Discovery Service Instances Names. There will be one name for each Discovery Service Instances Names. There will be one name for each
pairing available to the node. The Instance name for each name will pairing available to the node. The Instance name for each name will
be composed of a nonce and a proof, using the algorithm specified in be composed of a nonce and a proof, using the algorithm specified in
Section 4.4. Section 3.4.
The querier will issue SRV record queries for each of these names. The querier will issue SRV record queries for each of these names.
The queries will only succeed if the corresponding instance is The queries will only succeed if the corresponding instance is
present, in which case a pairing is discovered. After that, the present, in which case a pairing is discovered. After that, the
querier SHOULD try connecting to the corresponding instance, as querier SHOULD try connecting to the corresponding instance, as
explained in Section 4.4. explained in Section 3.4.
4.7. Using the Private Discovery Service 3.7. Using the Private Discovery Service
Once instances of the Private Discovery Service have been discovered, Once instances of the Private Discovery Service have been discovered,
peers can establish TLS connections and send DNS requests over these peers can establish TLS connections and send DNS requests over these
connections, as specified in DNS-SD. connections, as specified in DNS-SD.
5. Security Considerations 4. Security Considerations
This document specifies a method for protecting the privacy of nodes This document specifies a method for protecting the privacy of nodes
that offer and query for services. This is especially useful when that offer and query for services. This is especially useful when
operating in a public space. Hiding the identity of the publishing operating in a public space. Hiding the identity of the publishing
nodes prevents some forms of "targeting" of high value nodes. nodes prevents some forms of "targeting" of high value nodes.
However, adversaries can attempt various attacks to break the However, adversaries can attempt various attacks to break the
anonymity of the service, or to deny it. A list of these attacks and anonymity of the service, or to deny it. A list of these attacks and
their mitigations are described in the following sections. their mitigations are described in the following sections.
5.1. Attacks Against the Pairing System 4.1. Attacks Against the Pairing System
There are a variety of attacks against pairing systems, which may There are a variety of attacks against pairing systems, which may
result in compromised pairing secrets. If an adversary manages to result in compromised pairing secrets. If an adversary manages to
acquire a compromised key, the adversary will be able to perform acquire a compromised key, the adversary will be able to perform
private service discovery according to Section 4.5. This will allow private service discovery according to Section 3.5. This will allow
tracking of the service. The adversary will also be able to discover tracking of the service. The adversary will also be able to discover
which private services are available for the compromised pairing. which private services are available for the compromised pairing.
Attacks on pairing systems are detailed in [I-D.ietf-dnssd-pairing]. Attacks on pairing systems are detailed in [I-D.ietf-dnssd-pairing].
5.2. Denial of Discovery of the Private Discovery Service 4.2. Denial of Discovery of the Private Discovery Service
The algorithm described in Section 4.5 scales as O(M*N), where M is The algorithm described in Section 3.5 scales as O(M*N), where M is
the number of pairings per node and N is the number of nodes in the the number of pairings per node and N is the number of nodes in the
local scope. Adversaries can attack this service by publishing local scope. Adversaries can attack this service by publishing
"fake" instances, effectively increasing the number N in that scaling "fake" instances, effectively increasing the number N in that scaling
equation. equation.
Similar attacks can be mounted against DNS-SD: creating fake Similar attacks can be mounted against DNS-SD: creating fake
instances will generally increase the noise in the system and make instances will generally increase the noise in the system and make
discovery less usable. Private Discovery Service discovery SHOULD discovery less usable. Private Discovery Service discovery SHOULD
use the same mitigations as DNS-SD. use the same mitigations as DNS-SD.
The attack could be amplified if the clients needed to compute proofs The attack could be amplified if the clients needed to compute proofs
for all the nonces presented in Private Discovery Service Instance for all the nonces presented in Private Discovery Service Instance
names. This is mitigated by the specification of nonces as rounded names. This is mitigated by the specification of nonces as rounded
time stamps in Section 4.5. If we assume that timestamps must not be time stamps in Section 3.5. If we assume that timestamps must not be
too old, there will be a finite number of valid rounded timestamps at too old, there will be a finite number of valid rounded timestamps at
any time. Even if there are many instances present, they would all any time. Even if there are many instances present, they would all
pick their nonces from this small number of rounded timestamps, and a pick their nonces from this small number of rounded timestamps, and a
smart client will make sure that proofs are only computed once per smart client will make sure that proofs are only computed once per
valid time stamp. valid time stamp.
5.3. Replay Attacks Against Discovery of the Private Discovery Service 4.3. Replay Attacks Against Discovery of the Private Discovery Service
Adversaries can record the service instance names published by Adversaries can record the service instance names published by
Private Discovery Service instances, and replay them later in Private Discovery Service instances, and replay them later in
different contexts. Peers engaging in discovery can be misled into different contexts. Peers engaging in discovery can be misled into
believing that a paired server is present. They will attempt to believing that a paired server is present. They will attempt to
connect to the absent peer, and in doing so will disclose their connect to the absent peer, and in doing so will disclose their
presence in a monitored scope. presence in a monitored scope.
The binary instance identifiers defined in Section 4.4 start with 24 The binary instance identifiers defined in Section 3.4 start with 24
bits encoding the most significant bits of the "UNIX" time. In order bits encoding the most significant bits of the "UNIX" time. In order
to protect against replay attacks, clients SHOULD verify that this to protect against replay attacks, clients SHOULD verify that this
time is reasonably recent, as specified in Section 4.5. time is reasonably recent, as specified in Section 3.5.
5.4. Denial of Private Discovery Service 4.4. Denial of Private Discovery Service
The Private Discovery Service is only available through a mutually The Private Discovery Service is only available through a mutually
authenticated TLS connection, which provides state-of-the-art authenticated TLS connection, which provides state-of-the-art
protection mechanisms. However, adversaries can mount a denial of protection mechanisms. However, adversaries can mount a denial of
service attack against the service. In the absence of shared service attack against the service. In the absence of shared
secrets, the connections will fail, but the servers will expend some secrets, the connections will fail, but the servers will expend some
CPU cycles defending against them. CPU cycles defending against them.
To mitigate such attacks, nodes SHOULD restrict the range of network To mitigate such attacks, nodes SHOULD restrict the range of network
addresses from which they accept connections, matching the expected addresses from which they accept connections, matching the expected
scope of the service. scope of the service.
This mitigation will not prevent denial of service attacks performed This mitigation will not prevent denial of service attacks performed
by locally connected adversaries; but protecting against local denial by locally connected adversaries; but protecting against local denial
of service attacks is generally very difficult. For example, local of service attacks is generally very difficult. For example, local
attackers can also attack mDNS and DNS-SD by generating a large attackers can also attack mDNS and DNS-SD by generating a large
number of multicast requests. number of multicast requests.
5.5. Replay Attacks against the Private Discovery Service 4.5. Replay Attacks against the Private Discovery Service
Adversaries may record the PSK Key Identifiers used in successful Adversaries may record the PSK Key Identifiers used in successful
connections to a private discovery service. They could attempt to connections to a private discovery service. They could attempt to
replay them later against nodes advertising the private service at replay them later against nodes advertising the private service at
other times or at other locations. If the PSK identifier is still other times or at other locations. If the PSK identifier is still
valid, the server will accept the TLS connection, and in doing so valid, the server will accept the TLS connection, and in doing so
will reveal being the same server observed at a previous time or will reveal being the same server observed at a previous time or
location. location.
The PSK identifiers defined in Section 4.3.1 start with the 24 most The PSK identifiers defined in Section 3.3.1 start with the 24 most
significant bits of the "UNIX" time. In order to mitigate replay significant bits of the "UNIX" time. In order to mitigate replay
attacks, servers SHOULD verify that this time is reasonably recent, attacks, servers SHOULD verify that this time is reasonably recent,
and fail the connection if it is too old, or if it occurs too far in and fail the connection if it is too old, or if it occurs too far in
the future. the future.
The processing of timestamps is however affected by the accuracy of The processing of timestamps is however affected by the accuracy of
computer clocks. If the check is too strict, reasonable connections computer clocks. If the check is too strict, reasonable connections
could fail. To further mitigate replay attacks, servers MAY record could fail. To further mitigate replay attacks, servers MAY record
the list of valid PSK identifiers received in a recent past, and fail the list of valid PSK identifiers received in a recent past, and fail
connections if one of these identifiers is replayed. connections if one of these identifiers is replayed.
5.6. Replay attacks and clock synchronization 4.6. Replay attacks and clock synchronization
The mitigation of replay attacks relies on verification of the time The mitigation of replay attacks relies on verification of the time
encoded in the nonce. This verification assumes that the hosts encoded in the nonce. This verification assumes that the hosts
engaged in discovery have a reasonably accurate sense of the current engaged in discovery have a reasonably accurate sense of the current
time. time.
5.7. Fingerprinting the number of published instances 4.7. Fingerprinting the number of published instances
Adversaries could monitor the number of instances published by a Adversaries could monitor the number of instances published by a
particular device, which in the absence of mitigations will reflect particular device, which in the absence of mitigations will reflect
the number of pairings established by that device. This number will the number of pairings established by that device. This number will
probably vary between 1 and maybe 100, providing the adversary with probably vary between 1 and maybe 100, providing the adversary with
maybe 6 or 7 bits of input in a fingerprinting algorithm. maybe 6 or 7 bits of input in a fingerprinting algorithm.
Devices MAY protect against this fingerprinting by publishing a Devices MAY protect against this fingerprinting by publishing a
number of "fake" instances in addition to the real ones. The fake number of "fake" instances in addition to the real ones. The fake
instance identifiers will contain the same nonce as the genuine instance identifiers will contain the same nonce as the genuine
instance identifiers, and random bits instead of the proof. Peers instance identifiers, and random bits instead of the proof. Peers
should be able to quickly discard these fake instances, as the proof should be able to quickly discard these fake instances, as the proof
will not match any of the values that they expect. One plausible will not match any of the values that they expect. One plausible
padding strategy is to ensure that the total number of published padding strategy is to ensure that the total number of published
instances, either fake or genuine, matches one of a few values such instances, either fake or genuine, matches one of a few values such
as 16, 32, 64, or higher powers of 2. as 16, 32, 64, or higher powers of 2.
6. IANA Considerations 5. IANA Considerations
This draft does not require any IANA action. This draft does not require any IANA action.
7. Acknowledgments 6. Acknowledgments
This draft results from initial discussions with Dave Thaler, and This draft results from initial discussions with Dave Thaler, and
encouragements from the DNS-SD working group members. We would like encouragements from the DNS-SD working group members. We would like
to thank Stephane Bortzmeyer and Ted Lemon for their detailed reviews to thank Stephane Bortzmeyer and Ted Lemon for their detailed reviews
of the working draft. of the working draft.
8. References 7. References
8.1. Normative References 7.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>. <https://www.rfc-editor.org/info/rfc2045>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 23, line 5 skipping to change at page 20, line 5
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
8.2. Informative References 7.2. Informative References
[I-D.ietf-dnssd-pairing] [I-D.ietf-dnssd-pairing]
Huitema, C. and D. Kaiser, "Device Pairing Using Short Huitema, C. and D. Kaiser, "Device Pairing Using Short
Authentication Strings", draft-ietf-dnssd-pairing-03 (work Authentication Strings", draft-ietf-dnssd-pairing-04 (work
in progress), September 2017. in progress), April 2018.
[I-D.ietf-dnssd-prireq]
Huitema, C., "DNS-SD Privacy and Security Requirements",
draft-ietf-dnssd-prireq-00 (work in progress), September
2018.
[I-D.ietf-dnssd-privacyscaling]
Huitema, C., "DNS-SD Privacy Scaling Tradeoffs", draft-
ietf-dnssd-privacyscaling-00 (work in progress), September
2018.
[I-D.ietf-dnssd-push] [I-D.ietf-dnssd-push]
Pusateri, T. and S. Cheshire, "DNS Push Notifications", Pusateri, T. and S. Cheshire, "DNS Push Notifications",
draft-ietf-dnssd-push-14 (work in progress), March 2018. draft-ietf-dnssd-push-15 (work in progress), September
2018.
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-28 (work in progress), Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
March 2018. March 2018.
[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>.
skipping to change at page 23, line 37 skipping to change at page 20, line 48
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>.
[KW14b] Kaiser, D. and M. Waldvogel, "Efficient Privacy Preserving [KW14b] Kaiser, D. and M. Waldvogel, "Efficient Privacy Preserving
Multicast DNS Service Discovery", Multicast DNS Service Discovery",
DOI 10.1109/HPCC.2014.141, 2014, DOI 10.1109/HPCC.2014.141, 2014,
<http://ieeexplore.ieee.org/xpl/ <http://ieeexplore.ieee.org/xpl/
articleDetails.jsp?arnumber=7056899>. articleDetails.jsp?arnumber=7056899>.
[RFC1033] Lottor, M., "Domain Administrators Operations Guide",
RFC 1033, DOI 10.17487/RFC1033, November 1987,
<https://www.rfc-editor.org/info/rfc1033>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/info/rfc2782>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>. <https://www.rfc-editor.org/info/rfc6762>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015, DOI 10.17487/RFC7626, August 2015,
 End of changes. 58 change blocks. 
279 lines changed or deleted 116 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/