draft-ietf-dnssd-privacy-02.txt   draft-ietf-dnssd-privacy-03.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: January 4, 2018 University of Konstanz Expires: March 14, 2018 University of Konstanz
July 3, 2017 September 10, 2017
Privacy Extensions for DNS-SD Privacy Extensions for DNS-SD
draft-ietf-dnssd-privacy-02.txt draft-ietf-dnssd-privacy-03
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 39 skipping to change at page 1, line 39
pairing system. pairing system.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2018. This Internet-Draft will expire on March 14, 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 (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 45 skipping to change at page 2, line 45
3.2.3. Using a Short Proof . . . . . . . . . . . . . . . . . 10 3.2.3. Using a Short Proof . . . . . . . . . . . . . . . . . 10
3.2.4. Direct Queries . . . . . . . . . . . . . . . . . . . 12 3.2.4. Direct Queries . . . . . . . . . . . . . . . . . . . 12
3.3. Private Discovery Service . . . . . . . . . . . . . . . . 12 3.3. Private Discovery Service . . . . . . . . . . . . . . . . 12
3.3.1. A Note on Private DNS Services . . . . . . . . . . . 13 3.3.1. A Note on Private DNS Services . . . . . . . . . . . 13
3.4. Randomized Host Names . . . . . . . . . . . . . . . . . . 14 3.4. Randomized Host Names . . . . . . . . . . . . . . . . . . 14
3.5. Timing of Obfuscation and Randomization . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . 15 4.1. Host Name Randomization . . . . . . . . . . . . . . . . . 15
4.2. Device Pairing . . . . . . . . . . . . . . . . . . . . . 15 4.2. Device Pairing . . . . . . . . . . . . . . . . . . . . . 15
4.3. Private Discovery Server . . . . . . . . . . . . . . . . 15 4.3. Private Discovery Server . . . . . . . . . . . . . . . . 15
4.3.1. Establishing TLS Connections . . . . . . . . . . . . 16 4.3.1. Establishing TLS Connections . . . . . . . . . . . . 15
4.4. Publishing Private Discovery Service Instances . . . . . 16 4.4. Publishing Private Discovery Service Instances . . . . . 16
4.5. Discovering Private Discovery Service Instances . . . . . 17 4.5. Discovering Private Discovery Service Instances . . . . . 17
4.6. Direct Discovery of Private Discovery Service Instances . 18 4.6. Direct Discovery of Private Discovery Service Instances . 18
4.7. Using the Private Discovery Service . . . . . . . . . . . 18 4.7. Using the Private Discovery Service . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5.1. Attacks Against the Pairing System . . . . . . . . . . . 19 5.1. Attacks Against the Pairing System . . . . . . . . . . . 19
5.2. Denial of Discovery of the Private Discovery Service . . 19 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 . . . . . . . . . . . . . . . . . . . . . . . . . 19 Service . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.4. Denial of Private Discovery Service . . . . . . . . . . . 20 5.4. Denial of Private Discovery Service . . . . . . . . . . . 20
5.5. Replay Attacks against the Private Discovery Service . . 20 5.5. Replay Attacks against the Private Discovery Service . . 20
5.6. Replay attacks and clock synchronization . . . . . . . . 21
5.7. Fingerprinting the number of published instances . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
DNS-SD [RFC6763] over mDNS [RFC6762] enables configurationless DNS-SD [RFC6763] over mDNS [RFC6762] enables configurationless
service discovery in local networks. It is very convenient for service discovery in local networks. It is very convenient for
users, but it requires the public exposure of the offering and users, but it requires the public exposure of the offering and
requesting identities along with information about the offered and requesting identities along with information about the offered and
requested services. Parts of the published information can seriously requested services. Parts of the published information can seriously
breach the user's privacy. These privacy issues and potential breach the user's privacy. These privacy issues and potential
solutions are discussed in [KW14a] and [KW14b]. solutions are discussed in [KW14a] and [KW14b].
skipping to change at page 5, line 21 skipping to change at page 5, line 21
Alice will see the list on her phone and understand intuitively that Alice will see the list on her phone and understand intuitively that
she should pick the first item. The discovery will "just work". she should pick the first item. The discovery will "just work".
However, DNS-SD/mDNS will reveal to anybody that Alice is currently However, DNS-SD/mDNS will reveal to anybody that Alice is currently
visiting the Internet Cafe. It further discloses the fact that she visiting the Internet Cafe. It further discloses the fact that she
uses two devices, shares an image store, and uses a chat application uses two devices, shares an image store, and uses a chat application
supporting the _presence protocol on both of her devices. She might supporting the _presence protocol on both of her devices. She might
currently chat with Bob or Carol, as they are also using a _presence currently chat with Bob or Carol, as they are also using a _presence
supporting chat application. This information is not just available supporting chat application. This information is not just available
to devices actively browsing for and offering services, but to to devices actively browsing for and offering services, but to
anybody passively listing to the network traffic. anybody passively listening 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 both the device, and, by identifier. It enables tracking of both the device, and, by
skipping to change at page 7, line 33 skipping to change at page 7, line 33
services, such as for example some private messaging services. services, such as for example some private messaging services.
One way to protect clients would be to somehow encrypt the requested One way to protect clients would be to somehow encrypt the requested
service types. Of course, just as we noted in Section 2.4, traffic service types. Of course, just as we noted in Section 2.4, traffic
analysis can often reveal the service. analysis can often reveal the service.
3. Design of the Private DNS-SD Discovery Service 3. Design of the Private DNS-SD Discovery Service
In this section, we present the design of a two-stage solution that In this section, we present the design of a two-stage solution that
enables private use of DNS-SD, without affecting existing users. The enables private use of DNS-SD, without affecting existing users. The
solution is largely based on the architecture proposed in [KW14b], solution is largely based on the architecture proposed in [KW14b] and
which separates the general private discovery problem in three [K17], which separates the general private discovery problem in three
components. The first component is an offline pairing mechanism, components. The first component is an offline pairing mechanism,
which is performed only once per pair of users. It establishes a which is performed only once per pair of users. It establishes a
shared secret over an authenticated channel, allowing devices to shared secret over an authenticated channel, allowing devices to
authenticate using this secret without user interaction at any later authenticate using this secret without user interaction at any later
point in time. We use the pairing system proposed in point in time. We use the pairing system proposed in
[I-D.ietf-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
skipping to change at page 8, line 46 skipping to change at page 8, line 46
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 browsed using regular DNS-SD procedures, and then
list of discovered services will have to be filtered so only paired filtered so that only instances offered by paired devices are
devices are retained. retained.
3.2.1. Obfuscated Instance Names 3.2.1. Obfuscated Instance Names
The instance names for the Private Discovery Service are obfuscated, The instance names for the Private Discovery Service are obfuscated,
so that authorized peers can associate the instance with its so that authorized peers can associate the instance with its
publisher, but unauthorized peers can only observe what looks like a publisher, but unauthorized peers can only observe what looks like a
random name. To achieve this, the names are composed as the random name. To achieve this, the names are composed as the
concatenation of a nonce and a proof, which is composed by hashing concatenation of a nonce and a proof, which is composed by hashing
the nonce with a pairing key: the nonce with a pairing key:
skipping to change at page 9, line 48 skipping to change at page 9, line 48
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. published instances.
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 initially proposed a value of about 5 minutes,
which would work well for the mDNS variant of DNS-SD. However, this
may cause an excessive number of updates for the DNS server based
version of DNS-SD. We propose to set a value of about 30 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 Receivers can pre-calculate all the M relevant proofs once per time
interval and then establish a mapping from the corresponding instance interval and then establish a mapping from the corresponding instance
names to the pairing data in form of a hash table. These M relevant 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 proofs are the proofs resulting from hashing a host's M pairing keys
alongside the current nonce. Each time they receive an instance alongside the current nonce. Each time they receive an instance
name, they can test in O(1) time if the received service information name, they can test in O(1) time if the received service information
is relevant or not. 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 20 bits of this 32 bit number represent the number of
seconds intervals since the epoch. 256 seconds correspond to 4 2048 seconds intervals since the epoch. 2048 seconds correspond to 34
minutes and 16 seconds, which is close enough to our design goal of 5 minutes and 8 seconds, which is close enough to our design goal of 30
minutes. We will thus use this 24 bit number as nonce, represented minutes. We will thus use this 20 bit number as nonce, which for
as 3 octets. simplicity will be padded zeroes to 24 bits and encoded in 3 octets.
For coping with time skew, receivers pre-calculate proofs for the For coping with time skew, receivers pre-calculate proofs for the
respective next time interval and store hash tables for the last, the respective next time interval and store hash tables for the last, the
current, and the next time interval. When receiving a service current, and the next time interval. When receiving a service
instance name, receivers first check whether the nonce corresponds to instance name, receivers first check whether the nonce corresponds to
the current, the last or the next time interval, and if so, check the current, the last or the next time interval, and if so, check
whether the instance name is in the corresponding hash table. For whether the instance name is in the corresponding hash table. For
(approximately) meeting our design goal of 5 min validity, the last (approximately) meeting our design goal of 5 min validity, the last
time interval may only be considered if the current one is less than 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 half way over and the next time interval may only be considered if
skipping to change at page 12, line 50 skipping to change at page 12, line 50
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 plain 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 an authentication based on pre-shared keys.
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:
skipping to change at page 13, line 42 skipping to change at page 13, line 42
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
further published an UDP variant, DNS over DTLS [RFC8094], which further published an UDP variant, DNS over DTLS [RFC8094], which
would also be a candidate. would also be a candidate.
DPRIVE and Private Discovery solve however two somewhat different DPRIVE and Private Discovery, however, solve two somewhat different
problems. DPRIVE is concerned with the confidentiality of DNS problems. While DPRIVE is concerned with the confidentiality of DNS
transactions, addressing the problems outlined in [RFC7626]. transactions addressing the problems outlined in [RFC7626], DPRIVE
However, DPRIVE does not address the confidentiality or privacy does not address the confidentiality or privacy issues with
issues with publication of services, and is not a direct solution to publication of services, and is not a direct solution to DNS-SD
DNS-SD privacy: 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
networks, there is no guarantee that the domain services for these networks, there is no guarantee that the domain services for these
networks will be accessible using DNS over TLS or DNS over DTLS. networks will be accessible using DNS over TLS or DNS over DTLS.
o Information placed in the DNS is considered public. Even if the o Information placed in the DNS is considered public. Even if the
server does support DNS over TLS, third parties will still be able server does support DNS over TLS, third parties will still be able
to discover the content of PTR, SRV and TXT records. to discover the content of PTR, SRV and TXT records.
o Neither DNS over TLS nor DNS over DTLS applies to MDNS. o Neither DNS over TLS nor DNS over DTLS applies to mDNS.
In contrast, we propose using mutual authentication of the client and In contrast, we propose using mutual authentication of the client and
server as part of the TLS solution, to ensure that only authorized server as part of the TLS solution, to ensure that only authorized
parties learn the presence of a service. parties learn the presence of a service.
3.4. Randomized Host Names 3.4. Randomized Host Names
Instead of publishing their actual host names in the SRV records, Instead of publishing their actual host names in the SRV records,
nodes could publish randomized host names. That is the solution nodes could publish randomized host names. That is the solution
argued for in [RFC8117]. argued for in [RFC8117].
skipping to change at page 15, line 15 skipping to change at page 15, line 15
These components are detailed in the following subsections. These components are detailed in the following subsections.
4.1. Host Name Randomization 4.1. Host Name Randomization
Nodes publishing services with DNS-SD and concerned about their Nodes publishing services with DNS-SD and concerned about their
privacy MUST use a randomized host name. The randomized name MUST be privacy MUST use a randomized host name. The randomized name MUST be
changed when network connectivity changes, to avoid the correlation changed when network connectivity changes, to avoid the correlation
issues described in Section 3.5. The randomized host name MUST be issues described in Section 3.5. The randomized host name MUST be
used in the SRV records describing the service instance, and the used in the SRV records describing the service instance, and the
corresponding A or AAAA records MUST be made available through DNS or corresponding A or AAAA records MUST be made available through DNS or
MDNS, within the same scope as the PTR, SRV and TXT records used by mDNS, within the same scope as the PTR, SRV and TXT records used by
DNS-SD. DNS-SD.
If the link-layer address of the network connection is properly If the link-layer address of the network connection is properly
obfuscated (e.g. using MAC Address Randomization), the Randomized obfuscated (e.g. using MAC Address Randomization), the Randomized
Host Name MAY be computed using the algorithm described in section Host Name MAY be computed using the algorithm described in section
3.7 of [RFC7844]. If this is not possible, the randomized host name 3.7 of [RFC7844]. If this is not possible, the randomized host name
SHOULD be constructed by simply picking a 48 bit random number SHOULD be constructed by simply picking a 48 bit random number
meeting the Randomness Requirements for Security expressed in meeting the Randomness Requirements for Security expressed in
[RFC4075], and then use the hexadecimal representation of this number [RFC4075], and then use the hexadecimal representation of this number
as the obfuscated host name. as the obfuscated host name.
4.2. Device Pairing 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.ietf-dnssd-pairing] to establish these secrets. [I-D.ietf-dnssd-pairing] to establish these secrets.
[[TODO: Should we support mutually authenticated certificates? They
can also be used to initiate TLS and have several advantages, i.e.
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
secret with the host (see Section 4.2). To ensure privacy of the secret with the host (see Section 4.2). To ensure privacy of the
requests, the service is only available over TLS [RFC5246], and the requests, the service is only available over TLS [RFC5246], and the
shared secrets are used to mutually authenticate peers and servers. shared secrets are used to mutually authenticate peers and servers.
The Private Name Server SHOULD support DNS push notifications The Private Name Server SHOULD support DNS push notifications
skipping to change at page 16, line 36 skipping to change at page 16, line 30
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 the PDS to all paired peers. 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 20 most significant bits of the
significant bits of the 32 bit Unix GMT time. 32 bit Unix GMT time padded with 4 zeroes.
For example, on August 22, 2017 at 20h 4 min and 54 seconds
international time, the Unix 32 bit time had the
hexadecimal value 0x599C8E68. The corresponding nonce
would be set to the 24 bits: 0x599C80.
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_name = BASE64(binary identifier) set instance_name = BASE64(binary identifier)
In this formula, HASH SHOULD be the function SHA256 defined in In this formula, HASH SHOULD be the function SHA256 defined in
[RFC4055], and BASE64 is defined in section 6.8 of [RFC2045]. The [RFC4055], and BASE64 is defined in section 6.8 of [RFC2045]. The
concatenation of a 24 bit nonce and 48 bit proof result in a 72 bit concatenation of a 24 bit nonce and 48 bit proof result in a 72 bit
string. The BASE64 conversion is 12 characters long per [RFC6763]. string. The BASE64 conversion is 12 characters long per [RFC6763].
4.5. Discovering Private Discovery Service Instances 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. When using the Direct Discovery
request, they will receive in response a series of PTR records, procedure over mDNS, nodes SHOULD always set the QU-bit (unicast
providing the names of the instances present in the scope. response requested, see [RFC6762] Section 5.4) because responses
related to a "_pds._tcp" instance are only relevant for the querying
node itself.
When nodes send a DNS-SD discovery request, they will receive in
response a series of PTR records, each providing the name of one of
the instances present in the scope.
For each time interval, the querier SHOULD pre-calculate a hash table For each time interval, the querier SHOULD pre-calculate a hash table
mapping instance names to pairings according to the following mapping instance names to pairings according to the following
conceptual algorithm: conceptual algorithm:
nonce = 24 bit rounded time stamp of the\ nonce = 20 bit rounded time stamp of the \
respective next time interval respective next time interval padded to \
24 bits with four zeroes
for each available pairing for each available pairing
retrieve the key Xj of pairing number j retrieve the key Xj of pairing number j
compute F = first 48 bits of hash(nonce, Xj) compute F = first 48 bits of hash(nonce, Xj)
construct the binary instance_name as described\ construct the binary instance_name as described \
in the previous section in the previous section
instance_names[nonce][instance_name] = Xj; instance_names[nonce][instance_name] = Xj;
The querier SHOULD store the hash tables for the previous, the The querier SHOULD store the hash tables for the previous, the
current, and the next time interval. 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 72 bits,
discard the instance. discard the instance.
nonce = first 24 bits of binary. nonce = first 24 bits of binary.
Check that the nonce matches the first 24 bits of Check that the 4 least significant bits of the nonce
the current time, or the previous interval (24 bit number have the value 0, and that the 20 most significant
bits of the nonce match the first 20 bits of
the current time, or the previous interval (20 bit number
minus 1) if the current interval is less than half over, minus 1) if the current interval is less than half over,
or the next interval (24 bit number plus 1) if the or the next interval (20 bit number plus 1) if the
current interval is more than half over. If the current interval is more than half over. If the
nonce does not match an acceptable value, discard nonce does not match an acceptable value, discard
the instance. the instance.
if ((Xj = instance_names[nonce][instance_name]) != null) if ((Xj = instance_names[nonce][instance_name]) != null)
mark the pairing number j as available 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 two while not mandating a time synchronization precision better than 15
minutes. 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 proof, which entails a small chance of "false positive" match. This
will occur if the hash of the nonce with two different keys produces will occur if the hash of the nonce with two different keys produces
the same result. In that case, the TLS connection will fail with an the same result. In that case, the TLS connection will fail with an
authentication error or a decryption error. authentication error or a decryption error.
4.6. Direct Discovery of Private Discovery Service Instances 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.
skipping to change at page 20, line 5 skipping to change at page 20, line 26
different contexts. Peers engaging in discovery can be misled into different contexts. Peers engaging in discovery can be misled into
believing that a paired server is present. They will attempt to believing that a paired server is present. They will attempt to
connect to the absent peer, and in doing so will disclose their connect to the absent peer, and in doing so will disclose their
presence in a monitored scope. presence in a monitored scope.
The binary instance identifiers defined in Section 4.4 start with 24 The binary instance identifiers defined in Section 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
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 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.
To mitigate such attacks, nodes SHOULD restrict the range of network To mitigate such attacks, nodes SHOULD restrict the range of network
skipping to change at page 20, line 35 skipping to change at page 20, line 50
by locally connected adversaries; but protecting against local denial by locally connected adversaries; but protecting against local denial
of service attacks is generally very difficult. For example, local of service attacks is generally very difficult. For example, local
attackers can also attack mDNS and DNS-SD by generating a large attackers can also attack mDNS and DNS-SD by generating a large
number of multicast requests. number of multicast requests.
5.5. Replay Attacks against the Private Discovery Service 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 the 24 most The PSK identifiers defined in Section 4.3.1 start with the 24 most
significant bits of the "UNIX" time. In order to mitigate replay significant bits of the "UNIX" time. In order to mitigate replay
attacks, servers SHOULD verify that this time is reasonably recent, attacks, servers SHOULD verify that this time is reasonably recent,
and fail the connection if it is too old, or if it occurs too far in and fail the connection if it is too old, or if it occurs too far in
the future. the future.
The processing of timestamps is however affected by the accuracy of The processing of timestamps is however affected by the accuracy of
computer clocks. If the check is too strict, reasonable connections computer clocks. If the check is too strict, reasonable connections
could fail. To further mitigate replay attacks, servers MAY record could fail. To further mitigate replay attacks, servers MAY record
the list of valid PSK identifiers received in a recent past, and fail the list of valid PSK identifiers received in a recent past, and fail
connections if one of these identifiers is replayed. connections if one of these identifiers is replayed.
5.6. Replay attacks and clock synchronization
The mitigation of replay attacks relies on verification of the time
encoded in the nonce. This verification assumes that the hosts
engaged in discovery have a reasonably accurate sense of the current
time.
5.7. Fingerprinting the number of published instances
Adversaries could monitor the number of instances published by a
particular device, which in the absence of mitigations will reflect
the number of pairings established by that device. This number will
probably vary between 1 and maybe 100, providing the adversary with
maybe 6 or 7 bits of input in a fingerprinting algorithm.
Devices MAY protect against this fingerprinting by publishing a
number of "fake" instances in addition to the real ones. The fake
instance identifiers will contain the same nonce as the genuine
instance identifiers, and random bits instead of the proof. Peers
should be able to quickly discard these fake instances, as the proof
will not match any of the values that they expect. One plausible
padding strategy is to ensure that the total number of published
instances, either fake or genuine, matches one of a few values such
as 16, 32, 64, or higher powers of 2.
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.
about the _pds tag?)
7. Acknowledgments 7. Acknowledgments
This draft results from initial discussions with Dave Thaler, and This draft results from initial discussions with Dave Thaler, and
encouragements from the DNS-SD working group members. encouragements from the DNS-SD working group members. We would like
to thank Stephane Bortzmeyer and Ted Lemon for their detailed reviews
of the working draft.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<http://www.rfc-editor.org/info/rfc2045>. <https://www.rfc-editor.org/info/rfc2045>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055, and Certificate Revocation List (CRL) Profile", RFC 4055,
DOI 10.17487/RFC4055, June 2005, DOI 10.17487/RFC4055, June 2005,
<http://www.rfc-editor.org/info/rfc4055>. <https://www.rfc-editor.org/info/rfc4055>.
[RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP)
Configuration Option for DHCPv6", RFC 4075, Configuration Option for DHCPv6", RFC 4075,
DOI 10.17487/RFC4075, May 2005, DOI 10.17487/RFC4075, May 2005,
<http://www.rfc-editor.org/info/rfc4075>. <https://www.rfc-editor.org/info/rfc4075>.
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)", Ciphersuites for Transport Layer Security (TLS)",
RFC 4279, DOI 10.17487/RFC4279, December 2005, RFC 4279, DOI 10.17487/RFC4279, December 2005,
<http://www.rfc-editor.org/info/rfc4279>. <https://www.rfc-editor.org/info/rfc4279>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
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-02 (work
in progress), March 2017. in progress), July 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-11 (work in progress), June 2017. draft-ietf-dnssd-push-12 (work in progress), July 2017.
[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-20 (work in progress), Version 1.3", draft-ietf-tls-tls13-21 (work in progress),
April 2017. July 2017.
[K17] Kaiser, D., "Efficient Privacy-Preserving
Configurationless Service Discovery Supporting Multi-Link
Networks", 2017,
<http://nbn-resolving.de/urn:nbn:de:bsz:352-0-422757>.
[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>.
[RFC1033] Lottor, M., "Domain Administrators Operations Guide", [RFC1033] Lottor, M., "Domain Administrators Operations Guide",
RFC 1033, DOI 10.17487/RFC1033, November 1987, RFC 1033, DOI 10.17487/RFC1033, November 1987,
<http://www.rfc-editor.org/info/rfc1033>. <https://www.rfc-editor.org/info/rfc1033>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <https://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>. <https://www.rfc-editor.org/info/rfc2782>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>. <https://www.rfc-editor.org/info/rfc6762>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015, DOI 10.17487/RFC7626, August 2015,
<http://www.rfc-editor.org/info/rfc7626>. <https://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>. <https://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, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094, Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017, DOI 10.17487/RFC8094, February 2017,
<http://www.rfc-editor.org/info/rfc8094>. <https://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>. <https://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
U.S.A. U.S.A.
Email: huitema@huitema.net Email: huitema@huitema.net
URI: http://privateoctopus.com/ URI: http://privateoctopus.com/
 End of changes. 55 change blocks. 
87 lines changed or deleted 127 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/