draft-huitema-dnssd-privacy-01.txt

Network Working Group                                         C. Huitema
Internet-Draft                                                 Microsoft
Intended status: Standards Track                               D. Kaiser
Expires: December 12, 2016                        University of Konstanz
                                                           June 10, 2016


                     Privacy Extensions for DNS-SD
                   draft-huitema-dnssd-privacy-01.txt

Abstract

   DNS-SD allows discovery of services published in DNS or MDNS.  The
   publication normally discloses 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 to solve this problem by a two-stage approach.  In the
   first stage, hosts discover Private Discovery Service Instances via
   DNS-SD using special formats to protect their privacy.  These service
   instances correspond to Private Discovery Servers running on peers.
   In the second stage, hosts directly query these Private Discovery
   Servers via DNS-SD over TLS.  A pairwise shared secret necessary to
   establish these connections is only known to hosts authorized by a
   pairing system.

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 December 12, 2016.








Huitema & Kaiser        Expires December 12, 2016               [Page 1]

Internet-Draft          DNS-SD Privacy Extensions              June 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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements  . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Privacy Implications of DNS-SD  . . . . . . . . . . . . . . .   4
     2.1.  Privacy Implication of Publishing Service Instance Names    4
     2.2.  Privacy Implication of Publishing Node Names  . . . . . .   5
     2.3.  Privacy Implication of Publishing Service Attributes  . .   5
     2.4.  Device Fingerprinting . . . . . . . . . . . . . . . . . .   6
     2.5.  Privacy Implication of Discovering Services . . . . . . .   6
   3.  Limits of a Simple Design . . . . . . . . . . . . . . . . . .   7
     3.1.  Obfuscated Instance Names . . . . . . . . . . . . . . . .   7
     3.2.  Names of Obfuscated Services  . . . . . . . . . . . . . .   8
     3.3.  Scaling Issues with Obfuscation . . . . . . . . . . . . .  10
   4.  Design of the Private DNS-SD Discovery Service  . . . . . . .  11
     4.1.  Device Pairing  . . . . . . . . . . . . . . . . . . . . .  11
       4.1.1.  Shared Secret . . . . . . . . . . . . . . . . . . . .  12
       4.1.2.  Secure Authenticated Pairing Channel  . . . . . . . .  12
       4.1.3.  Public Authentication Keys  . . . . . . . . . . . . .  12
     4.2.  Discovery of the Private Discovery Service  . . . . . . .  13
     4.3.  Private Discovery Service . . . . . . . . . . . . . . . .  14
       4.3.1.  A Note on Private DNS Services  . . . . . . . . . . .  15
     4.4.  Randomized Host Names . . . . . . . . . . . . . . . . . .  16
     4.5.  Timing of Obfuscation and Randomization . . . . . . . . .  16
   5.  Private Discovery Service Specification . . . . . . . . . . .  16
     5.1.  Host Name Randomization . . . . . . . . . . . . . . . . .  17
     5.2.  Device Pairing  . . . . . . . . . . . . . . . . . . . . .  17
     5.3.  Private Discovery Server  . . . . . . . . . . . . . . . .  18
       5.3.1.  Establishing TLS Connections  . . . . . . . . . . . .  18
     5.4.  Publishing Private Discovery Service Instances  . . . . .  19
     5.5.  Discovering Private Discovery Service Instances . . . . .  19
     5.6.  Using the Private Discovery Service . . . . . . . . . . .  20
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  20



Huitema & Kaiser        Expires December 12, 2016               [Page 2]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


     6.1.  Attacks Against the Pairing System  . . . . . . . . . . .  21
     6.2.  Denial of Discovery of the Private Discovery Service  . .  21
     6.3.  Replay Attacks Against Discovery of the Private Discovery
           Service . . . . . . . . . . . . . . . . . . . . . . . . .  22
     6.4.  Denial of Private Discovery Service . . . . . . . . . . .  22
     6.5.  Replay Attacks against the Private Discovery Service  . .  22
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  23
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  23
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25

1.  Introduction

   DNS-SD [RFC6763] enables distribution and discovery in local networks
   without configuration.  It is very convenient for users, but it
   requires the public exposure of the offering and requesting
   identities along with information about the offered and requested
   services.  Some of the information published by the announcements can
   be very revealing.  These privacy issues and potential solutions are
   discussed in [KW14a] and [KW14b].

   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 traveler
   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
   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.

   When analyzing 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 4, and describe the proposed solution in
   Section 5.

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].



Huitema & Kaiser        Expires December 12, 2016               [Page 3]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


