--- 1/draft-ietf-dnssd-privacy-02.txt 2017-09-10 22:13:15.707159541 -0700 +++ 2/draft-ietf-dnssd-privacy-03.txt 2017-09-10 22:13:15.755160684 -0700 @@ -1,19 +1,19 @@ Network Working Group C. Huitema Internet-Draft Private Octopus Inc. Intended status: Standards Track D. Kaiser -Expires: January 4, 2018 University of Konstanz - July 3, 2017 +Expires: March 14, 2018 University of Konstanz + September 10, 2017 Privacy Extensions for DNS-SD - draft-ietf-dnssd-privacy-02.txt + draft-ietf-dnssd-privacy-03 Abstract DNS-SD (DNS Service Discovery) normally discloses information about both the devices offering services and the devices requesting services. This information includes host names, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS Service Discovery over Multicast DNS at a public hotspot, a serious privacy problem arises. @@ -28,37 +28,37 @@ 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/. + Drafts is at https://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 January 4, 2018. + This Internet-Draft will expire on March 14, 2018. Copyright Notice Copyright (c) 2017 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 + (https://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 @@ -77,38 +77,40 @@ 3.2.3. Using a Short Proof . . . . . . . . . . . . . . . . . 10 3.2.4. Direct Queries . . . . . . . . . . . . . . . . . . . 12 3.3. Private Discovery Service . . . . . . . . . . . . . . . . 12 3.3.1. A Note on Private DNS Services . . . . . . . . . . . 13 3.4. Randomized Host Names . . . . . . . . . . . . . . . . . . 14 3.5. Timing of Obfuscation and Randomization . . . . . . . . . 14 4. Private Discovery Service Specification . . . . . . . . . . . 14 4.1. Host Name Randomization . . . . . . . . . . . . . . . . . 15 4.2. Device Pairing . . . . . . . . . . . . . . . . . . . . . 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.5. Discovering Private Discovery Service Instances . . . . . 17 4.6. Direct Discovery of Private Discovery Service Instances . 18 - 4.7. Using the Private Discovery Service . . . . . . . . . . . 18 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 4.7. Using the Private Discovery Service . . . . . . . . . . . 19 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5.1. Attacks Against the Pairing System . . . . . . . . . . . 19 5.2. Denial of Discovery of the Private Discovery Service . . 19 5.3. Replay Attacks Against Discovery of the Private Discovery - Service . . . . . . . . . . . . . . . . . . . . . . . . . 19 + Service . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.4. Denial of 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 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 - 8.2. Informative References . . . . . . . . . . . . . . . . . 22 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 22 + 8.2. Informative References . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction DNS-SD [RFC6763] over mDNS [RFC6762] enables configurationless service discovery in local networks. 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. Parts of the published information can seriously breach the user's privacy. These privacy issues and potential solutions are discussed in [KW14a] and [KW14b]. @@ -194,21 +196,21 @@ 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. + anybody passively listening 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 [RFC8117]. 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 both the device, and, by @@ -302,22 +304,22 @@ services, such as for example some private messaging services. 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. 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. The - solution is largely based on the architecture proposed in [KW14b], - which separates the general private discovery problem in three + solution is largely based on the architecture proposed in [KW14b] and + [K17], which separates the general private discovery problem in three components. The first component is an offline pairing mechanism, which is performed only once per pair of users. It establishes a shared secret over an authenticated channel, allowing devices to authenticate using this secret without user interaction at any later point in time. We use the pairing system proposed in [I-D.ietf-dnssd-pairing]. The further two components are online (in contrast to pairing they are performed anew each time joining a network) and compose the two service discovery stages, namely @@ -362,23 +364,23 @@ optionally mutually authenticated public keys or certificates added to a local web of trust. Public key technology has many advantages, but shared secrets are typically easier to handle on small devices. 3.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. + instances can be browsed using regular DNS-SD procedures, and then + filtered so that only instances offered by paired devices are + retained. 3.2.1. Obfuscated Instance Names The instance names for the Private Discovery Service are obfuscated, so that authorized peers can associate the instance with its publisher, but unauthorized peers can only observe what looks like a random name. To achieve this, the names are composed as the concatenation of a nonce and a proof, which is composed by hashing the nonce with a pairing key: @@ -409,38 +411,41 @@ 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 representation of the current time rounded to some period. With this convention, receivers can predict the nonces that will appear in the published instances. The publishers will have to create new records at the end of each rounding period. If the rounding period is set too short, they will have to repeat that very often, which is inefficient. On the other hand, if the rounding period is too long, the system may be exposed - to replay attacks. We propose to set a value of about 5 minutes, + 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. Receivers can pre-calculate all the M relevant proofs once per time interval and then establish a mapping from the corresponding instance names to the pairing data in form of a hash table. These M relevant proofs are the proofs resulting from hashing a host's M pairing keys alongside the current nonce. Each time they receive an instance name, they can test in O(1) time if the received service information is relevant or not. Unix defines a 32 bit time stamp as the number of seconds elapsed since January 1st, 1970 not counting leap seconds. The most - significant 24 bits of this 32 bit number represent the number of 256 - seconds intervals since the epoch. 256 seconds correspond to 4 - minutes and 16 seconds, which is close enough to our design goal of 5 - minutes. We will thus use this 24 bit number as nonce, represented - as 3 octets. + significant 20 bits of this 32 bit number represent the number of + 2048 seconds intervals since the epoch. 2048 seconds correspond to 34 + minutes and 8 seconds, which is close enough to our design goal of 30 + minutes. We will thus use this 20 bit number as nonce, which for + simplicity will be padded zeroes to 24 bits and encoded in 3 octets. For coping with time skew, receivers pre-calculate proofs for the respective next time interval and store hash tables for the last, the current, and the next time interval. When receiving a service instance name, receivers first check whether the nonce corresponds to the current, the last or the next time interval, and if so, check whether the instance name is in the corresponding hash table. For (approximately) meeting our design goal of 5 min validity, the last time interval may only be considered if the current one is less than half way over and the next time interval may only be considered if @@ -552,21 +557,21 @@ 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 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 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: @@ -591,37 +596,37 @@ like the "proof" described in Section 3.2, by concatenating a nonce and the hash of the nonce with the shared secret. 3.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 further published an UDP variant, DNS over DTLS [RFC8094], which would also be a candidate. - DPRIVE and Private Discovery solve however two somewhat different - problems. DPRIVE is concerned with the confidentiality of 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: + DPRIVE and Private Discovery, however, solve two somewhat different + problems. While DPRIVE is concerned with the confidentiality of DNS + transactions addressing the problems outlined in [RFC7626], 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. + o Neither DNS over TLS nor DNS over DTLS applies to mDNS. 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. 3.4. Randomized Host Names Instead of publishing their actual host names in the SRV records, nodes could publish randomized host names. That is the solution argued for in [RFC8117]. @@ -661,44 +666,40 @@ These components are detailed in the following subsections. 4.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 3.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 + 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. 4.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. Each shared secret MUST be a 256 bit randomly chosen number. We RECOMMEND using the pairing mechanism proposed in [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 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 4.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 @@ -729,94 +730,108 @@ The DNS-SD service type for the Private Discovery Service is "_pds._tcp". Each published instance describes one server and one pairing. In the 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. Each instance name is composed as follows: - pick a 24 bit nonce, set to the 24 most - significant bits of the 32 bit Unix GMT time. + pick a 24 bit nonce, set to the 20 most significant bits of the + 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: proof = first 48 bits of HASH(|) set the 72 bit binary identifier as the concatenation of nonce and proof set instance_name = 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 24 bit nonce and 48 bit proof result in a 72 bit string. The BASE64 conversion is 12 characters long per [RFC6763]. 4.5. Discovering Private Discovery Service Instances Nodes that wish to discover Private Discovery Service Instances SHOULD issue a DNS-SD discovery request for the service type "_pds._tcp". They MAY, as an alternative, use the Direct Discovery - procedure defined in Section 4.6. If nodes send a DNS-SD discovery - request, they will receive in response a series of PTR records, - providing the names of the instances present in the scope. + procedure defined in Section 4.6. When using the Direct Discovery + procedure over mDNS, nodes SHOULD always set the QU-bit (unicast + 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 mapping instance names to pairings according to the following conceptual algorithm: - nonce = 24 bit rounded time stamp of the\ - respective next time interval + nonce = 20 bit rounded time stamp of the \ + respective next time interval padded to \ + 24 bits with four zeroes for each available pairing retrieve the key Xj of pairing number j compute F = first 48 bits of hash(nonce, Xj) construct the binary instance_name as described\ in the previous section instance_names[nonce][instance_name] = Xj; The querier SHOULD store the hash tables for the previous, the current, and the next time interval. The querier SHOULD examine each instance to see whether it corresponds to 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 not multiple 72 bits, + if the binary instance length is not 72 bits, discard the instance. nonce = first 24 bits of binary. - Check that the nonce matches the first 24 bits of - the current time, or the previous interval (24 bit number + Check that the 4 least significant bits of the nonce + 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, - 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 nonce does not match an acceptable value, discard the instance. if ((Xj = instance_names[nonce][instance_name]) != null) mark the pairing number j as available The check of the current time is meant to mitigate replay attacks, - while not mandating a time synchronization precision better than two + while not mandating a time synchronization precision better than 15 minutes. 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 + proof, 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. 4.6. Direct Discovery of Private Discovery Service Instances Nodes that wish to discover Private Discovery Service Instances MAY use the following Direct Discovery procedure instead of the regular DNS-SD Discovery explained in Section 4.5. @@ -889,26 +904,20 @@ 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 4.4 start with 24 bits encoding the most significant bits of the "UNIX" time. In order to protect against replay attacks, clients SHOULD verify that this time is reasonably recent, as specified in Section 4.5. - [[TODO: Should we somehow encode the scope in the identifier? Having - 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 The Private Discovery Service is only available through a mutually authenticated TLS connection, which provides state-of-the-art protection mechanisms. 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 @@ -919,162 +928,193 @@ 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. 5.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 + 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 4.3.1 start with the 24 most significant bits of the "UNIX" time. In order to mitigate replay 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 the future. The processing of timestamps is however affected 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. +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 - This draft does not require any IANA action. (Or does it? What - about the _pds tag?) + This draft does not require any IANA action. 7. Acknowledgments 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.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, - . + . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, - . + . [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, - . + . [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6", RFC 4075, DOI 10.17487/RFC4075, May 2005, - . + . [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, - . + . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, - . + . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, - . + . 8.2. Informative References [I-D.ietf-dnssd-pairing] Huitema, C. and D. Kaiser, "Device Pairing Using Short - Authentication Strings", draft-ietf-dnssd-pairing-01 (work - in progress), March 2017. + Authentication Strings", draft-ietf-dnssd-pairing-02 (work + in progress), July 2017. [I-D.ietf-dnssd-push] 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] Rescorla, E., "The Transport Layer Security (TLS) Protocol - Version 1.3", draft-ietf-tls-tls13-20 (work in progress), - April 2017. + Version 1.3", draft-ietf-tls-tls13-21 (work in progress), + July 2017. + + [K17] Kaiser, D., "Efficient Privacy-Preserving + Configurationless Service Discovery Supporting Multi-Link + Networks", 2017, + . [KW14a] Kaiser, D. and M. Waldvogel, "Adding Privacy to Multicast DNS Service Discovery", DOI 10.1109/TrustCom.2014.107, 2014, . [KW14b] Kaiser, D. and M. Waldvogel, "Efficient Privacy Preserving Multicast DNS Service Discovery", DOI 10.1109/HPCC.2014.141, 2014, . [RFC1033] Lottor, M., "Domain Administrators Operations Guide", RFC 1033, DOI 10.17487/RFC1033, November 1987, - . + . [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, - . + . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, - November 1987, . + November 1987, . [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, - . + . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, - . + . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, - . + . [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, - . + . [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, - . + . [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, . + 2016, . [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, - . + . [RFC8117] Huitema, C., Thaler, D., and R. Winter, "Current Hostname Practice Considered Harmful", RFC 8117, DOI 10.17487/RFC8117, March 2017, - . + . Authors' Addresses Christian Huitema Private Octopus Inc. Friday Harbor, WA 98250 U.S.A. Email: huitema@huitema.net URI: http://privateoctopus.com/