draft-ietf-dnssd-privacy-01.txt   draft-ietf-dnssd-privacy-02.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: September 11, 2017 University of Konstanz Expires: January 4, 2018 University of Konstanz
March 10, 2017 July 3, 2017
Privacy Extensions for DNS-SD Privacy Extensions for DNS-SD
draft-ietf-dnssd-privacy-01.txt draft-ietf-dnssd-privacy-02.txt
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.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 September 11, 2017. This Internet-Draft will expire on January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
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. Privacy Implications of DNS-SD . . . . . . . . . . . . . . . 4
2.1. Privacy Implication of Publishing Service Instance Names 4 2.1. Privacy Implication of Publishing Service Instance Names 4
2.2. Privacy Implication of Publishing Node Names . . . . . . 5 2.2. Privacy Implication of Publishing Node Names . . . . . . 5
2.3. Privacy Implication of Publishing Service Attributes . . 5 2.3. Privacy Implication of Publishing Service Attributes . . 5
2.4. Device Fingerprinting . . . . . . . . . . . . . . . . . . 6 2.4. Device Fingerprinting . . . . . . . . . . . . . . . . . . 6
2.5. Privacy Implication of Discovering Services . . . . . . . 6 2.5. Privacy Implication of Discovering Services . . . . . . . 7
3. Design of the Private DNS-SD Discovery Service . . . . . . . 7 3. Design of the Private DNS-SD Discovery Service . . . . . . . 7
3.1. Device Pairing . . . . . . . . . . . . . . . . . . . . . 8 3.1. Device Pairing . . . . . . . . . . . . . . . . . . . . . 8
3.2. Discovery of the Private Discovery Service . . . . . . . 8 3.2. Discovery of the Private Discovery Service . . . . . . . 8
3.2.1. Obfuscated Instance Names . . . . . . . . . . . . . . 8 3.2.1. Obfuscated Instance Names . . . . . . . . . . . . . . 9
3.2.2. Using a Predictable Nonce . . . . . . . . . . . . . . 9 3.2.2. Using a Predictable Nonce . . . . . . . . . . . . . . 9
3.2.3. Using a Short Proof . . . . . . . . . . . . . . . . . 10 3.2.3. Using a Short Proof . . . . . . . . . . . . . . . . . 10
3.2.4. Direct Queries . . . . . . . . . . . . . . . . . . . 11 3.2.4. Direct Queries . . . . . . . . . . . . . . . . . . . 12
3.3. Private Discovery Service . . . . . . . . . . . . . . . . 11 3.3. Private Discovery Service . . . . . . . . . . . . . . . . 12
3.3.1. A Note on Private DNS Services . . . . . . . . . . . 12 3.3.1. A Note on Private DNS Services . . . . . . . . . . . 13
3.4. Randomized Host Names . . . . . . . . . . . . . . . . . . 13 3.4. Randomized Host Names . . . . . . . . . . . . . . . . . . 14
3.5. Timing of Obfuscation and Randomization . . . . . . . . . 13 3.5. Timing of Obfuscation and Randomization . . . . . . . . . 14
4. Private Discovery Service Specification . . . . . . . . . . . 14 4. Private Discovery Service Specification . . . . . . . . . . . 14
4.1. Host Name Randomization . . . . . . . . . . . . . . . . . 14 4.1. Host Name Randomization . . . . . . . . . . . . . . . . . 15
4.2. Device Pairing . . . . . . . . . . . . . . . . . . . . . 14 4.2. Device Pairing . . . . . . . . . . . . . . . . . . . . . 15
4.3. Private Discovery Server . . . . . . . . . . . . . . . . 15 4.3. Private Discovery Server . . . . . . . . . . . . . . . . 15
4.3.1. Establishing TLS Connections . . . . . . . . . . . . 15 4.3.1. Establishing TLS Connections . . . . . . . . . . . . 16
4.4. Publishing Private Discovery Service Instances . . . . . 15 4.4. Publishing Private Discovery Service Instances . . . . . 16
4.5. Discovering Private Discovery Service Instances . . . . . 16 4.5. Discovering Private Discovery Service Instances . . . . . 17
4.6. Direct Discovery of Private Discovery Service Instances . 17 4.6. Direct Discovery of Private Discovery Service Instances . 18
4.7. Using the Private Discovery Service . . . . . . . . . . . 17 4.7. Using the Private Discovery Service . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5.1. Attacks Against the Pairing System . . . . . . . . . . . 18 5.1. Attacks Against the Pairing System . . . . . . . . . . . 19
5.2. Denial of Discovery of the Private Discovery Service . . 18 5.2. Denial of Discovery of the Private Discovery Service . . 19
5.3. Replay Attacks Against Discovery of the Private Discovery 5.3. Replay Attacks Against Discovery of the Private Discovery
Service . . . . . . . . . . . . . . . . . . . . . . . . . 18 Service . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.4. Denial of Private Discovery Service . . . . . . . . . . . 19 5.4. Denial of Private Discovery Service . . . . . . . . . . . 20
5.5. Replay Attacks against the Private Discovery Service . . 19 5.5. Replay Attacks against the Private Discovery Service . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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. Some of the information published by the requested services. Parts of the published information can seriously
announcements can be very revealing. These privacy issues and breach the user's privacy. These privacy issues and potential
potential solutions are discussed in [KW14a] and [KW14b]. solutions are discussed in [KW14a] and [KW14b].
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
skipping to change at page 5, line 31 skipping to change at page 5, line 31
anybody passively listing to the network traffic. anybody passively listing to the network traffic.
2.2. Privacy Implication of Publishing Node Names 2.2. Privacy Implication of Publishing Node Names
The SRV records contain the DNS name of the node publishing the The SRV records contain the DNS name of the node publishing the
service. Typical implementations construct this DNS name by service. Typical implementations construct this DNS name by
concatenating the "host name" of the node with the name of the local concatenating the "host name" of the node with the name of the local
domain. The privacy implications of this practice are reviewed in domain. The privacy implications of this practice are reviewed in
[RFC8117]. Depending on naming practices, the host name is either a [RFC8117]. Depending on naming practices, the host name is either a
strong identifier of the device, or at a minimum a partial strong identifier of the device, or at a minimum a partial
identifier. It enables tracking of the device, and by extension of identifier. It enables tracking of both the device, and, by
the device's owner. extension, the device's owner.
2.3. Privacy Implication of Publishing Service Attributes 2.3. Privacy Implication of Publishing Service Attributes
The TXT record's attribute and value pairs contain information on the The TXT record's attribute-value pairs contain information on the
characteristics of the corresponding service instance. This in turn characteristics of the corresponding service instance. This in turn
reveals information about the devices that publish services. The reveals information about the devices that publish services. The
amount of information varies widely with the particular service and amount of information varies widely with the particular service and
its implementation: its implementation:
o Some attributes like the paper size available in a printer, are o Some attributes like the paper size available in a printer, are
the same on many devices, and thus only provide limited the same on many devices, and thus only provide limited
information to a tracker. information to a tracker.
o Attributes that have freeform values, such as the name of a o Attributes that have freeform values, such as the name of a
skipping to change at page 6, line 37 skipping to change at page 6, line 37
o The port numbers used by the services. o The port numbers used by the services.
o The values of the priority and weight attributes in the SRV o The values of the priority and weight attributes in the SRV
records. records.
This combination of services and attributes will often be sufficient This combination of services and attributes will often be sufficient
to identify the version of the software running on a device. If a to identify the version of the software running on a device. If a
device publishes many services with rich sets of attributes, the device publishes many services with rich sets of attributes, the
combination may be sufficient to identify the specific device. combination may be sufficient to identify the specific device.
There is however an argument that devices providing services can be A sometimes heard argument is that devices providing services can be
discovered by observing the local traffic, and that trying to hide identified by observing the local traffic, and that trying to hide
the presence of the service is futile. The same argument can be the presence of the service is futile. This argument, however, does
extended to say that the pattern of services offered by a device not carry much weight because
allows for fingerprinting the device. This may or may not be true,
since we can expect that services will be designed or updated to 1. proving privacy at the discovery layer is of the essence for
avoid leaking fingerprints. In any case, the design of the discovery enabling automatically configured privacy-preserving network
service should avoid making a bad situation worse, and should as much applications. Application layer protocols are not forced to
as possible avoid providing new fingerprinting information. 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 2.5. Privacy Implication of Discovering Services
The consumers of services engage in discovery, and in doing so reveal The consumers of services engage in discovery, and in doing so reveal
some information such as the list of services they are interested in 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 and the domains in which they are looking for the services. When the
clients select specific instances of services, they reveal their clients select specific instances of services, they reveal their
preference for these instances. This can be benign if the service preference for these instances. This can be benign if the service
type is very common, but it could be more problematic for sensitive type is very common, but it could be more problematic for sensitive
services, such as for example some private messaging services. services, such as for example some private messaging services.
skipping to change at page 8, line 17 skipping to change at page 8, line 32
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 leverage [I-D.ietf-dnssd-pairing] as pairing mechanism. document, we utilize [I-D.ietf-dnssd-pairing] as the pairing
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 3.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
skipping to change at page 9, line 22 skipping to change at page 9, line 42
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
that the nonce be derived from the current time, for example set to a that the nonce be derived from the current time, for example set to a
representation of the current time rounded to some period. With this representation of the current time rounded to some period. With this
convention, receivers can predict the nonces that will appear in the convention, receivers can predict the nonces that will appear in the
published instances. They will only need to compute O(M) hashes, published instances.
instead of O(N*M*M).
The publishers will have to create new records at the end of each The publishers will have to create new records at the end of each
rounding period. If the rounding period is set too short, they will rounding period. If the rounding period is set too short, they will
have to repeat that very often, which is inefficient. On the other have to repeat that very often, which is inefficient. On the other
hand, if the rounding period is too long, the system may be exposed hand, if the rounding period is too long, the system may be exposed
to replay attacks. We propose to set a value of about 5 minutes, to replay attacks. We propose to set a value of about 5 minutes,
which seems to be a reasonable compromise. which seems to be a reasonable compromise.
Receivers can pre-calculate all the M relevant proofs once per time
interval and then establish a mapping from the corresponding instance
names to the pairing data in form of a hash table. These M relevant
proofs are the proofs resulting from hashing a host's M pairing keys
alongside the current nonce. Each time they receive an instance
name, they can test in O(1) time if the received service information
is relevant or not.
Unix defines a 32 bit time stamp as the number of seconds elapsed Unix defines a 32 bit time stamp as the number of seconds elapsed
since January 1st, 1970 not counting leap seconds. The most since January 1st, 1970 not counting leap seconds. The most
significant 24 bits of this 32 bit number represent the number of 256 significant 24 bits of this 32 bit number represent the number of 256
seconds intervals since the epoch. 256 seconds correspond to 4 seconds intervals since the epoch. 256 seconds correspond to 4
minutes and 16 seconds, which is close enough to our design goal of 5 minutes and 16 seconds, which is close enough to our design goal of 5
minutes. We will thus use this 24 bit number as nonce, represented minutes. We will thus use this 24 bit number as nonce, represented
as 3 octets. as 3 octets.
For coping with time skew, receivers pre-calculate proofs for the
respective next time interval and store hash tables for the last, the
current, and the next time interval. When receiving a service
instance name, receivers first check whether the nonce corresponds to
the current, the last or the next time interval, and if so, check
whether the instance name is in the corresponding hash table. For
(approximately) meeting our design goal of 5 min validity, the last
time interval may only be considered if the current one is less than
half way over and the next time interval may only be considered if
the current time interval is more than half way over.
Publishers will need to compute O(M) hashes at most once per time Publishers will need to compute O(M) hashes at most once per time
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.
skipping to change at page 10, line 15 skipping to change at page 10, line 50
3.2.3. Using a Short Proof 3.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 BASE56. 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
skipping to change at page 12, line 7 skipping to change at page 12, line 47
3.3. Private Discovery Service 3.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
over TLS defined in [RFC7858]. The main difference with simple DNS over TLS defined in [RFC7858]. The main difference with plain DNS
over TLS is the need for authentication. over TLS is the need for authentication.
We assume that the pairing process has provided each pair of We assume that the pairing process has provided each pair of
authorized client and server with a shared secret. We can use that authorized client and server with a shared secret. We can use that
shared secret to provide mutual authentication of clients and servers shared secret to provide mutual authentication of clients and servers
using "Pre Shared Key" authentication, as defined in [RFC4279] and using "Pre-Shared Key" authentication, as defined in [RFC4279] and
incorporated in the latest version of TLS [I-D.ietf-tls-tls13]. incorporated in the latest version of TLS [I-D.ietf-tls-tls13].
One difficulty is the reliance on a key identifier in the protocol. One difficulty is the reliance on a key identifier in the protocol.
For example, in TLS 1.3 the PSK extension is defined as: For example, in TLS 1.3 the PSK extension is defined as:
opaque psk_identity<0..2^16-1>; opaque psk_identity<0..2^16-1>;
struct { struct {
select (Role) { select (Role) {
case client: case client:
skipping to change at page 12, line 46 skipping to change at page 13, line 39
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 3.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 3.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
is also working on an UDP variant, DNS over DTLS further published an UDP variant, DNS over DTLS [RFC8094], which
[I-D.ietf-dprive-dnsodtls], which would also be a candidate. would also be a candidate.
DPRIVE and Private Discovery solve however two somewhat different DPRIVE and Private Discovery solve however two somewhat different
problems. DPRIVE is concerned with the confidentiality of DNS problems. DPRIVE is concerned with the confidentiality of DNS
transactions, addressing the problems outlined in [RFC7626]. transactions, addressing the problems outlined in [RFC7626].
However, DPRIVE does not address the confidentiality or privacy However, DPRIVE does not address the confidentiality or privacy
issues with publication of services, and is not a direct solution to issues with publication of services, and is not a direct solution to
DNS-SD privacy: DNS-SD privacy:
o Discovery queries are scoped by the domain name within which o Discovery queries are scoped by the domain name within which
services are published. As nodes move and visit arbitrary services are published. As nodes move and visit arbitrary
skipping to change at page 13, line 24 skipping to change at page 14, line 17
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 3.4. Randomized Host Names
Instead of publishing their actual name in the SRV records, nodes Instead of publishing their actual host names in the SRV records,
could publish a randomized name. That is the solution argued for in nodes could publish randomized host names. That is the solution
[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 3.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
skipping to change at page 15, line 45 skipping to change at page 16, line 32
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
many instances as necessary to advertise all available pairings. many instances as necessary to advertise the PDS to all paired peers.
Each instance name is composed as follows: Each instance name is composed as follows:
pick a 24 bit nonce, set to the 24 most pick a 24 bit nonce, set to the 24 most
significant bits of the 32 bit Unix GMT time. significant bits of the 32 bit Unix GMT time.
compute a 48 bit proof: compute a 48 bit proof:
proof = first 48 bits of HASH(<nonce>|<pairing key>) proof = first 48 bits of HASH(<nonce>|<pairing key>)
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-ID = 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 4.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. If nodes send a DNS-SD discovery procedure defined in Section 4.6. If nodes send a DNS-SD discovery
request, they will receive in response a series of PTR records, request, they will receive in response a series of PTR records,
providing the names of the instances present in the scope. providing the names of the instances present in the scope.
For each time interval, the querier SHOULD pre-calculate a hash table
mapping instance names to pairings according to the following
conceptual algorithm:
nonce = 24 bit rounded time stamp of the\
respective next time interval
for each available pairing
retrieve the key Xj of pairing number j
compute F = first 48 bits of hash(nonce, Xj)
construct the binary instance_name as described\
in the previous section
instance_names[nonce][instance_name] = Xj;
The querier SHOULD store the hash tables for the previous, the
current, and the next time interval.
The querier SHOULD examine each instance to see whether it The querier SHOULD examine each instance to see whether it
corresponds to one of its available pairings, according to the corresponds to one of its available pairings, according to the
following conceptual algorithm: following conceptual algorithm:
for each received instance name: for each received instance_name:
convert the instance name to binary using BASE64 convert the instance name to binary using BASE64
if the conversion fails, if the conversion fails,
discard the instance. discard the instance.
if the binary instance length is not multiple 72 bits, if the binary instance length is not multiple 72 bits,
discard the instance. discard the instance.
nonce = first 24 bits of binary. nonce = first 24 bits of binary.
if nonce does not match the first 24 bits of the current Check that the nonce matches the first 24 bits of
time plus or minus 1 minute, discard the instance. the current time, or the previous interval (24 bit number
minus 1) if the current interval is less than half over,
or the next interval (24 bit number plus 1) if the
current interval is more than half over. If the
nonce does not match an acceptable value, discard
the instance.
for each available pairing if ((Xj = instance_names[nonce][instance_name]) != null)
retrieve the key Xj of pairing number j mark the pairing number j as available
compute F = first 48 bits of hash(nonce, Xj)
if F is equal to the last 48 bits of
the binary instance ID
mark the pairing number j as available
The check of the current time is meant to mitigate replay attacks, The check of the current time is meant to mitigate replay attacks,
while not mandating a time synchronization precision better than one while not mandating a time synchronization precision better than two
minute. minutes.
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
hint, which entails a small chance of "false positive" match. This hint, 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 4.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 4.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 ID for each name will be pairing available to the node. The Instance name for each name will
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 4.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 4.4.
4.7. Using the Private Discovery Service 4.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 5. Security Considerations
This document specifies a method to protect the privacy of service This document specifies a method for protecting the privacy of nodes
publishing nodes. This is especially useful when operating in a that offer and query for services. This is especially useful when
public space. Hiding the identity of the publishing nodes prevents operating in a public space. Hiding the identity of the publishing
some forms of "targeting" of high value nodes. However, adversaries nodes prevents some forms of "targeting" of high value nodes.
can attempt various attacks to break the anonymity of the service, or However, adversaries can attempt various attacks to break the
to deny it. A list of these attacks and their mitigations are anonymity of the service, or to deny it. A list of these attacks and
described in the following sections. their mitigations are described in the following sections.
5.1. Attacks Against the Pairing System 5.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 4.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.
skipping to change at page 19, line 9 skipping to change at page 20, line 9
The binary instance identifiers defined in Section 4.4 start with 24 The binary instance identifiers defined in Section 4.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 4.5.
[[TODO: Should we somehow encode the scope in the identifier? Having [[TODO: Should we somehow encode the scope in the identifier? Having
both scope and time would really mitigate that attack. For example, both scope and time would really mitigate that attack. For example,
one could add a local IPv4 or IPv6 prefix in the nonce. However, one could add a local IPv4 or IPv6 prefix in the nonce. However,
this won't work in networks behind NAT. It would also increase the this won't work in networks behind NAT. It would also increase the
size of the instance ID.]] size of the instance name.]]
5.4. Denial of Private Discovery Service 5.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.
skipping to change at page 21, line 18 skipping to change at page 22, line 18
8.2. Informative References 8.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-01 (work Authentication Strings", draft-ietf-dnssd-pairing-01 (work
in progress), March 2017. in progress), March 2017.
[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-09 (work in progress), October 2016. draft-ietf-dnssd-push-11 (work in progress), June 2017.
[I-D.ietf-dprive-dnsodtls]
Reddy, T., Wing, D., and P. Patil, "Specification for DNS
over Datagram Transport Layer Security (DTLS)", draft-
ietf-dprive-dnsodtls-15 (work in progress), December 2016.
[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-18 (work in progress), Version 1.3", draft-ietf-tls-tls13-20 (work in progress),
October 2016. April 2017.
[KW14a] Kaiser, D. and M. Waldvogel, "Adding Privacy to Multicast [KW14a] Kaiser, D. and M. Waldvogel, "Adding Privacy to Multicast
DNS Service Discovery", DOI 10.1109/TrustCom.2014.107, DNS Service Discovery", DOI 10.1109/TrustCom.2014.107,
2014, <http://ieeexplore.ieee.org/xpl/ 2014, <http://ieeexplore.ieee.org/xpl/
articleDetails.jsp?arnumber=7011331>. articleDetails.jsp?arnumber=7011331>.
[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/
skipping to change at page 22, line 32 skipping to change at page 23, line 27
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
Profiles for DHCP Clients", RFC 7844, Profiles for DHCP Clients", RFC 7844,
DOI 10.17487/RFC7844, May 2016, DOI 10.17487/RFC7844, May 2016,
<http://www.rfc-editor.org/info/rfc7844>. <http://www.rfc-editor.org/info/rfc7844>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <http://www.rfc-editor.org/info/rfc7858>. 2016, <http://www.rfc-editor.org/info/rfc7858>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017,
<http://www.rfc-editor.org/info/rfc8094>.
[RFC8117] Huitema, C., Thaler, D., and R. Winter, "Current Hostname [RFC8117] Huitema, C., Thaler, D., and R. Winter, "Current Hostname
Practice Considered Harmful", RFC 8117, Practice Considered Harmful", RFC 8117,
DOI 10.17487/RFC8117, March 2017, DOI 10.17487/RFC8117, March 2017,
<http://www.rfc-editor.org/info/rfc8117>. <http://www.rfc-editor.org/info/rfc8117>.
Authors' Addresses Authors' Addresses
Christian Huitema Christian Huitema
Private Octopus Inc. Private Octopus Inc.
Friday Harbor, WA 98250 Friday Harbor, WA 98250
 End of changes. 36 change blocks. 
88 lines changed or deleted 140 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/