draft-ietf-dnssd-privacy-00.txt   draft-ietf-dnssd-privacy-01.txt 
Network Working Group C. Huitema Network Working Group C. Huitema
Internet-Draft Internet-Draft Private Octopus Inc.
Intended status: Standards Track D. Kaiser Intended status: Standards Track D. Kaiser
Expires: April 29, 2017 University of Konstanz Expires: September 11, 2017 University of Konstanz
October 26, 2016 March 10, 2017
Privacy Extensions for DNS-SD Privacy Extensions for DNS-SD
draft-ietf-dnssd-privacy-00.txt draft-ietf-dnssd-privacy-01.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 April 29, 2017. This Internet-Draft will expire on September 11, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
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 . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 4
2. Privacy Implications of DNS-SD . . . . . . . . . . . . . . . 3 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 . . . . . . . 6
3. Design of the Private DNS-SD Discovery Service . . . . . . . 7 3. Design of the Private DNS-SD Discovery Service . . . . . . . 7
3.1. Device Pairing . . . . . . . . . . . . . . . . . . . . . 7 3.1. Device Pairing . . . . . . . . . . . . . . . . . . . . . 8
3.2. Discovery of the Private Discovery Service . . . . . . . 8 3.2. Discovery of the Private Discovery Service . . . . . . . 8
3.3. Private Discovery Service . . . . . . . . . . . . . . . . 9 3.2.1. Obfuscated Instance Names . . . . . . . . . . . . . . 8
3.3.1. A Note on Private DNS Services . . . . . . . . . . . 10 3.2.2. Using a Predictable Nonce . . . . . . . . . . . . . . 9
3.4. Randomized Host Names . . . . . . . . . . . . . . . . . . 11 3.2.3. Using a Short Proof . . . . . . . . . . . . . . . . . 10
3.5. Timing of Obfuscation and Randomization . . . . . . . . . 11 3.2.4. Direct Queries . . . . . . . . . . . . . . . . . . . 11
4. Private Discovery Service Specification . . . . . . . . . . . 11 3.3. Private Discovery Service . . . . . . . . . . . . . . . . 11
4.1. Host Name Randomization . . . . . . . . . . . . . . . . . 12 3.3.1. A Note on Private DNS Services . . . . . . . . . . . 12
4.2. Device Pairing . . . . . . . . . . . . . . . . . . . . . 12 3.4. Randomized Host Names . . . . . . . . . . . . . . . . . . 13
4.3. Private Discovery Server . . . . . . . . . . . . . . . . 12 3.5. Timing of Obfuscation and Randomization . . . . . . . . . 13
4.3.1. Establishing TLS Connections . . . . . . . . . . . . 13 4. Private Discovery Service Specification . . . . . . . . . . . 14
4.4. Publishing Private Discovery Service Instances . . . . . 14 4.1. Host Name Randomization . . . . . . . . . . . . . . . . . 14
4.5. Discovering Private Discovery Service Instances . . . . . 14 4.2. Device Pairing . . . . . . . . . . . . . . . . . . . . . 14
4.6. Using the Private Discovery Service . . . . . . . . . . . 15 4.3. Private Discovery Server . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 4.3.1. Establishing TLS Connections . . . . . . . . . . . . 15
5.1. Attacks Against the Pairing System . . . . . . . . . . . 15 4.4. Publishing Private Discovery Service Instances . . . . . 15
5.2. Denial of Discovery of the Private Discovery Service . . 16 4.5. Discovering Private Discovery Service Instances . . . . . 16
4.6. Direct Discovery of Private Discovery Service Instances . 17
4.7. Using the Private Discovery Service . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5.1. Attacks Against the Pairing System . . . . . . . . . . . 18
5.2. Denial of Discovery of the Private Discovery Service . . 18
5.3. Replay Attacks Against Discovery of the Private Discovery 5.3. Replay Attacks Against Discovery of the Private Discovery
Service . . . . . . . . . . . . . . . . . . . . . . . . . 16 Service . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4. Denial of Private Discovery Service . . . . . . . . . . . 16 5.4. Denial of Private Discovery Service . . . . . . . . . . . 19
5.5. Replay Attacks against the Private Discovery Service . . 17 5.5. Replay Attacks against the Private Discovery Service . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
DNS-SD [RFC6763] enables distribution and discovery in local networks DNS-SD [RFC6763] over mDNS [RFC6762] enables configurationless
without configuration. It is very convenient for users, but it service discovery in local networks. It is very convenient for
requires the public exposure of the offering and requesting users, but it requires the public exposure of the offering and
identities along with information about the offered and requested requesting identities along with information about the offered and
services. Some of the information published by the announcements can requested services. Some of the information published by the
be very revealing. These privacy issues and potential solutions are announcements can be very revealing. These privacy issues and
discussed in [KW14a] and [KW14b]. potential 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
using DNS-SD [RFC6763]. One of the devices will publish the using DNS-SD [RFC6763] over mDNS [RFC6762]. One of the devices will
availability of a service, such as a picture library or a file store publish the availability of a service, such as a picture library or a
in our examples. The user of the other device will discover this file store in our examples. The user of the other device will
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 Section 2, we find that the DNS-SD
messages leak identifying information such as the instance name, the messages leak identifying information such as the instance name, the
host name or service properties. We review the design constraint of host name or service properties. We review the design constraint of
a solution in Section 3, and describe the proposed solution in a solution in Section 3, and describe the proposed solution in
Section 4. Section 4.
While we focus on a mDNS-based distribution of the DNS-SD resource
records, our solution is agnostic about the distribution method and
also works with other distribution methods, e.g. the classical
hierarchical DNS.
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. Privacy Implications of DNS-SD
DNS-Based Service Discovery (DNS-SD) is defined in [RFC6763]. It DNS-Based Service Discovery (DNS-SD) is defined in [RFC6763]. It
allows nodes to publish the availability of an instance of a service allows nodes to publish the availability of an instance of a service
skipping to change at page 5, line 15 skipping to change at page 5, line 29
supporting chat application. This information is not just available supporting chat application. This information is not just available
to devices actively browsing for and offering services, but to to devices actively browsing for and offering services, but to
anybody passively 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
[I-D.ietf-intarea-hostname-practice]. Depending on naming practices, [RFC8117]. Depending on naming practices, the host name is either a
the host name is either a strong identifier of the device, or at a strong identifier of the device, or at a minimum a partial
minimum a partial identifier. It enables tracking of the device, and identifier. It enables tracking of the device, and by extension of
by extension of the device's owner. 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 and 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
skipping to change at page 7, line 16 skipping to change at page 7, line 23
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], solution is largely based on the architecture proposed in [KW14b],
which separates the general private discovery problem in three 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
[I-D.kaiser-dnssd-pairing]. [I-D.ietf-dnssd-pairing].
The further two components are online (in contrast to pairing they The further two components are online (in contrast to pairing they
are performed anew each time joining a network) and compose the two are performed anew each time joining a network) and compose the two
service discovery stages, namely service discovery stages, namely
o Discovery of the Private Discovery Service -- the first stage -- o Discovery of the Private Discovery Service -- the first stage --
in which hosts discover the Private Discovery Service (PDS), a in which hosts discover the Private Discovery Service (PDS), a
special service offered by every host supporting our extension. special service offered by every host supporting our extension.
After the discovery, hosts connect to the PSD offered by paired After the discovery, hosts connect to the PSD offered by paired
peers. peers.
skipping to change at page 8, line 6 skipping to change at page 8, line 17
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.kaiser-dnssd-pairing] as pairing document, we leverage [I-D.ietf-dnssd-pairing] as 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 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
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 discovered using regular DNS-SD procedures, but the instances can be discovered using regular DNS-SD procedures, but the
list of discovered services will have to be filtered so only paired list of discovered services will have to be filtered so only paired
devices are retained. devices are retained.
The discovery relies on the advertisement of "proofs" by the 3.2.1. Obfuscated Instance Names
publishers of the service. Each proof is the hash of a nonce with
the key shared between the publisher and one of the paired devices.
In order to reduce the overall number of messages, we use a special
encoding of the instance name. Suppose that the publisher manages N
pairings with the associated keys K1, K2, ... Kn. The instance name
will be set to an encoding of N "proofs" of the N keys, where each
proof is computed as function of the key and a nonce:
instance name = <nonce><F1><F2>..<Fn> The instance names for the Private Discovery Service are obfuscated,
so that authorized peers can associate the instance with its
publisher, but unauthorized peers can only observe what looks like a
random name. To achieve this, the names are composed as the
concatenation of a nonce and a proof, which is composed by hashing
the nonce with a pairing key:
Fi = hash (nonce, Ki), where hash is a cryptographic hash PrivateInstanceName = <nonce>|<proof>
function. proof = hash(<nonce>|<key>)
The querier can test the instance name by computing the same "proof" The publisher will publish as many instances as it has established
for each of its own keys. Suppose that the receiver manages P pairings.
pairings, with the corresponding keys X1, X2, .. Xp. The receiver
verification procedure will be:
for each received instance name: The discovering party that looks for instances of the service will
retrieve nonce from instance name receive lists of advertisements from nodes present on the network.
for (j = 1 to P) For each advertisement, it will parse the instance name, and then,
retrieve the key Xj of pairing number j for each available pairing key, compares the proof to the hash of the
compute F = hash(nonce, Xj) nonce concatenated with this pairing key. If there is no match, it
for (i=1 to N) discards the instance name. If there is a match, it has discovered a
retrieve the proof Fi peer.
if F is equal to Fi
mark the pairing number j as available
The procedure presented here requires on average O(M*N) iterations of 3.2.2. Using a Predictable Nonce
the hash function. It also requires O(M*N^2) comparison operations,
but these are less onerous than cryptographic operations. Further,
when setting the nonce to a timestamp, the Fi have to be calculated
only once per time interval.
The number of pairing proofs that can be encoded in a single record Assume that there are N nodes on the local scope, and that each node
is limited by the maximum size of a DNS label, which is 63 bytes. has on average M pairings. Each node will publish on average M
Since this are characters and not pure binary values, nonce and records, and the node engaging in discovery may have to process on
proofs will have to be encoded using BASE64 ([RFC2045] section 6.8), average N*M instance names. The discovering node will have to
resulting in at most 378 bits. The nonce should not be repeated, and compute on average M potential hashes for each nonce. The number of
the simplest way to achieve that is to set the nonce to a 32 bit hash computations would scale as O(N*M*M), which means that it could
timestamp value. The remaining 346 bits could encode up to 10 proofs cause a significant drain of resource in large networks.
of 32 bits each, which would be sufficient for many practical
scenarios.
In practice, a 32 bit proof should be sufficient to distinguish In order to minimize the amount of computing resource, we suggest
between available devices. However, there is clearly a risk of that the nonce be derived from the current time, for example set to a
collision. The Private Discovery Service as described here will find representation of the current time rounded to some period. With this
the available pairings, but it might also find a spurious number of convention, receivers can predict the nonces that will appear in the
"false positives". The chances of that happening are however quite published instances. They will only need to compute O(M) hashes,
small: less than 0.02% for a device managing 10 pairings and instead of O(N*M*M).
processing 10000 responses.
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
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
to replay attacks. We propose to set a value of about 5 minutes,
which seems to be a reasonable compromise.
Unix defines a 32 bit time stamp as the number of seconds elapsed
since January 1st, 1970 not counting leap seconds. The most
significant 24 bits of this 32 bit number represent the number of 256
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. We will thus use this 24 bit number as nonce, represented
as 3 octets.
Publishers will need to compute O(M) hashes at most once per time
stamp interval. If records can be created "on the fly", publishers
will only need to perform that computation upon receipt of the first
query during a given interval, and cache the computed results for the
remainder of the interval. There are however scenarios in which
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
"classic" DNS server. In such scenarios, publishers will need to
perform the computations and publication exactly once per time stamp
interval.
3.2.3. Using a Short Proof
Devices will have to publish as many instance names as they have
peers. The instance names will have to be represented via a text
string, which means that the binary concatenation of nonce and proof
will have to be encoded using a binary-to-text conversion such as
BASE64 ([RFC2045] section 6.8) or BASE32 ([RFC4648] section 6).
Using long proofs, such as the full output of SHA256 [RFC4055], would
generate fairly long instance names: 48 characters using BASE64, or
56 using BASE56. These long names would inflate the network traffic
required when discovering the privacy service. They would also limit
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
with BASE32.
Shorter proofs lead to shorter messages, which is more efficient as
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
proof computed by a receiver using another key. If a receiver
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
but in the absence of the proper pairwise shared key, the connection
will fail. This will not create an actual error, but the probability
of such events should be kept low.
The following table provides the probability that a discovery agent
maintaining 100 pairings will observe a collision after receiving
100000 advertisement records. It also provides the number of
characters required for the encoding of the corresponding instance
name in BASE64 or BASE32, assuming 24 bit nonces.
+-------+------------+--------+--------+
| Proof | Collisions | BASE64 | BASE32 |
+-------+------------+--------+--------+
| 24 | 5.96046% | 8 | 16 |
| 32 | 0.02328% | 11 | 16 |
| 40 | 0.00009% | 12 | 16 |
| 48 | 3.6E-09 | 12 | 16 |
| 56 | 1.4E-11 | 15 | 16 |
+-------+------------+--------+--------+
Table 1
The table shows that for a proof, 24 bits would be too short. 32 bits
might be long enough, but the BASE64 encoding requires padding if the
input is not an even multiple of 24 bits, and BASE32 requires padding
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
BASE32. The resulting instance name will be either 12 characters
long with BASE64, allowing 54 advertisements in an 1500 byte mDNS
message, or 16 characters long with BASE32, allowing 47
advertisements per message.
In the specification section, we will assume BASE64, and 48 bit
proofs composed of the first 6 bytes of a SHA256 hash.
3.2.4. Direct Queries
The preceding sections assume that the discovery is performed using
the classic DNS-SD process, in which a query for all available
"instance names" of a service provides a list of PTR records. The
discoverer will then select the instance names that correspond to its
peers, and request the SRV and TXT records corresponding to the
service instance, and then obtain the relevant A or AAAA records.
This is generally required in DNS-SD because the instance names are
not known in advance, but for the Private Discovery Service the
instance names can be predicted, and a more efficient Direct Query
method can be used.
At a given time, the node engaged in discovery can predict the nonce
that its peer will use, since that nonce is composed by rounding the
current time. The node can also compute the proofs that its peers
might use, since it knows the nonce and the keys. The node can thus
build a list of instance names, and directly query the SRV records
corresponding to these names. If peers are present, they will answer
directly.
This "direct query" process will result in fewer network messages
than the regular DNS-SD query process in some circumstances,
depending on the number of peers per node and the number of nodes
publishing the presence discovery service in the desired scope.
When using mDNS, it is possible to pack multiple queries in a single
broadcast message. Using name compression and 12 characters per
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
the queries, resulting in significant efficiency gains in wireless
networks.
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
skipping to change at page 10, line 23 skipping to change at page 12, line 39
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 "hint" 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 is also working on an UDP variant, DNS over DTLS
[I-D.ietf-dprive-dnsodtls], which would also be a candidate. [I-D.ietf-dprive-dnsodtls], which would also be a candidate.
DPRIVE and Private Discovery solve however two somewhat different DPRIVE and Private Discovery solve however two somewhat different
skipping to change at page 11, line 13 skipping to change at page 13, line 26
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 name in the SRV records, nodes
could publish a randomized name. That is the solution argued for in could publish a randomized name. That is the solution argued for in
[I-D.ietf-intarea-hostname-practice]. [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
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 [I-D.ietf-intarea-hostname-practice], which The problem is handled in [RFC8117], which recommends to pick a new
recommends to pick a new random host name at the time of connecting random host name at the time of connecting to a new network. New
to a new network. New instance names for the Private Discovery instance names for the Private Discovery Services should be composed
Services should be composed at the same time. at the same time.
4. Private Discovery Service Specification 4. 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.
skipping to change at page 12, line 31 skipping to change at page 14, line 45
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 4.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.kaiser-dnssd-pairing] to establish these secrets. [I-D.ietf-dnssd-pairing] to establish these secrets.
[[TODO: Should we support mutually authenticated certificates? They [[TODO: Should we support mutually authenticated certificates? They
can also be used to initiate TLS and have several advantages, i.e. can also be used to initiate TLS and have several advantages, i.e.
allow setting an expiry date.]] allow setting an expiry date.]]
4.3. Private Discovery Server 4.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
skipping to change at page 13, line 9 skipping to change at page 15, line 22
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 4.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. pairing MUST be used as PSK. To guarantee interoperability,
implementations of the Private Name Server MUST support
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 composed as follows, using the identifying the pre-shared key MUST be identical to the "Instance
conventions of TLS [RFC7858]: Identifier" defined in Section 4.4, i.e. 24 bit nonce and 48 bit
proof encoded in BASE64 as 12 character string. The server will use
struct { the pairing key associated with this instance identifier.
uint32 gmt_unix_time;
opaque random_bytes[4];
} nonce;
long_proof = HASH(nonce | pairing_key )
proof = first 12 bytes of long_proof
psk_identity = BASE64(nonce) "." BASE64(proof)
In this formula, HASH SHOULD be the function SHA256 defined in
[RFC4055]. Implementers MAY eventually replace SHA256 with a
stronger algorithm, in which cases both clients and servers will have
to agree on that algorithm during the pairing process. The first 32
bits of the nonce are set to the current time and date in standard
UNIX 32-bit format (seconds since the midnight starting Jan 1, 1970,
UTC, ignoring leap seconds) according to the client's internal clock.
The next 32 bits of the nonce are set to a value generated by a
secure random number generator.
In this formula, the identity is finally set to a character string,
using BASE64 ([RFC2045] section 6.8). This transformation is meant
to comply with the PSK identity encoding rules specified in section
5.1 of [RFC4279].
The server will check the received key identity, trying the key
against the valid keys established through pairing. If one of the
keys matches, the TLS connection is accepted, otherwise it is
declined.
4.4. Publishing Private Discovery Service Instances 4.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._tls". "_pds._tcp".
Each published instance describes one server and up to 10 pairings. Each published instance describes one server and one pairing. In the
In the case where a node manages more than 10 pairings, it should case where a node manages more than one pairing, it should publish as
publish as many instances as necessary to advertise all available many instances as necessary to advertise all available pairings.
pairings.
Each instance name is composed as follows: Each instance name is composed as follows:
pick a 32 bit nonce, e.g. using the Unix GMT time. pick a 24 bit nonce, set to the 24 most
set the binary identifier to the nonce. significant bits of the 32 bit Unix GMT time.
for each of up to 10 pairings compute a 48 bit proof:
hint = first 32 bits of HASH(<nonce>|<pairing key>) proof = first 48 bits of HASH(<nonce>|<pairing key>)
concatenate the hint to the binary identifier
set the 72 bit binary identifier as the concatenation
of nonce and proof
set instance-ID = BASE64(binary identifier) set instance-ID = 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 32 bit nonce and up to 10 pairing hints result a concatenation of a 24 bit nonce and 48 bit proof result in a 72 bit
bit string at most 352 bit long. The BASE64 conversion will produce string. The BASE64 conversion is 12 characters long per [RFC6763].
a string that is up to 59 characters long, which fits within the 63
characters limit defined in [RFC6763].
4.5. Discovering Private Discovery Service Instances 4.5. Discovering Private Discovery Service Instances
Nodes that wish to discover Private Discovery Service Instances will Nodes that wish to discover Private Discovery Service Instances
issue a DNS-SD discovery request for the service type. These request SHOULD issue a DNS-SD discovery request for the service type
will return a series of PTR records, providing the names of the "_pds._tcp". They MAY, as an alternative, use the Direct Discovery
instances present in the scope. procedure defined in Section 4.6. If nodes send a DNS-SD discovery
request, they will receive in response a series of PTR records,
providing the names of the instances present in the scope.
The querier SHOULD examine each instance to see whether it hints at The querier SHOULD examine each instance to see whether it
one of its available pairings, according to the following conceptual corresponds to one of its available pairings, according to the
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 a not multiple of 32 bits, if the binary instance length is not multiple 72 bits,
discard the instance. discard the instance.
nonce = first 32 bits of binary. nonce = first 24 bits of binary.
for each 32 bit hint after the nonce
for each available pairing if nonce does not match the first 24 bits of the current
retrieve the key Xj of pairing number j time plus or minus 1 minute, discard the instance.
compute F = hash(nonce, Xj)
if F is equal to the 32 bit hint for each available pairing
mark the pairing number j as available retrieve the key Xj of pairing number j
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,
while not mandating a time synchronization precision better than one
minute.
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. Using the Private Discovery Service 4.6. Direct Discovery of Private Discovery Service Instances
Nodes that wish to discover Private Discovery Service Instances MAY
use the following Direct Discovery procedure instead of the regular
DNS-SD Discovery explained in Section 4.5.
To perform Direct Discovery, nodes should compose a list of Private
Discovery Service Instances Names. There will be one name for each
pairing available to the node. The Instance ID for each name will be
composed of a nonce and a proof, using the algorithm specified in
Section 4.4.
The querier will issue SRV record queries for each of these names.
The queries will only succeed if the corresponding instance is
present, in which case a pairing is discovered. After that, the
querier SHOULD try connecting to the corresponding instance, as
explained in Section 4.4.
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 to protect the privacy of service
publishing nodes. This is especially useful when operating in a publishing nodes. This is especially useful when operating in a
public space. Hiding the identity of the publishing nodes prevents public space. Hiding the identity of the publishing nodes prevents
skipping to change at page 16, line 5 skipping to change at page 18, line 14
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.
Attacks on pairing systems are detailed in Attacks on pairing systems are detailed in [I-D.ietf-dnssd-pairing].
[I-D.kaiser-dnssd-pairing].
5.2. Denial of Discovery of the Private Discovery Service 5.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 4.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 is amplified because the clients need 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. One possible mitigation would be to require that such nonces names. This is mitigated by the specification of nonces as rounded
correspond to rounded timestamps. If we assume that timestamps must time stamps in Section 4.5. If we assume that timestamps must not be
not be too old, there will be a finite number of valid rounded too old, there will be a finite number of valid rounded timestamps at
timestamps at any time. Even if there are many instances present, any time. Even if there are many instances present, they would all
they would all pick their nonces from this small number of rounded pick their nonces from this small number of rounded timestamps, and a
timestamps, and a smart client could make sure that proofs are only smart client will make sure that proofs are only computed once per
computed once per valid time stamp. valid time stamp.
5.3. Replay Attacks Against Discovery of the Private Discovery Service 5.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 32 The binary instance identifiers defined in Section 4.4 start with 24
bits encoding the "UNIX" time. In order to protect against replay bits encoding the most significant bits of the "UNIX" time. In order
attacks, clients MAY verify that this time is reasonably recent. to protect against replay attacks, clients SHOULD verify that this
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.]] both scope and time would really mitigate that attack. For example,
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
size of the instance ID.]]
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 17, line 27 skipping to change at page 19, line 40
5.5. Replay Attacks against the Private Discovery Service 5.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 32 bits The PSK identifiers defined in Section 4.3.1 start with the 24 most
encoding the "UNIX" time. In order to mitigate replay attacks, significant bits of the "UNIX" time. In order to mitigate replay
servers SHOULD verify that this time is reasonably recent, and fail attacks, servers SHOULD verify that this time is reasonably recent,
the connection if it is too old, or if it occurs too far in the and fail the connection if it is too old, or if it occurs too far in
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.
6. IANA Considerations 6. IANA Considerations
This draft does not require any IANA action. (Or does it? What This draft does not require any IANA action. (Or does it? What
skipping to change at page 18, line 47 skipping to change at page 21, line 11
(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,
<http://www.rfc-editor.org/info/rfc5246>. <http://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,
<http://www.rfc-editor.org/info/rfc6763>. <http://www.rfc-editor.org/info/rfc6763>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-dnssd-pairing]
Huitema, C. and D. Kaiser, "Device Pairing Using Short
Authentication Strings", draft-ietf-dnssd-pairing-01 (work
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-08 (work in progress), July 2016. draft-ietf-dnssd-push-09 (work in progress), October 2016.
[I-D.ietf-dprive-dnsodtls] [I-D.ietf-dprive-dnsodtls]
Reddy, T., Wing, D., and P. Patil, "Specification for DNS Reddy, T., Wing, D., and P. Patil, "Specification for DNS
over Datagram Transport Layer Security (DTLS)", draft- over Datagram Transport Layer Security (DTLS)", draft-
ietf-dprive-dnsodtls-12 (work in progress), September ietf-dprive-dnsodtls-15 (work in progress), December 2016.
2016.
[I-D.ietf-intarea-hostname-practice]
Huitema, C., Thaler, D., and R. Winter, "Current Hostname
Practice Considered Harmful", draft-ietf-intarea-hostname-
practice-03 (work in progress), July 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-18 (work in progress),
October 2016. October 2016.
[I-D.kaiser-dnssd-pairing]
Huitema, C. and D. Kaiser, "Device Pairing Using Short
Authentication Strings", draft-kaiser-dnssd-pairing-00
(work in progress), September 2016.
[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/
articleDetails.jsp?arnumber=7056899>. articleDetails.jsp?arnumber=7056899>.
skipping to change at page 20, line 5 skipping to change at page 22, line 10
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000, DOI 10.17487/RFC2782, February 2000,
<http://www.rfc-editor.org/info/rfc2782>. <http://www.rfc-editor.org/info/rfc2782>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://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,
<http://www.rfc-editor.org/info/rfc6762>. <http://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,
<http://www.rfc-editor.org/info/rfc7626>. <http://www.rfc-editor.org/info/rfc7626>.
[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>.
[RFC8117] Huitema, C., Thaler, D., and R. Winter, "Current Hostname
Practice Considered Harmful", RFC 8117,
DOI 10.17487/RFC8117, March 2017,
<http://www.rfc-editor.org/info/rfc8117>.
Authors' Addresses Authors' Addresses
Christian Huitema Christian Huitema
Private Octopus Inc.
Friday Harbor, WA 98250 Friday Harbor, WA 98250
U.S.A. U.S.A.
Email: huitema@huitema.net Email: huitema@huitema.net
URI: http://privateoctopus.com/
Daniel Kaiser Daniel Kaiser
University of Konstanz University of Konstanz
Konstanz 78457 Konstanz 78457
Germany Germany
Email: daniel.kaiser@uni-konstanz.de Email: daniel.kaiser@uni-konstanz.de
 End of changes. 54 change blocks. 
202 lines changed or deleted 320 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/