2.  Privacy Implications of DNS-SD

   DNS-Based Service Discovery (DNS-SD) is defined in [RFC6763].  It
   allows nodes to publish the availability of an instance of a service
   by inserting specific records in the DNS ([RFC1033], [RFC1034],
   [RFC1035]) or by publishing these records locally using multicast DNS
   (mDNS) [RFC6762].  Available services are described using three types
   of records:

   PTR Record:  Associates a service type in the domain with an
      "instance" name of this service type.

   SRV Record:  Provides the node name, port number, priority and weight
      associated with the service instance, in conformance with
      [RFC2782].

   TXT Record:  Provides a set of attribute-value pairs describing
      specific properties of the service instance.

   In the remaining subsections, we will review the privacy issues
   related to publishing instance names, node names, service attributes
   and other data, as well as review the implications of using the
   discovery service as a client.

2.1.  Privacy Implication of Publishing Service Instance Names

   In the first phase of discovery, the client obtains all the PTR
   records associated with a service type in a given naming domain.
   Each PTR record contains a Service Instance Name defined in Section 4
   of [RFC6763]:

     Service Instance Name = <Instance> . <Service> . <Domain>

   The <Instance> portion of the Service Instance Name is meant to
   convey enough information for users of discovery clients to easily
   select the desired service instance.  Nodes that use DNS-SD over mDNS
   [RFC6762] in a mobile environment will rely on the specificity of the
   instance name to identify the desired service instance.  In our
   example of users wanting to upload pictures to a laptop in an
   Internet Cafe, the list of available service instances may look like:

   Alice's Images         . _imageStore._tcp . local
   Alice's Mobile Phone   . _presence._tcp   . local
   Alice's Notebook       . _presence._tcp   . local
   Bob's Notebook         . _presence._tcp   . local
   Carol's Notebook       . _presence._tcp   . local





Huitema & Kaiser        Expires December 12, 2016               [Page 4]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


   Alice will see the list on her phone and understand intuitively that
   she should pick the first item.  The discovery will "just work".

   However, DNS-SD/mDNS will reveal to anybody that Alice is currently
   visiting the Internet Cafe.  It further discloses the fact that she
   uses two devices, shares an image store, and uses a chat application
   supporting the _presence protocol on both of her devices.  She might
   currently chat with Bob or Carol, as they are also using a _presence
   supporting chat application.  This information is not just available
   to devices actively browsing for and offering services, but to
   anybody passively listing to the network traffic.

