--- 1/draft-ietf-dnssd-privacy-01.txt 2017-07-03 11:14:00.467580661 -0700 +++ 2/draft-ietf-dnssd-privacy-02.txt 2017-07-03 11:14:00.515581800 -0700 @@ -1,19 +1,19 @@ Network Working Group C. Huitema Internet-Draft Private Octopus Inc. Intended status: Standards Track D. Kaiser -Expires: September 11, 2017 University of Konstanz - March 10, 2017 +Expires: January 4, 2018 University of Konstanz + July 3, 2017 Privacy Extensions for DNS-SD - draft-ietf-dnssd-privacy-01.txt + draft-ietf-dnssd-privacy-02.txt 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. @@ -35,21 +35,21 @@ 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 11, 2017. + This Internet-Draft will expire on January 4, 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 publication of this document. Please review these documents @@ -61,64 +61,64 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 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 + 2.5. Privacy Implication of Discovering Services . . . . . . . 7 3. Design of the Private DNS-SD Discovery Service . . . . . . . 7 3.1. Device Pairing . . . . . . . . . . . . . . . . . . . . . 8 3.2. Discovery of the Private Discovery Service . . . . . . . 8 - 3.2.1. Obfuscated Instance Names . . . . . . . . . . . . . . 8 + 3.2.1. Obfuscated Instance Names . . . . . . . . . . . . . . 9 3.2.2. Using a Predictable Nonce . . . . . . . . . . . . . . 9 3.2.3. Using a Short Proof . . . . . . . . . . . . . . . . . 10 - 3.2.4. Direct Queries . . . . . . . . . . . . . . . . . . . 11 - 3.3. Private Discovery Service . . . . . . . . . . . . . . . . 11 - 3.3.1. A Note on Private DNS Services . . . . . . . . . . . 12 - 3.4. Randomized Host Names . . . . . . . . . . . . . . . . . . 13 - 3.5. Timing of Obfuscation and Randomization . . . . . . . . . 13 + 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 . . . . . . . . . . . . . . . . . 14 - 4.2. Device Pairing . . . . . . . . . . . . . . . . . . . . . 14 + 4.1. Host Name Randomization . . . . . . . . . . . . . . . . . 15 + 4.2. Device Pairing . . . . . . . . . . . . . . . . . . . . . 15 4.3. Private Discovery Server . . . . . . . . . . . . . . . . 15 - 4.3.1. Establishing TLS Connections . . . . . . . . . . . . 15 - 4.4. Publishing Private Discovery Service Instances . . . . . 15 - 4.5. Discovering Private Discovery Service Instances . . . . . 16 - 4.6. Direct Discovery of Private Discovery Service Instances . 17 - 4.7. Using the Private Discovery Service . . . . . . . . . . . 17 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 5.1. Attacks Against the Pairing System . . . . . . . . . . . 18 - 5.2. Denial of Discovery of the Private Discovery Service . . 18 + 4.3.1. Establishing TLS Connections . . . . . . . . . . . . 16 + 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 + 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 . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 5.4. Denial of Private Discovery Service . . . . . . . . . . . 19 - 5.5. Replay Attacks against the Private Discovery Service . . 19 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 - 8.2. Informative References . . . . . . . . . . . . . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 + Service . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 5.4. Denial of Private Discovery Service . . . . . . . . . . . 20 + 5.5. Replay Attacks against the Private Discovery Service . . 20 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 + 8.2. Informative References . . . . . . . . . . . . . . . . . 22 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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. Some of the information published by the - announcements can be very revealing. These privacy issues and - potential solutions are discussed in [KW14a] and [KW14b]. + 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]. 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 @@ -204,26 +204,26 @@ 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 [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 the device, and by extension of - the device's owner. + identifier. It enables tracking of both the device, and, by + extension, the device's owner. 2.3. Privacy Implication of Publishing Service Attributes - The TXT record's attribute and value pairs contain information on the + The TXT record's attribute-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 @@ -258,29 +258,45 @@ 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, and that trying to hide - the presence of the service is futile. The same argument can be - extended to say that the pattern of services offered by a device - allows for fingerprinting the device. This may or may not be true, - since we can expect that services will be designed or updated to - avoid leaking fingerprints. In any case, the design of the discovery - service should avoid making a bad situation worse, and should as much - as possible avoid providing new fingerprinting information. + A sometimes heard argument is that devices providing services can be + identified by observing the local traffic, and that trying to hide + the presence of the service is futile. This argument, however, does + not carry much weight because + + 1. proving privacy at the discovery layer is of the essence for + enabling automatically configured privacy-preserving network + applications. Application layer protocols are not forced to + leverage the offered privacy, but if device tracking is not + prevented at the deeper layers, including the service discovery + layer, obfuscating a certain service's protocol at the + application layer is futile. + + 2. Further, even if the application layer does not protect privacy, + it is hard to record and analyse the unicast traffic (which most + applications will generate) compared to just listening to the + multicast messages sent by DNS-SD/mDNS. + + The same argument can be extended to say that the pattern of services + offered by a device allows for fingerprinting the device. This may + or may not be true, since we can expect that services will be + designed or updated to avoid leaking fingerprints. In any case, the + design of the discovery service should avoid making a bad situation + worse, and should as much as possible avoid providing new + fingerprinting information. 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. @@ -332,21 +348,22 @@ 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". Device pairing has to be performed only once per pair of users. This is important for user-friendliness, as it is the only step that demands user-interaction. After this single pairing, privacy preserving service discovery works fully automatically. In this - document, we leverage [I-D.ietf-dnssd-pairing] as pairing mechanism. + document, we utilize [I-D.ietf-dnssd-pairing] as the pairing + mechanism. The pairing yields a mutually authenticated shared secret, and 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 @@ -386,38 +403,56 @@ records, and the node engaging in discovery may have to process on average N*M instance names. The discovering node will have to compute on average M potential hashes for each nonce. The number of hash computations would scale as O(N*M*M), which means that it could cause a significant drain of resource in large networks. 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. They will only need to compute O(M) hashes, - instead of O(N*M*M). + 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, 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. + 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 + the current time interval is more than half way over. + Publishers will need to compute O(M) hashes at most once per time stamp interval. If records can be created "on the fly", publishers will only need to perform that computation upon receipt of the first query during a given interval, and cache the computed results for the remainder of the interval. There are however scenarios in which records have to be produced in advance, for example when records are published within a scope defined by a domain name and managed by a "classic" DNS server. In such scenarios, publishers will need to perform the computations and publication exactly once per time stamp interval. @@ -425,21 +460,21 @@ 3.2.3. Using a Short Proof Devices will have to publish as many instance names as they have peers. The instance names will have to be represented via a text string, which means that the binary concatenation of nonce and proof will have to be encoded using a binary-to-text conversion such as BASE64 ([RFC2045] section 6.8) or BASE32 ([RFC4648] section 6). Using long proofs, such as the full output of SHA256 [RFC4055], would generate fairly long instance names: 48 characters using BASE64, or - 56 using BASE56. These long names would inflate the network traffic + 56 using BASE32. These long names would inflate the network traffic required when discovering the privacy service. They would also limit the number of DNS-SD PTR records that could be packed in a single 1500 octet sized packet, to 23 or fewer with BASE64, or 20 or fewer with BASE32. Shorter proofs lead to shorter messages, which is more efficient as long as we do not encounter too many collisions. A collision will happen if the proof computed by the publisher using one key matches a proof computed by a receiver using another key. If a receiver mistakenly believes that a proof fits one of its peers, it will @@ -514,29 +549,29 @@ 3.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 + 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 defined in [RFC7858]. The main difference with plain 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 + 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: opaque psk_identity<0..2^16-1>; struct { select (Role) { case client: @@ -553,22 +588,22 @@ 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 "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 - is also working on an UDP variant, DNS over DTLS - [I-D.ietf-dprive-dnsodtls], which would also be a candidate. + 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: o Discovery queries are scoped by the domain name within which services are published. As nodes move and visit arbitrary @@ -580,23 +615,23 @@ to discover the content of PTR, SRV and TXT records. 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 name in the SRV records, nodes - could publish a randomized name. That is the solution argued for in - [RFC8117]. + 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]. 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. 3.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 @@ -690,118 +725,135 @@ 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._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 all available pairings. + 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. 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-ID = BASE64(binary identifier) + 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. + 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 + 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: + 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, discard the instance. nonce = first 24 bits of binary. - if nonce does not match the first 24 bits of the current - time plus or minus 1 minute, discard the instance. + Check that the nonce matches the first 24 bits of + the current time, or the previous interval (24 bit number + minus 1) if the current interval is less than half over, + or the next interval (24 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. - for each available pairing - retrieve the key Xj of pairing number j - compute F = first 48 bits of hash(nonce, Xj) - if F is equal to the last 48 bits of - the binary instance ID + 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 one - minute. + while not mandating a time synchronization precision better than two + 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 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. To perform Direct Discovery, nodes should compose a list of Private Discovery Service Instances Names. There will be one name for each - pairing available to the node. The Instance ID for each name will be - composed of a nonce and a proof, using the algorithm specified in + pairing available to the node. The Instance name for each name will + be composed of a nonce and a proof, using the algorithm specified in Section 4.4. The querier will issue SRV record queries for each of these names. The queries will only succeed if the corresponding instance is present, in which case a pairing is discovered. After that, the querier SHOULD try connecting to the corresponding instance, as explained in Section 4.4. 4.7. Using the Private Discovery Service Once instances of the Private Discovery Service have been discovered, peers can establish TLS connections and send DNS requests over these connections, as specified in DNS-SD. 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. 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. + This document specifies a method for protecting the privacy of nodes + that offer and query for services. 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. 5.1. Attacks Against the Pairing System There are a variety of attacks against pairing systems, which may result in compromised pairing secrets. If an adversary manages to acquire a compromised key, the adversary will be able to perform private service discovery according to Section 4.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. @@ -841,21 +893,21 @@ 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 ID.]] + 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. @@ -943,31 +995,26 @@ 8.2. Informative References [I-D.ietf-dnssd-pairing] Huitema, C. and D. Kaiser, "Device Pairing Using Short Authentication Strings", draft-ietf-dnssd-pairing-01 (work in progress), March 2017. [I-D.ietf-dnssd-push] Pusateri, T. and S. Cheshire, "DNS Push Notifications", - draft-ietf-dnssd-push-09 (work in progress), October 2016. - - [I-D.ietf-dprive-dnsodtls] - Reddy, T., Wing, D., and P. Patil, "Specification for DNS - over Datagram Transport Layer Security (DTLS)", draft- - ietf-dprive-dnsodtls-15 (work in progress), December 2016. + draft-ietf-dnssd-push-11 (work in progress), June 2017. [I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol - Version 1.3", draft-ietf-tls-tls13-18 (work in progress), - October 2016. + Version 1.3", draft-ietf-tls-tls13-20 (work in progress), + April 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, . [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, . + [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