Internet DRAFT - draft-huitema-dnssd-privacy
draft-huitema-dnssd-privacy
Network Working Group C. Huitema
Internet-Draft Microsoft
Intended status: Standards Track March 9, 2016
Expires: September 10, 2016
Privacy Extensions for DNS-SD
draft-huitema-dnssd-privacy-00.txt
Abstract
DNS-SD allows discovery of services published in DNS or MDNS. The
publication normally disclose information about the device publishing
the services. There are use cases where devices want to communicate
without disclosing their identity, for example two mobile devices
visiting the same hotspot. We propose a method to obfuscate the
identification information published by DNS-SD.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Huitema Expires September 10, 2016 [Page 1]
Internet-Draft DNS-SD Privacy Extensions March 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
2. Privacy implications of DNS-SD . . . . . . . . . . . . . . . 3
2.1. Privacy implication of publishing instance names . . . . 3
2.2. Privacy implication of publishing node names . . . . . . 4
2.3. Privacy implication of publishing service attributes . . 4
2.4. Device fingerprinting . . . . . . . . . . . . . . . . . . 5
2.5. Privacy implication of discovering services . . . . . . . 5
3. Design of DNS-SD privacy mitigations . . . . . . . . . . . . 5
3.1. Obfuscated instance names . . . . . . . . . . . . . . . . 5
3.2. Randomized host names . . . . . . . . . . . . . . . . . . 6
3.3. Timing of obfuscation and randomization . . . . . . . . . 7
3.4. Fingerprint resistance . . . . . . . . . . . . . . . . . 7
3.5. A note on Private DNS services . . . . . . . . . . . . . 7
4. Privacy extensions for DNS-SD . . . . . . . . . . . . . . . . 8
4.1. Randomized Host Name . . . . . . . . . . . . . . . . . . 8
4.2. Instance Discovery Key . . . . . . . . . . . . . . . . . 8
4.3. Composing Obfuscated Instance Names . . . . . . . . . . . 9
4.4. De-Obfuscation of Instance Names . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
There are cases when nodes connected to a network want to provide or
consume services without exposing their identity to the other parties
connected to the same network. Consider for example a traveller
wanting to upload pictures from a phone to a laptop when connected to
the Wi-Fi network of an Internet cafe, or two travellers who want to
share files between their laptops when waiting for their plane in an
airport lounge.
We expect that these exchanges will start with a discovery procedure
using DNS-SD [RFC6763]. One of the devices will publish the
availability of a service, such as a picture library or a file store
in our examples. The user of the other device will discover this
service, and then connect to it.
Huitema Expires September 10, 2016 [Page 2]
Internet-Draft DNS-SD Privacy Extensions March 2016
When analysing these scenarios in Section 2, we find that the DNS-SD
messages leak identifying information such as instance name, host
name or service properties. We review the design constraint of a
solution in Section 3, and describe the proposed solution in
Section 4.
1.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Privacy implications of DNS-SD
DNS-Based Service Discovery (DNS-SD) is defined in [RFC6763]. It
allows nodes to publish the availibility of an instance of a service
by inserting specific records in the DNS ([RFC1033], [RFC1034],
[RFC1035]) or by publishing these records locally using multicast DNS
(MDNS) [RFC6762]. The service availability will be described in
three types of records:
PTR Record: Associate the service name in the domain with the
"instance" name published by the node.
SRV Record: Provides the node name, port number, priority and weight
associated with the service instance, in conformance with
[RFC2782].
TXT Record: Provides a set of attribute-value pairs describing
specific properties of the service instance.
In the remaining subsections, we will review the privacy issues
related to publishing instance names, node names, service attributes
and other data, as well as review the implications of using the
discovery service as a client.
2.1. Privacy implication of publishing instance names
In the first phase of discovery, the client will obtain a copy of all
the PTR records associated to a service in a given naming domain.
Each record contains a domain name starting with an instance name.
Instance names are free form description of the instance, and are
meant to convey enough information so discovery clients can easily
select the desired service. Section 4 of [RFC6763] give the
following example for the instance names of a printer service:
Huitema Expires September 10, 2016 [Page 3]
Internet-Draft DNS-SD Privacy Extensions March 2016
Building 2, 1st Floor . example . com .
Building 2, 2nd Floor . example . com .
Building 2, 3rd Floor . example . com .
Building 2, 4th Floor . example . com .
Nodes that use DNS-SD in a mobile environment will rely on the
specificity of the instance name to identify the desired service. In
our example of users wanting to upload pictures to a laptop in an
Internet Cafe, the list of available services may look like:
Alice's notebook . local .
Bob's laptop . local .
Image store for Carol . local .
Alice will see the list on her phone and understand intuitively that
she should pick the fist item. The discovery will "just work." It
will also reveal to anybody who cares that Alice is currently
visiting the Internet Cafe.
2.2. Privacy implication of publishing node names
The SRV records contain the DNS name of the node publishing the
service. Typical implementations construct this DNS name by
concatenating the "host name" of the node with the name of the local
domain. The privacy implications of this practice are reviewed in
[I-D.ietf-intarea-hostname-practice]. Depending on naming practices,
the host name is either a strong identifier of the device, or at a
minimum a partial identifier. It enables tracking of the device, and
by extension of the device's owner.
2.3. Privacy implication of publishing service attributes
The TXT records contain a set of attribute and value pairs
characteristics of the service implementation. These attributes
reveal some information about the devices that publishes the service.
The amount of information will vary widely with the particular
service and its implementation:
o Some attributeslike the paper size available in a printer, are the
same on many devices, and thus only provides limited information
to a tracker.
o Attributes that have freeform values, such as the name of a
directory, may reveal much more information.
Combinations of attributes have more information power than specific
attributes, and can potentially be used for "fingerprinting" a
specific device.
Huitema Expires September 10, 2016 [Page 4]
Internet-Draft DNS-SD Privacy Extensions March 2016
2.4. Device fingerprinting
The combination of information published in DNS-SD has the potential
to provide a "fingerprint" of a specific device. Such information
includes:
o The list of services published by the device, which can be
retrieved because the SRV records will point to the same host
name.
o The specific attributes describing these services.
o The port numbers used by the services.
o The values of the priority and weight attributes in the SRV
records.
This combination of services and attribute will often be sufficient
to identify the version of the software running on a device. If a
device publishes many services with rich sets of attributes, the
combination may be sufficient to identify the specific device.
2.5. Privacy implication of discovering services
The consumers of services engage in discovery, and in doing so do
reveal some information such as the list of services that they are
interested in and the domains in which they are looking for the
services. When the clients select specific instances of services,
they reveal their preference for these instances.
In first analysis, the leakage of information by lients looks benign
compared to the disclosures made by the servers. There may be a
concern when the client is attempting to use rare services.
3. Design of DNS-SD privacy mitigations
Ah Ah.
3.1. Obfuscated instance names
The privacy issues described in Section 2.1 can be solved by
obfuscating the instance names. Instead of a user friendly
description of the instance, the nodes will publish a random looking
string of characters. To prevent tracking over time and location,
different string values should be used at different locations, or at
different times.
Huitema Expires September 10, 2016 [Page 5]
Internet-Draft DNS-SD Privacy Extensions March 2016
Authorized parties should be able to "de-obfuscate" the names, while
non-authorized third parties will not be. For example, if both Alice
notebook and Bob's laptop use an obfuscation process, the list of
available services should appear differently to them and to thrid
parties. Alice's phone will be able to de-obfuscate the name of
Alice's notebook, but not that of Bob's laptop. Bob's phone will do
the opposite. Carol will do neither.
Alice will see something like:
GobbeldygookBlaBlaBla (Alice's notebook) . local .
Abracadabragooklybok . local .
Image store for Carol . local .
Bob will see:
GobbeldygookBlaBlaBla . local .
Abracadabragooklybok (Bob's laptop) . local .
Image store for Carol . local .
Carol will see:
GobbeldygookBlaBlaBla . local .
Abracadabragooklybok . local .
Image store for Carol . local .
In that example, Alice, Bob and Carol will be able to select the
appropriate instance. It would probably be preferable to filter out
the obfuscated instance names, to avoid confusing the user. In our
example, Alice and Bob have updated their software to understand
obfuscation, and they could easily filter out the obfuscated strings
that they do not like. But Carol is not using this system, and we
could argue that her experience is suboptimal.
The suboptimal experience with unmodified software could be avoided
if the obfuscated service records were published using different
service names, or using different domain names. This would of course
make management a bit more complex, and is thus debatable.
3.2. Randomized host names
Instead of publishing their actual name in the SRV records, nodes
could publish a randomized name. That the solution argued for in
[I-D.ietf-intarea-hostname-practice].
Randomized host names will prevent some of the tracking. Host names
are typically not visible by the users, and randomizing host names
will probably not cause much usability issues.
Huitema Expires September 10, 2016 [Page 6]
Internet-Draft DNS-SD Privacy Extensions March 2016
3.3. Timing of obfuscation and randomization
It is important that obfuscation of instance names be performed at
the right time, and that the obfuscated names change in synchrony
with other identifiers, such as MAC Addresses, IP Addresses or host
names. If the randomized host name changed but the instance name
remained constant, an adversary would have no difficulty linking the
old and new host names. Similarly, if IP or MAC addresses changed
but host names remained constant, the adversary could link the new
addresses to the old ones using the published name.
The problem is handled in [I-D.ietf-intarea-hostname-practice], which
recommends to pick a new random host name at the time of connecting
to a new network. The instance names should be obfuscated at the
same time, or maybe use the randomized host name as input in the
randomization process.
3.4. Fingerprint resistance
Difficult...
3.5. A note on Private DNS services
The DNS Private Exchange working group develops mechanisms to provide
confidentiality to DNS transactions, addressing the problems outlined
in [RFC7626]. The solutions being developed include DNS over TLS
[I-D.ietf-dprive-dns-over-tls] and DNS over DTLS
[I-D.ietf-dprive-dnsodtls].
We could imagine that DNS-SD nodes are configure to update and
retrieve DNS records using DNS over TLS or DNS over DTLS, but a
number of problems can arise:
o Discovery queries are scoped by the domain name within which
services are published. As nodes move and visit arbitrary
networks, there is no guarantee that the domain services for these
networks will be accessible using DNS over TLS or DNS over DTLS.
o Information placed in the DNS is considered public. Even if the
server does support DNS over TLS, third parties will still be able
to discover the content of PTR, SRV and TXT records.
o Neither DNS over TLS nor DNS over DTLS applies to MDNS.
In short, DNS ovr TLS and DNS over DTLS solve a different problem,
and are not a solution for DNS-SD privacy.
Huitema Expires September 10, 2016 [Page 7]
Internet-Draft DNS-SD Privacy Extensions March 2016
4. Privacy extensions for DNS-SD
The proposed solution uses the following components:
o The host names are randomized to prevent tracking.
o Nodes provide an Instance Discovery Key to other nodes authorized
to discover the service instance,
o The Instance Discovery Key is combined with a random seed to
obfuscate the instance names,
o Nodes engaged in discovery attempt to de-obfuscate the instance
names using the set of Instance Discovery Key that they know
about,
These components are detailed in the following subsections.
4.1. Randomized Host Name
Nodes publishing services with DNS-SD and concerned about their
privacy MUST use a randomized host name. The randomized name MUST be
changed when network conectivity changes, to avid the correlation
issues described in Section 3.3. The randomized host name MUST be
used in the SRV records describing the service instance, and the
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
DNS-SD.
If the link-layer address of the network connection is properly
obfuscated (e.g. using MAC Address Randomization), The Randomized
Host Name MAY be computed using the algorithm described in section
3.7 of [I-D.ietf-dhc-anonymity-profile]. If this is not possible,
the randomized host name SHOULD be constructed by simply picking a 48
bit random number meeting the Randomness Requirements for Security
expressed in [RFC4075], and then use the hexadecimal representation
of this number as the obfuscated host name.
4.2. Instance Discovery Key
The obfuscation and de-obfuscation of instance names is controlled by
the Instance Discovery Key. Each device publishing a service
instance configures an Instance Discovery Key associated with the
service instance.
The Instance Key SHOULD be at least 16 bytes long (128 bits). Its
content SHOULD meet the Randomness Requirements for Security
expressed in [RFC4075].
Huitema Expires September 10, 2016 [Page 8]
Internet-Draft DNS-SD Privacy Extensions March 2016
4.3. Composing Obfuscated Instance Names
The obfuscated instance name is composed of two components, a seed
and a hash, encoded in BASE64 ([RFC2045] section 6.8) and separated
by a dot:
instance_name = <base64_seed> "." <base64_hash>
The seed is derived algorithmically from the randomized host name.
If the randomized name changes, new instance names SHOULD be computed
and the corresponding records SHOULD be published in order to meet
the requirement defined in Section 3.3.
The complete instance name MUST be genrated using the following
process:
long_seed = HASH(randomized_host_name)
seed = first 12 bytes of long_seed
long_hash = HASH(seed | instance_discovery_key )
instance_hash = first 12 bytes of long_hash
instance_name = BASE64(seed) "." BASE64(instance_hash)
In this formula, HASH SHOULD be the function SHA256 defined in
[RFC4055], unless otherwise specified. Implementers MAY eventually
replace SHA256 with a stronger algorithm.
The algorithm produces seeds and hash that are encoded as 16 BASE64
characters. The resulting instance name is 33 characters long, which
fits within the 63 characters limit defined in [RFC6763].
4.4. De-Obfuscation of Instance Names
De-obfuscation of instance names assumes that authorized nodes are
provisioned with three elements for each discoverable instance:
o the de-obfuscated instance name,
o a copy of the instance_discovery_key,
o optionally, the identifier of the HASH function used by the
publisher.
A given node may be provisioned do discover many instances. For
example, Alice's phone may know about Alice's laptop and Alice's
desktop. It might also know of Bob's laptop, if Alice and Bob have
agreed to share such information.
Huitema Expires September 10, 2016 [Page 9]
Internet-Draft DNS-SD Privacy Extensions March 2016
To de-obfuscate the instance names, nodes performing discovery should
obtain the list of PTR records published for the service and domain
being searched and then do the following:
o Test whether the instance name contains the base64 encoding of a
seed and hash as defined in Section 4.3. If it is not in that
form, the name is not considered obfuscated.
o Retrieve the binary seed and hash from the base64 encoding.
o For each known instance discovery key, compute whether the hash of
the seed and key, and compare it to the published hash.
o If there is a hash, the de-obfuscated name of the instance is the
de-obfuscated name associated with the matching instance discovery
key
5. Security Considerations
This document specifies a method to protect the privacy of service
publishing nodes. This is especially useful when operating in a
public space. Obfuscating the identity of the publishing nodes
prevents some forms of "targeting" of high value nodes.
Obfuscating the identity of the publishing nodes does not provide any
form of access control. It will not prevent attackers from trying to
access the services.
The cost of the de-obfuscation algorithm scales as the product of the
number of authorized publishers known by the client, times the number
of obfuscated services published in the searched name domain.
Attackers could potentially publish a large number of bogus instances
of a service, forcing a high computation cost on discovery clients.
While this potential denial of service attack is concerning, we note
that this is merely an aggravation of a flooding attacks against DNS-
SD.
6. IANA Considerations
This draft does not require any IANA action.
7. Acknowledgments
This draft results from initial discussions with Dave Thaler.
Huitema Expires September 10, 2016 [Page 10]
Internet-Draft DNS-SD Privacy Extensions March 2016
8. References
8.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<http://www.rfc-editor.org/info/rfc2045>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055,
DOI 10.17487/RFC4055, June 2005,
<http://www.rfc-editor.org/info/rfc4055>.
[RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP)
Configuration Option for DHCPv6", RFC 4075,
DOI 10.17487/RFC4075, May 2005,
<http://www.rfc-editor.org/info/rfc4075>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>.
8.2. Informative References
[I-D.ietf-dhc-anonymity-profile]
Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
profile for DHCP clients", draft-ietf-dhc-anonymity-
profile-08 (work in progress), February 2016.
[I-D.ietf-dprive-dns-over-tls]
Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over TLS", draft-
ietf-dprive-dns-over-tls-07 (work in progress), March
2016.
[I-D.ietf-dprive-dnsodtls]
Reddy, T., Wing, D., and P. Patil, "DNS over DTLS
(DNSoD)", draft-ietf-dprive-dnsodtls-04 (work in
progress), January 2016.
Huitema Expires September 10, 2016 [Page 11]
Internet-Draft DNS-SD Privacy Extensions March 2016
[I-D.ietf-intarea-hostname-practice]
Huitema, C. and D. Thaler, "Current Hostname Practice
Considered Harmful", draft-ietf-intarea-hostname-
practice-00 (work in progress), October 2015.
[RFC1033] Lottor, M., "Domain Administrators Operations Guide",
RFC 1033, DOI 10.17487/RFC1033, November 1987,
<http://www.rfc-editor.org/info/rfc1033>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
<http://www.rfc-editor.org/info/rfc2782>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015,
<http://www.rfc-editor.org/info/rfc7626>.
Author's Address
Christian Huitema
Microsoft
Redmond, WA 98052
U.S.A.
Email: huitema@microsoft.com
Huitema Expires September 10, 2016 [Page 12]