2.2.  Privacy Implication of Publishing Node Names

   The SRV records contain the DNS name of the node publishing the
   service.  Typical implementations construct this DNS name by
   concatenating the "host name" of the node with the name of the local
   domain.  The privacy implications of this practice are reviewed in
   [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 record's attribute and value pairs contain information on the
   characteristics of the corresponding service instance.  This in turn
   reveals information about the devices that publish services.  The
   amount of information varies widely with the particular service and
   its implementation:

   o  Some attributes like the paper size available in a printer, are
      the same on many devices, and thus only provide limited
      information to a tracker.

   o  Attributes that have freeform values, such as the name of a
      directory, may reveal much more information.

   Combinations of attributes have more information power than specific
   attributes, and can potentially be used for "fingerprinting" a
   specific device.

   Information contained in TXT records does not only breach privacy by
   making devices trackable, but might directly contain private
   information about a device user.  For instance the _presence service
   reveals the "chat status" to everyone in the same network.  Users
   might not be aware of that.




Huitema & Kaiser        Expires December 12, 2016               [Page 5]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


   Further, TXT records often contain version information about services
   allowing potential attackers to identify devices running exploit-
   prone versions of a certain service.

2.4.  Device Fingerprinting

   The combination of information published in DNS-SD has the potential
   to provide a "fingerprint" of a specific device.  Such information
   includes:

   o  The list of services published by the device, which can be
      retrieved because the SRV records will point to the same host
      name.

   o  The specific attributes describing these services.

   o  The port numbers used by the services.

   o  The values of the priority and weight attributes in the SRV
      records.

   This combination of services and attributes will often be sufficient
   to identify the version of the software running on a device.  If a
   device publishes many services with rich sets of attributes, the
   combination may be sufficient to identify the specific device.

   There is however an argument that devices providing services can be
   discovered by observing the local traffic, because different services
   have different traffic patterns.  The observation could in many cases
   also reveal some specificities of the service's implementation.  Even
   if the traffic is encrypted, the size and the timing of packets may
   be sufficient to reveal that information.  This argument can be used
   to assess the priority of, for example, protecting the fact that a
   device publishes a particular service.  However, we may assume that
   the developers of sensitive services will use counter-measures to
   defeat such traffic analysis.

2.5.  Privacy Implication of Discovering Services

   The consumers of services engage in discovery, and in doing so reveal
   some information such as the list of services they are interested in
   and the domains in which they are looking for the services.  When the
   clients select specific instances of services, they reveal their
   preference for these instances.  This can be benign if the service
   type is very common, but it could be more problematic for sensitive
   services, such as for example some private messaging services.





Huitema & Kaiser        Expires December 12, 2016               [Page 6]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


   One way to protect clients would be to somehow encrypt the requested
   service types.  Of course, just as we noted in Section 2.4, traffic
   analysis can often reveal the service.

3.  Limits of a Simple Design

   We first tried a simple design for mitigating the issues outlined in
   Section 2.  The basic idea was to advertise obfuscated names, so as
   to not reveal the particularities of the service providers.  This
   design is tempting, because it only requires minimal changes in the
   DNS-SD processing.  However, as we will see in the following
   subsections, it has two important drawbacks:

   o  The simple design leads to UI issues, because users of unmodified
      DNS-SD agents will see a mix of clear text names and obfuscated
      names, which is unpleasant.

   o  With this simple design, there is no good way to hide the type of
      services provided or consumed by a specific node.

   o  The simple design either requires having a shared key between all
      "authorized users" of a service, which implies substandard key
      management practices, or publishing as many instances of a service
      as there are authorized users, which leads to the scaling issues
      discussed in Section 3.3.

   Both issues are mitigated by the two-stage design presented in
   Section 4.  The following subsections detail the simple design, and
   its drawbacks.

3.1.  Obfuscated Instance Names

   The privacy issues described in Section 2.1 could be solved by
   obfuscating the instance names.  Instead of a user friendly
   description of the instance, the nodes would publish a random looking
   string of characters.  To prevent tracking over time and location,
   different string values would be used at different locations, or at
   different times.

   Authorized parties have to be able to "de-obfuscate" the names, while
   non-authorized third parties will not be.  For example, if both
   Alice's notebook and Bob's laptop use an obfuscation process, the
   list of available services should appear differently to them and to
   third 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:



Huitema & Kaiser        Expires December 12, 2016               [Page 7]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


   QwertyUiopAsdfghjk (Alice's Images)       . _imageStore._tcp . local
   GobbeldygookBlaBla (Alice's Mobile Phone) . _presence._tcp   . local
   MNbvCxzLkjhGfdEdhg (Alice's Notebook)     . _presence._tcp   . local
   Abracadabragooklybok (Bob's Notebook)     . _presence._tcp   . local
   Carol's Notebook                          . _presence._tcp   . local

   Bob will see:

   QwertyUiopAsdfghjk                    . _imageStore._tcp . local
   GobbeldygookBlaBla                    . _presence._tcp   . local
   MNbvCxzLkjhGfdEdhg                    . _presence._tcp   . local
   Abracadabragooklybok (Bob's Notebook) . _presence._tcp   . local
   Carol's Notebook                      . _presence._tcp   . local

   Carol will see:

   QwertyUiopAsdfghjk   . _imageStore._tcp . local
   GobbeldygookBlaBla   . _presence._tcp   . local
   MNbvCxzLkjhGfdEdhg   . _presence._tcp   . local
   Abracadabragooklybok . _presence._tcp   . local
   Carol's Notebook     . _presence._tcp   . 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.

3.2.  Names of Obfuscated Services

   Instead of publishing the actual service name in the SRV records,
   nodes could publish a randomized name.  There are two plausible
   reasons for doing that:

   o  Having a different service name for privacy enhanced services will
      ensure that hosts that are not privacy aware are not puzzled by
      obfuscated service names.

   o  Using obfuscated service names prevents third parties from
      discovering which service a particular host is providing or
      consuming.

   The first requirement can be met with a simple modification of an
   existing name.  For example, instead of publishing:





Huitema & Kaiser        Expires December 12, 2016               [Page 8]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


   QwertyUiopAsdfghjk . _imageStore._tcp . local
   GobbeldygookBlaBla . _presence._tcp   . local

   Alice could publish some kind of "translation" of the service name,
   such as:

   QwertyUiopAsdfghjk . _vzntrFgber._tcp . local
   GobbeldygookBlaBla . _cerfrapr._tcp   . local

   The previous examples use rot13 translation.  It does not provide any
   particular privacy, but it does ensure that obfuscated services are
   named differently from clear text services.

   Making the service name actually private would require some actual
   encryption.  The main problem with such solutions is that the client
   needs to know the service name in order to compose the DNS-SD query
   for services.  There are several options:

   o  The service name is chosen by the client.  For example, the client
      could encrypt the original service name and a nonce with a key
      shared between client and server.  Upon receiving the queries, the
      server would attempt to decrypt the service name.  If that
      succeeds, the server would respond with PTR records created on the
      fly for the new service name.

   o  The service name is chosen by the server and cannot be predicted
      in advance by the client.  For example, the server could encrypt a
      nonce and the original service name.  The client retrieves such
      services by doing a wild card query, then attempting to decrypt
      the received responses.

   o  The service name is chosen by the server in a way that can be
      predicted in advance by the client.  For example, the server could
      encrypt some version of the data and time and the original service
      name.  The data and time are encoded with a coarse precision,
      enabling the client to predict the value that the server is using,
      and to send the corresponding queries.

   None of these solutions is very attractive.  Creating records on the
   fly is a burden for the server.  If clients must use wildcard
   queries, they will need to process lots of irrelevant data.  If
   clients need to predict different instance names for each potential
   server, they will end up sending batches of queries with many
   different names.  All of these solutions appear like big departures
   from the simplicity and robustness of the DNS-SD design.






Huitema & Kaiser        Expires December 12, 2016               [Page 9]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


3.3.  Scaling Issues with Obfuscation

   In Section 3.1, we assumed that each advertised record contains a
   name obfuscated with a shared key.  This approach is easy to
   understand, but it contains hidden assumptions.  Let's look at one of
   our examples:

   Abracadabragooklybok (Bob's Notebook) . _presence._tcp   . local

   We only see one record for Bob's Notebook, obfuscated using the
   unique shared secret associated with Bob's Notebook.  That means that
   every device paired with Bob's Notebook will have a copy of that
   shared secret.  This is a possible solution, but there are known
   issues with having a secret shared with multiple entities:

   o  If for some reason the secret needs to be changed, every paired
      device will need a copy of the new secret before it can
      participate again in discovery.

   o  If one of the previous pairings becomes invalid, the only way to
      block the corresponding devices from discovery is to change the
      secret for all other devices.

   Key management becomes much easier if it is strictly pair-wise.  Two
   paired devices, or to pairs of users, can simply renew their pairing
   and get a new secret.  If a device ceases to be trusted, the pairing
   data and the corresponding secret can just be deleted and forgotten.
   But using strictly pair-wise keys yields a scaling issue.  Let's
   assume that:

   o  Each device maintains an average of N pairings.

   o  There are on average M devices present during discovery.

   In the single key scenario, after issuing a broadcast query, the
   querier will receive a series of responses, each of which may well be
   obfuscated with a different key.  If the receiver has N pre-existing
   pairings and receives M obfuscated responses, the cost will scale as
   O(M*N), i.e. try all N pairing keys for each of the M responses to
   see what matches.  But if the keys are specific to each pair of
   devices, the obfuscation becomes complicated.  When receiving a
   request, the publisher does not know which of its N keys the querier
   can decrypt.  One simple solution would be to send N responses, but
   then the load on the querier will scale as O(M*N^2).  That can go out
   of hand very quickly.

   To solve the scaling issue, we consider a two-stage solution that
   uses an optimized discovery procedure to discover privacy-compatible



Huitema & Kaiser        Expires December 12, 2016              [Page 10]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


   devices; and uses point to point encrypted exchanges to privately
   discover the available services.

4.  Design of the Private DNS-SD Discovery Service

   In this section, we present the design of a two-stage solution that
   enables private use of DNS-SD, without affecting existing users, and
   with better scalability than the simple solution presented in
   Section 3.  The solution is largely based on the architecture
   proposed in [KW14b], which separates the general private discovery
   problems in three components: Pairing, discovery of a private
   discovery service, and actual service discovery through this private
   service.  Pairing has to provide the private discovery servers with
   means for mutual authentication, e.g. with an authenticated shared
   secret.  The private discovery servers provide actual service
   discovery with an authenticated connection.  Our solution applies
   this architecture in the context of DNS-SD.  It is based on the
   following components:

   o  Adding a pairing system to DNS-SD, described in Section 4.1,
      through which authorized peers can establish shared secrets;

   o  Defining the Private Discovery Service through which other
      services can be advertised in a private manner;

   o  And, publishing availability of the Private Discovery Service
      using DNS-SD, so that peers can discover their services without
      compromising their privacy.

   These are independent with respect to means used for transmitting the
   necessary data.

4.1.  Device Pairing

   Any private discovery solution needs to differentiate between
   authorized devices, which are allowed to get information about
   discoverable entities, and other devices, which should not be aware
   of the availability of private entities.  The commonly used solution
   to this problem is establishing a "device pairing".  In our discovery
   scenarios, we envisage two kinds of pairings:

   1.  Inter-user pairing is a pairing between devices of "friends".
       Since it has to be performed manually, e.g. by the means
       described above, it is important to limit it to once per pair of
       friends.

   2.  Intra-user pairing is a pairing of devices of the same user.  It
       can be performed without any configuration by a meta-service



Huitema & Kaiser        Expires December 12, 2016              [Page 11]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


       (pairing data synchronization service) in a trusted (home)
       network.

   The result of the pairing will be a shared secret, and optionally
   mutually authenticated public keys added to a local web of trust.
   Public key technology has many advantages, but shared secrets are
   typically easier to handle on small devices.  We offer both a simple
   pairing just exchanging a shared secret, and an authenticated pairing
   using public key technology.

4.1.1.  Shared Secret

   Goal of the pairing process is establishing pairwise shared secrets.
   If two users can leverage a secure private off-channel, it suffices
   for one user to generate the shared secret and transmit it over this
   off-channel.  It would be possible for the users to meet and orally
   agree on a password that both users enter in their devices.  This has
   the disadvantage of user-chosen passwords to have low entropy and the
   inconvenience of having to type the password.  Leveraging QR-codes
   can overcome these disadvantages: one user generates a shared secret,
   displays it in form of a QR-code, and the other user scans this code.
   Strictly speaking, displaying and scanning QR-codes does not
   establish a secure private channel, as others could also photograph
   this code; but it is reasonable secure for the application area of
   private service discovery.  Using Bluetooth LE might also be
   considered satisfactory as a compromise between convenience and
   security.

4.1.2.  Secure Authenticated Pairing Channel

   Optionally, various versions of authenticated DH can be used to
   exchange a mutually authenticated shared secret (which among other
   possibilities can leverage QR-codes for key fingerprint
   verification).  Using DH gives the benefit of provable security and
   the possibility to perform a pairing when not being able to meet in
   person.  Further, using DH to generate the shared secret has the
   advantage of both parties contributing to the shared secret
   (multiparty computation).

4.1.3.  Public Authentication Keys

   The public/private key pair - if at all - is just used for the
   aforementioned authenticated DH to grant a mutually authenticated
   shared secret.  Obtaining and verifying a friend's public key can be
   achieved by different means.  For obtaining the keys, we can either
   leverage an existing PKI, e.g. the PGP web of trust, or generate our
   own key pairs (and exchange them right before verifying).  For
   authenticating the keys, which boils down to comparing fingerprints



Huitema & Kaiser        Expires December 12, 2016              [Page 12]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


   on an off-channel, we distinguish between means that demand users to
   be in close proximity of each other, and means where users do not
   have to meet in person.  The former can e.g. be realized by verifying
   a fingerprint leveraging QR-Codes, the latter by reading a
   fingerprint during a phone call or using the socialist millionaires
   protocol.

4.2.  Discovery of the Private Discovery Service

   The first stage of service discovery is to check whether instances of
   compatible Private Discovery Services are available in the local
   scope.  The goal of that stage is to identify devices that share a
   pairing with the querier, and are available locally.  The service
   instances can be discovered using regular DNS-SD procedures, but the
   list of discovered services will have to be filtered so only paired
   devices are retained.

   We have demonstrated in Section 3.3 that simple obfuscation would
   require publishing as many records per publisher as there are
   pairings, which ends up scaling as O(M*N^2) in which M is the number
   of devices present and N is the number of pairings per device.  We
   can mitigate this problem by using 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>

      Fi = hash (nonce, Ki), where hash is a cryptographic hash
      function.

   The querier can test the instance name by computing the same "proof"
   for each of its own keys.  Suppose that the receiver manages P
   pairings, with the corresponding keys X1, X2, .. Xp.  The receiver
   verification procedure will be:

      for each received instance name:
         retrieve nonce from instance name
         for (j = 1 to P)
            retrieve the key Xj of pairing number j
            compute F = hash(nonce, Xj)
            for (i=1 to N)
               retrieve the proof Fi
               if F is equal to Fi
                  mark the pairing number j as available





Huitema & Kaiser        Expires December 12, 2016              [Page 13]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


   The procedure presented here requires on average O(M*N) iterations of
   the hash function, which is the same scaling as the "shared secret"
   variant.  It 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
   is limited by the maximum size of a DNS label, which is 63 bytes.
   Since this are characters and not pure binary values, nonce and
   proofs will have to be encoded using BASE64 ([RFC2045] section 6.8),
   resulting in at most 378 bits.  The nonce should not be repeated, and
   the simplest way to achieve that is to set the nonce to a 32 bit
   timestamp value.  The remaining 346 bits could encode up to 10 proofs
   of 32 bits each, which would be sufficient for many practical
   scenarios.

   In practice, a 32 bit proof should be sufficient to distinguish
   between available devices.  However, there is clearly a risk of
   collision.  The Private Discovery Service as described here will find
   the available pairings, but it might also find a spurious number of
   "false positives."  The chances of that happening are however quite
   small: less than 0.02% for a device managing 10 pairings and
   processing 10000 responses.

4.3.  Private Discovery Service

   The Private Discovery Service discovery allows discovering a list of
   available paired devices, and verifying that either party knows the
   corresponding shared secret.  At that point, the querier can engage
   in a series of directed discoveries.

   We have considered defining an ad-hoc protocol for the private
   discovery service, but found that just using TLS would be much
   simpler.  The Directed Private Discovery service is just a regular
   DNS-SD service, accessed over TLS, using the encapsulation of DNS
   over TLS defined in [RFC7858].  The main difference with simple DNS
   over TLS is the need for authentication.

   We assume that the pairing process has provided each pair of
   authorized client and server with a shared secret.  We can use that
   shared secret to provide mutual authentication of clients and servers
   using "Pre Shared Key" authentication, as defined in [RFC4279] and
   incorporated in the latest version of TLS [I-D.ietf-tls-tls13].

   One difficulty is the reliance on a key identifier in the protocol.
   For example, in TLS 1.3 the PSK extension is defined as:




Huitema & Kaiser        Expires December 12, 2016              [Page 14]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


      opaque psk_identity<0..2^16-1>;

      struct {
          select (Role) {
              case client:
                  psk_identity identities<2..2^16-1>;

              case server:
                  uint16 selected_identity;
          }
      } PreSharedKeyExtension

   According to the protocol, the PSK identity is passed in clear text
   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
   the connection.  But if we used a static identifier for the key,
   adversaries could use that identifier to track server and clients.
   The solution is to use a time-varying identifier, constructed exactly
   like the "hint" described in Section 4.2, by concatenating a nonce
   and the hash of the nonce with the shared secret.

4.3.1.  A Note on Private DNS Services

   Our solution uses a variant of the DNS over TLS protocol [RFC7858]
   defined by the DNS Private Exchange working group (DPRIVE).  DPRIVE
   is also working on an UDP variant, DNS over DTLS
   [I-D.ietf-dprive-dnsodtls], which would also be a candidate.

   DPRIVE and Private Discovery solve however two somewhat different
   problems.  DPRIVE is concerned with the confidentiality to DNS
   transactions, addressing the problems outlined in [RFC7626].
   However, DPRIVE does not address the confidentiality or privacy
   issues with publication of services, and is not a direct solution to
   DNS-SD privacy:

   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.






Huitema & Kaiser        Expires December 12, 2016              [Page 15]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


   In contrast, we propose using mutual authentication of the client and
   server as part of the TLS solution, to ensure that only authorized
   parties learn the presence of a service.

4.4.  Randomized Host Names

   Instead of publishing their actual name in the SRV records, nodes
   could publish a randomized name.  That is 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.

4.5.  Timing of Obfuscation and Randomization

   It is important that the obfuscation of instance names is 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.  New instance names for the Private Discovery
   Services should be composed at the same time.

5.  Private Discovery Service Specification

   The proposed solution uses the following components:

   o  Host name randomization to prevent tracking.

   o  Device pairing yielding pairwise shared secrets.

   o  A Private Discovery Server (PDS) running on each host.

   o  Discovery of the PDS instances using DNS-SD.

   These components are detailed in the following subsections.








Huitema & Kaiser        Expires December 12, 2016              [Page 16]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


5.1.  Host Name Randomization

   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 connectivity changes, to avoid the correlation
   issues described in Section 4.5.  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 [RFC7844].  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.

5.2.  Device Pairing

   Nodes that want to leverage the Private Directory Service for private
   service discovery among peers MUST share a secret with each of these
   peers.  The shared secret MUST be a 256 bit randomly chosen number.
   The secret SHOULD be exchanged via device Pairing.  The pairing
   process SHALL establish a mutually authenticated secure channel to
   perform the shared secret exchange.  It is RECOMMENDED for both
   parties to contribute to the shared secret, e.g. by using a Diffie-
   Hellman key exchange.

   TODO: need to define the pairing service, or API.  The API approach
   assumes that pairing is outside our scope, and is done using BT-LE,
   or any other existing mechanism.  This is a bit of a cope-out.  We
   could also define a pairing system that just sets the pairing with
   equivalent security as the "push button" or "PIN" solutions used for
   BT or Wi-Fi.  And we could at this stage leverage a pre-existing
   security association, e.g.  PGP identities or other certificates.  If
   we do that, we should probably dedicate a top level section to
   specifying the minimal pairing service.  Using a pre-existing
   asymmetric security association, we can use a key exchange similar to
   IKEv2 (RFC 7296).  IKEv2 leverages the SIGMA protocols, which provide
   various methods of authenticated DH.  It would also be possible to
   authenticate DH using symmetric passwords (e.g.  Bellovin-Merritt).







Huitema & Kaiser        Expires December 12, 2016              [Page 17]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


5.3.  Private Discovery Server

   A Private Discovery Server (PDS) is a minimal DNS server running on
   each host.  Its task is to offer resource records corresponding to
   private services only to authorized peers.  These peers MUST share a
   secret with the host (see Section 5.2).  To ensure privacy of the
   requests, the service is only available over TLS [RFC5246], and the
   shared secrets are used to mutually authenticate peers and servers.

   The Private Name Server SHOULD support DNS push notifications
   [I-D.ietf-dnssd-push], e.g. to facilitate an up-to-date contact list
   in a chat application without polling.

5.3.1.  Establishing TLS Connections

   The PDS MUST only answer queries via DNS over TLS [RFC7858] and MUST
   use a PSK authenticated TLS handshake [RFC4279].  The client and
   server should negotiate a forward secure cypher suite such as DHE-PSK
   or ECDHE-PSK when available.  The shared secret exchanged during
   pairing MUST be used as PSK.

   When using the PSK based authentication, the "psk_identity" parameter
   identifying the pre-shared key MUST be composed as follow, using the
   conventions of TLS [RFC7858]:

      struct {

                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 generator.





Huitema & Kaiser        Expires December 12, 2016              [Page 18]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


   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
   key matches, the TLS connection is accepted, otherwise it is
   declined.

5.4.  Publishing Private Discovery Service Instances

   Nodes that provide the Private Discovery Service SHOULD advertise
   their availability by publishing instances of the service through
   DNS-SD.

   The DNS-SD service type for the Private Discovery Service is
   "_pds._tls".

   Each published instance describes one server and up to 10 pairings.
   In the case where a node manages more than 10 pairings, it should
   publish as many instances as necessary to advertise all available
   pairings.

   Each instance name is composed as follows:

      pick a 32 bit nonce, e.g. using the Unix GMT time.
      set the binary identifier to the nonce.

      for each of up to 10 pairings
         hint = first 32 bits of HASH(<nonce>|<pairing key>)
         concatenate the hint to the binary identifier

      set instance-ID = BASE64(binary identifier)

   In this formula, HASH SHOULD be the function SHA256 defined in
   [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
   bit string at most 332 bit long.  The BASE64 conversion will produce
   a string that is up to 59 characters long, which fits within the 63
   characters limit defined in [RFC6763].

5.5.  Discovering Private Discovery Service Instances

   Nodes that wish to discover Private Discovery Service Instances will
   issue a DNS-SD discovery request for the service type.  These request
   will return a series of PTR records, providing the names of the
   instances present in the scope.



Huitema & Kaiser        Expires December 12, 2016              [Page 19]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


   The querier SHOULD examine each instance to see whether it hints at
   one of its available pairings, according to the following conceptual
   algorithm:

      for each received instance name:
         convert the instance name to binary using BASE64
         if the conversion fails,
            discard the instance.
         if the binary instance length is a not multiple of 32 bits,
            discard the instance.

         nonce = first 32 bits of binary.
         for each 32 bit hint after the nonce
            for each available pairing
               retrieve the key Xj of pairing number j
               compute F = hash(nonce, Xj)
               if F is equal to the 32 bit hint
                  mark the pairing number j as available

   Once a pairing has been marked available, the querier SHOULD try
   connecting to the corresponding instance, using the selected key.
   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
   hint, which entails a small chance of "false positive" match.  This
   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
   authentication error or a decryption error.

5.6.  Using the Private Discovery Service

   Once instances of the Private Discovery Service have been discovered,
   peers can establish TLS connections and send DNS requests over these
   connections, as specified in DNS-SD.

6.  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.  Hiding the identity of the publishing nodes prevents
   some forms of "targeting" of high value nodes.  However, adversaries
   can attempt various attacks to break the anonymity of the service, or
   to deny it.  A list of these attacks and their mitigations are
   described in the following sections.








Huitema & Kaiser        Expires December 12, 2016              [Page 20]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


6.1.  Attacks Against the Pairing System

   There are a variety of attacks against pairing systems.  They may
   result in compromised pairing keys.  If an adversary manages to
   acquire a compromised key, the adversary will be able to perform
   private service discovery according to Section 5.5.  This will allow
   tracking of the service.  The adversary will also be able to discover
   which private services are available for the compromised pairing.

   To mitigate such attacks, nodes MUST be able to quickly revoke a
   compromised pairing.  This is however not sufficient, as the
   compromise of the pairing key could remain undetected for a long
   time.  For further safety, nodes SHOULD assign a time limit to the
   validity of pairings, discard the corresponding keys when the time
   has passed, and establish new pairings.

   This later requirement of limiting the Time-To-Live can raise doubts
   about the usability of the protocol.  The usability issues would be
   mitigated if the initial pairing provided both a shared secret and
   the means to renew that secret over time, e.g. using authenticated
   public keys.

6.2.  Denial of Discovery of the Private Discovery Service

   The algorithm described in Section 5.5 scales as O(M*N), where M is
   the number of pairing per nodes and N is the number of nodes in the
   local scope.  Adversaries can attack this service by publishing
   "fake" instances, effectively increasing the number N in that scaling
   equation.

   Similar attacks can be mounted against DNS-SD: creating fake
   instances will generally increase the noise in the system and make
   discovery less usable.  Private Discovery Service discovery SHOULD
   use the same mitigations as DNS-SD.

   The attack is amplified because the clients need to compute proofs
   for all the nonces presented in Private Discovery Service Instance
   names.  One possible mitigation would be to require that such nonces
   correspond to rounded timestamps.  If we assume that timestamps must
   not be too old, there will be a finite number of valid rounded
   timestamps at any time.  Even if there are many instances present,
   they would all pick their nonces from this small number of rounded
   timestamps, and a smart client could make sure that proofs are only
   computed once per valid time stamp.







Huitema & Kaiser        Expires December 12, 2016              [Page 21]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


6.3.  Replay Attacks Against Discovery of the Private Discovery Service

   Adversaries can record the service instance names published by
   Private Discovery Service instances, and replay them later in
   different contexts.  Peers engaging in discovery can be misled into
   believing that a paired server is present.  They will attempt to
   connect to the absent peer, and in doing so will disclose their
   presence in a monitored scope.

   The binary instance identifiers defined in Section 5.4 start with 32
   bits encoding the "UNIX" time.  In order to protect against replay
   attacks, clients MAY verify that this time is reasonably recent.

   TODO: should we somehow encode the scope in the identifier?  Having
   both scope and time would really mitigate that attack.

6.4.  Denial of Private Discovery Service

   The Private Discovery Service is only available through a mutually
   authenticated TLS connection, which provides good protections.
   However, adversaries can mount a denial of service attack against the
   service.  In the absence of shared secrets, the connections will
   fail, but the servers will expend some CPU cycles defending against
   them.

   To mitigate such attacks, nodes SHOULD restrict the range of network
   addresses from which they accept connections, matching the expected
   scope of the service.

   This mitigation will not prevent denial of service attacks performed
   by locally connected adversaries; but protecting against local denial
   of service attacks is generally very difficult.  For example, local
   attackers can also attack mDNS and DNS-SD by generating a large
   number of multicast requests.

6.5.  Replay Attacks against the Private Discovery Service

   Adversaries may record the PSK Key Identifiers used in successful
   connections to a private discovery service.  They could attempt to
   replay them later against nodes advertising the private service at
   other times or at other locations.  If the PSK Identifier is still
   valid, the server will accept the TLS connection, and in doing so
   will reveal being the same server observed at a previous time or
   location.

   The PSK identifiers defined in Section 5.3.1 start with 32 bits
   encoding the "UNIX" time.  In order to mitigate replay attacks,
   servers SHOULD verify that this time is reasonably recent, and fail



Huitema & Kaiser        Expires December 12, 2016              [Page 22]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


   the connection if it is too old, or if it occurs too far in the
   future.

   The processing of timestamps is however mitigated by the accuracy of
   computer clocks.  If the check is too strict, reasonable connections
   could fail.  To further mitigate replay attacks, servers MAY record
   the list of valid PSK identifiers received in a recent past, and fail
   connections if one of these identifiers is replayed.

7.  IANA Considerations

   This draft does not require any IANA action.  (Or does it?  What
   about the _pds tag?)

8.  Acknowledgments

   This draft results from initial discussions with Dave Thaler, and
   encouragements from the DNS-SD working group members.

9.  References

9.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>.







Huitema & Kaiser        Expires December 12, 2016              [Page 23]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


   [RFC4279]  Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
              Ciphersuites for Transport Layer Security (TLS)",
              RFC 4279, DOI 10.17487/RFC4279, December 2005,
              <http://www.rfc-editor.org/info/rfc4279>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [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>.

9.2.  Informative References

   [I-D.ietf-dnssd-push]
              Pusateri, T. and S. Cheshire, "DNS Push Notifications",
              draft-ietf-dnssd-push-07 (work in progress), April 2016.

   [I-D.ietf-dprive-dnsodtls]
              Reddy, T., Wing, D., and P. Patil, "DNS over DTLS
              (DNSoD)", draft-ietf-dprive-dnsodtls-06 (work in
              progress), April 2016.

   [I-D.ietf-intarea-hostname-practice]
              Huitema, C., Thaler, D., and R. Winter, "Current Hostname
              Practice Considered Harmful", draft-ietf-intarea-hostname-
              practice-02 (work in progress), May 2016.

   [I-D.ietf-tls-tls13]
              Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", draft-ietf-tls-tls13-13 (work in progress),
              May 2016.

   [KW14a]    Kaiser, D. and M. Waldvogel, "Adding Privacy to Multicast
              DNS Service Discovery", DOI 10.1109/TrustCom.2014.107,
              2014, <http://ieeexplore.ieee.org/xpl/
              articleDetails.jsp?arnumber=7011331>.

   [KW14b]    Kaiser, D. and M. Waldvogel, "Efficient Privacy Preserving
              Multicast DNS Service Discovery",
              DOI 10.1109/HPCC.2014.141, 2014,
              <http://ieeexplore.ieee.org/xpl/
              articleDetails.jsp?arnumber=7056899>.






Huitema & Kaiser        Expires December 12, 2016              [Page 24]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


   [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>.

   [RFC7844]  Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
              Profiles for DHCP Clients", RFC 7844,
              DOI 10.17487/RFC7844, May 2016,
              <http://www.rfc-editor.org/info/rfc7844>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <http://www.rfc-editor.org/info/rfc7858>.

Authors' Addresses

   Christian Huitema
   Microsoft
   Redmond, WA  98052
   U.S.A.

   Email: huitema@microsoft.com








Huitema & Kaiser        Expires December 12, 2016              [Page 25]

Internet-Draft          DNS-SD Privacy Extensions              June 2016


   Daniel Kaiser
   University of Konstanz
   Konstanz  78457
   Germany

   Email: daniel.kaiser@uni-konstanz.de













































Huitema & Kaiser        Expires December 12, 2016              [Page 26]