RFC 8882

DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements

📅 published September 2020, from ietf

RFC 8882 💖 DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements

okay bestie, this one is RFC 8882 🎀 It's an Informational doc (not a Standards Track spec, just published for info 📚), written by C. Huitema from Private Octopus Inc. and D. Kaiser from the University of Luxembourg. It's dated September 2020 and its ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so it's kinda a standalone vibe ✨

Abstract

okay so DNS-SD (DNS-based Service Discovery) usually shares a lot of info about the devices that offer services and the ones looking for them 👀 That includes hostnames, network parameters, and maybe a description of the service instance. It gets really risky when phones and other mobile devices do DNS-SD on a public hotspot 😭 This doc looks at what a privacy-respecting discovery service would actually need 🫶

Status of This Memo

this is not a standards-track thing, it's published for informational purposes 🧚

this is an IETF product 💅 and it reflects the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is up for any level of Internet Standard, so check Section 2 of RFC 7841 if you're curious 🌸

for the current status, any errata, or to send feedback, go to https://www.rfc-editor.org/info/rfc8882 🔗

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.

this doc is under BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date. Read them carefully, bestie, they spell out your rights and restrictions for this doc 📜 If you pull Code Components out of this doc, they have to include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, same as the Simplified BSD License says 🫶

Table of Contents

   1.  Introduction
   2.  Threat Model
   3.  Threat Analysis
     3.1.  Service Discovery Scenarios
       3.1.1.  Private Client and Public Server
       3.1.2.  Private Client and Private Server
       3.1.3.  Wearable Client and Server
     3.2.  DNS-SD Privacy Considerations
       3.2.1.  Information Made Available Via DNS-SD Resource Records
       3.2.2.  Privacy Implication of Publishing Service Instance
               Names
       3.2.3.  Privacy Implication of Publishing Node Names
       3.2.4.  Privacy Implication of Publishing Service Attributes
       3.2.5.  Device Fingerprinting
       3.2.6.  Privacy Implication of Discovering Services
     3.3.  Security Considerations
       3.3.1.  Authenticity, Integrity, and Freshness
       3.3.2.  Confidentiality
       3.3.3.  Resistance to Dictionary Attacks
       3.3.4.  Resistance to Denial-of-Service Attacks
       3.3.5.  Resistance to Sender Impersonation
       3.3.6.  Sender Deniability
     3.4.  Operational Considerations
       3.4.1.  Power Management
       3.4.2.  Protocol Efficiency
       3.4.3.  Secure Initialization and Trust Models
       3.4.4.  External Dependencies
   4.  Requirements for a DNS-SD Privacy Extension
     4.1.  Private Client Requirements
     4.2.  Private Server Requirements
     4.3.  Security and Operation
   5.  IANA Considerations
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction ✨

okay so DNS-SD [RFC6763] running over Multicast DNS (mDNS) [RFC6762] gives you zero-configuration service discovery on local networks 🦋 It's super convenient, but it means you have to publicly expose both the offering and requesting identities, plus info about the services being offered and requested 😬 Some of that published info can seriously breach someone's privacy. These issues and possible fixes get covered in [KW14a], [KW14b], and [K17]. The multicast part of mDNS makes the risks super obvious, but honestly most of the risk comes from transactions being observable 👀 Server-based versions of DNS-SD need these risks handled too 💜

there are times when devices on a network want to offer or use services without showing their identities to everyone else on that same network 🧳 Imagine a traveler uploading pictures from their phone to a laptop while both are on an Internet cafe's Wi-Fi, or two travelers sharing files between laptops while waiting for their flight in an airport lounge ✈️

we expect these exchanges to kick off with a DNS-SD discovery over mDNS 🌈 One device announces that a service is available, like a picture library or a file store in our examples. The user on the other device finds that service and then connects to it 🫶

when we look at these scenarios in Section 3.1, we notice that DNS-SD messages leak identifying stuff, like the Service Instance Name, the hostname, or service properties 🙈 Here are the definitions we're using:

  • Identity: in this doc, "identity" means the identity of the entity (legal person) operating a device.
  • Disclosing an Identity: in this doc, "disclosing an identity" means showing the identity of operating entities to devices outside the discovery process, like devices on the same network link that are listening to traffic but aren't actually part of the discovery. This doc focuses on identity disclosure through data sent in messages at the service discovery protocol layer. Identity leaks at deeper layers, like the IP layer, get mentioned too 🧚
  • Disclosing Information: in this doc, "disclosing information" also focuses on data sent in service discovery protocol messages. That covers both identity-revealing info and other data that could still be sensitive 💅

2. Threat Model 👑

this doc looks at the following attacker types, sorted from least to most powerful 🔥 Every one of them can be passive (they just listen to network traffic they can access) or active (they can also craft and send malicious packets) 🕵️‍♀️

  • external: an external attacker is not on the same network link as the victim devices doing service discovery. So they're in a different multicast domain 🌍
  • on-link: an on-link attacker is on the same network link as the victim devices doing service discovery. So they're in the same multicast domain. They can also pull off every attack an external attacker can 💀
  • MITM: a Man-in-the-Middle (MITM) attacker either controls (parts of) a network link or can trick two parties into sending traffic through the attacker. So they can see unicast traffic between devices doing service discovery. They can also do everything an on-link attacker can 😭

3. Threat Analysis 🔍

in this section we dig into how the attackers from the last section could threaten the privacy of the people operating devices that take part in service discovery 💖 We focus on attacks that use data sent in service discovery protocol messages ✨

3.1. Service Discovery Scenarios 🎀

in this section we go over common service discovery scenarios and talk about the privacy threats and privacy requirements that come with them. In all three of these common scenarios, the attacker is passive on-link 🫣

3.1.1. Private Client and Public Server 🧳

okay this is probably the simplest private discovery scenario: one client connects to a public server over a public network 🖨️ A classic example is a traveler using a publicly available printer in a business center, a hotel, or an airport.

                                        ( Taking notes:
                                        ( David is printing
                                        ( a document.
                                         ~~~~~~~~~~~
                                                     o
            ___                                        o   ___
           /   \                                         _|___|_
           |   |   client                server           |* *|
            \_/      __                                    \_/
             |      / /   Discovery   +----------+          |
            /|\    /_/  <-----------> |  +----+  |         /|\
           / | \__/                   +--|    |--+        / | \
          /  |                           |____/          /  |  \
         /   |                                          /   |   \
            / \                                            / \
           /   \                                          /   \
          /     \                                        /     \
         /       \                                      /       \
        /         \                                    /         \

           David                                        Adversary

in this scenario the server is public and wants to be found, but the client is private 🥺 The adversary is listening to the network traffic, trying to figure out who the visitors are and what they're up to 👀 Identifying devices leads to identifying people, whether that's for keeping tabs on them in the real world or as a first step toward a targeted cyber attack 💀

so the requirement here is that the discovery activity should not disclose the identity of the client 🫶

3.1.2. Private Client and Private Server

okay so the second private discovery scenario is giving two people vibing on a collab app 🫶 like in an airport lounge, which is literally the most public place ever 🧳. one device acts as the server and the other acts as the client. the server wants to be found by the client but absolutely does NOT want to be found by anyone else 🙈

                                           ( Taking notes:
                                           ( David is meeting
                                           ( with Stuart.
                                             ~~~~~~~~~~~
                                                        o
            ___                               ___         o   ___
           /   \                             /   \          _|___|_
           |   |   server          client    |   |           |* *|
            \_/      __               __      \_/             \_/
             |      / /   Discovery   \ \      |               |
            /|\    /_/  <----------->  \_\    /|\             /|\
           / | \__/                       \__/ | \           / | \
          /  |                                 |  \         /  |  \
         /   |                                 |   \       /   |   \
            / \                               / \             / \
           /   \                             /   \           /   \
          /     \                           /     \         /     \
         /       \                         /       \       /       \
        /         \                       /         \     /         \

          David                              Stuart        Adversary

the adversary is lurking and listening to network traffic 👀 trying to figure out who the devices belong to, same as in the first scenario, but also trying to see the patterns of traffic. ngl that's the scary part, because those patterns reveal the business and social interactions between the owners of the devices 💀

so the requirement here is that the discovery activity should not disclose the identity of either the client or the server, and it also should not reveal the business and social interactions between the owners of the devices 🔒✨

3.1.3. Wearable Client and Server

now the third one is all about wearables ⌚💜 think the smartwatch on someone's wrist chatting with the phone in their pocket. super normal, super relatable, and also super leaky if nobody's paying attention 🙃

                                        ( Taking notes:
                                        ( David is here. His watch is
                                        ( talking to his phone.
                                          ~~~~~~~~~~~
                                                      o
            ___                                         o  ___
           /   \                                         _|___|_
           |   |   client                                 |* *|
            \_/                                            \_/
             |     _/                                       |
            /|\   //                                       /|\
           / | \__/  ^                                    / | \
          /  |__     | Discovery                         /  |  \
         /   |\ \    v                                  /   |   \
            / \\_\                                         / \
           /   \   server                                 /   \
          /     \                                        /     \
         /       \                                      /       \
        /         \                                    /         \

           David                                        Adversary

this scenario is kinda like the second one, honestly 🦋 there are two devices, one is the server and one is the client, and the requirement is the same: the discovery traffic must not disclose the identity of either the client or the server. the big difference is that one single owner manages both devices, which opens up different ways to set up secure relations between them. there's also extra emphasis on hiding what type of devices the person wears 🤫

the adversary isn't just tracking who the owner is either. they're also interested in the characteristics of the devices, like type, brand, and model 👀 knowing the device type can lead to further attacks, from theft all the way to device-specific hacking 😱 and when you combine all the devices one person wears, you get a "fingerprint" of that person, which risks identifying them 🫣

this scenario also stands in for the general case of bringing private Internet-of-Things (IoT) devices into public places 🌸 a wearable IoT device might act as a DNS-SD/mDNS client, and that lets attackers infer information about the devices' owners. the attacker might be a single person like in the example figure, but this could also be abused for large-scale data collection, with stationary IoT-device-tracking servers installed in frequented public places 🏪 yikes.

the issues described in Section 3.1.1, like identifying people or using the information for targeted attacks, apply here too 💅

3.2. DNS-SD Privacy Considerations

okay so the discovery process in the scenarios from Section 3.1 would most likely be based on [RFC6762] for making service information available 🧚 but this document looks at all kinds of ways to make DNS-SD resource records available, not just that one. these means comprise of but are not limited to mDNS [RFC6762], DNS servers ([RFC1033], [RFC1034], and [RFC1035]), the use of Service Registration Protocol (SRP) [SRP], and multi-link [RFC7558] networks 🌐

the discovery scenarios in Section 3.1 show three separate abstract privacy requirements, and which one you need depends on the use case. and these aren't limited to mDNS either 🎀

  1. Client identity privacy: Client identities are not leaked during service discovery or use.
  2. Multi-entity, mutual client and server identity privacy: Neither client nor server identities are leaked during service discovery or use.
  3. Single-entity, mutual client and server identity privacy: Identities of clients and servers owned and managed by the same legal person are not leaked during service discovery or use.

in this section we're going to walk through aspects of DNS-SD that make these requirements really hard to achieve in practice 😤 we're trying to be thorough, but it's not possible to be exhaustive, so bear with us 🫶

client identity privacy can be thwarted by a passive attacker (see Section 2) if it isn't handled properly 👻 which kind of passive attacker you're dealing with depends on how the service information is made available. information sent via multicast messages can be obtained by an on-link attacker. unicast messages are harder to access, but if the transmission isn't encrypted, they could still be accessed by an attacker with access to network routers or bridges. and if you're using multi-link service discovery solutions [RFC7558], external attackers have to be taken into consideration too, for example when multicast messages get relayed to other links 🔁

server identity privacy can be thwarted by a passive attacker in the same way as client identity privacy 🙃 on top of that, active attackers who are querying for information also have to be taken into consideration. this is mainly relevant for unicast-based discovery, where listening to discovery traffic requires a MITM attacker. however, an external active attacker might be able to learn the server identity just by querying for service information, for example via DNS 😬

3.2.1. Information Made Available Via DNS-SD Resource Records

okay so DNS-Based Service Discovery (DNS-SD) is defined in [RFC6763] 📖 it lets nodes publish the availability of an instance of a service by inserting specific records in the DNS ([RFC1033], [RFC1034], and [RFC1035]) or by publishing those 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.

3.2.2. Privacy Implication of Publishing Service Instance Names

so in the first phase of discovery, clients grab all the PTR records associated with a service type in a given naming domain 🔍 each PTR record contains a Service Instance Name, which is defined in Section 4 of [RFC6763]:

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

the <Instance> part is supposed to give users of discovery clients enough info to easily pick the service instance they want 💖 nodes that use DNS-SD over mDNS [RFC6762] in a mobile environment rely on how specific the instance name is to find the right service. so picture Alice wanting to upload pics to a laptop at an Internet cafe ☕📸 the list of available service instances might look something like this:

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

Alice sees the list on her phone and instantly knows to pick the first item ✨ the discovery just works, bestie 🥰 (quick note: our service name examples follow the spec in Section 4.1 of [RFC6763], but they may need some character escaping when you enter them in regular DNS software 🛠️)

BUT 😭 DNS-SD/mDNS will reveal to literally anybody that Alice is currently at the Internet cafe 🫣 it also spills that she has two devices, shares an image store, and uses a chat app that supports the _presence protocol on both of them. she might be chatting with Bob or Carol right now too, since they're also using a _presence-supporting chat app 👀 and this info isn't only available to devices actively browsing for and offering services. anybody passively listening to the network traffic can see it too, which is a passive on-link attacker 💀

and there's no authentication requirement to claim a particular instance name, so an active attacker can offer resources that claim to be Alice's when they totally aren't 🙃🚩

3.2.3. Privacy Implication of Publishing Node Names

the SRV records contain the DNS name of the node publishing the service 🖥️ typical implementations build this DNS name by sticking the node's "hostname" onto the name of the local domain. the privacy implications of this practice are reviewed in [RFC8117] 📚 depending on naming practices, the hostname is either a strong identifier of the device or, at the very least, a partial identifier 🫠 and that means it can enable tracking of both the device and, by extension, the device's owner 🕵️‍♀️💔

Okay bestie, picking right back up with the privacy stuff 🦋

3.2.4. Privacy Implication of Publishing Service Attributes ✨

The TXT record's attribute-value pairs hold info about the characteristics of the service instance, and ngl that tells people a lot about the devices publishing those services 👀 The amount of info totally varies depending on the service and how it's implemented:

  • Some attributes, like the paper size a printer supports, are the same across tons of devices, so they only give a tracker a little bit of info 🖨️
  • Attributes with free-form values, like the name of a directory, can reveal way more 😬

Combos of attributes are even more powerful than single ones, and they can be used for "fingerprinting" a specific device 🕵️‍♀️ It's giving detective energy, and not in a cute way.

Okay, and this part is so important: TXT records don't just make devices trackable, they can literally contain private info about the user 💀 For example, the _presence service shows the "chat status" to everyone on the same network. Users might have no idea that's happening 🙈

Also, TXT records often include version info about services, which hands potential attackers a list of devices running exploit-prone versions of a service 😱 Not the vibe at all.

3.2.5. Device Fingerprinting 🔍

Putting together everything published over DNS-SD can create a "fingerprint" of a specific device 💅 The stuff that goes into that includes:

  • A list of the services the device publishes, which anyone can retrieve because the SRV records all point to the same hostname 📋
  • Specific attributes describing those services 🏷️
  • Port numbers used by the services 🔌
  • Priority and weight attributes in the SRV records ⚖️

That combo will often be enough to figure out the version of software running on a device 💻 And if a device publishes a bunch of services with lots of detailed attributes, the combo might be enough to pin down the exact device and track its owner 😭

Sometimes people argue that you can just spot devices offering services by watching local traffic, so trying to hide the service is pointless. BUT there are good reasons for the discovery layer to avoid unnecessary exposure anyway, bestie:

  1. Privacy at the discovery layer is super important for automatically configured privacy-preserving network apps 🫶 Application protocols aren't forced to use that privacy, but if device tracking isn't stopped at the deeper layers, including the service discovery layer, then hiding a service's protocol at the application layer is futile 🙃
  2. Also, with mDNS-based discovery, even if the application layer doesn't protect privacy, services are usually offered via unicast, which takes a MITM attacker. Meanwhile, spotting services from multicast discovery messages only takes an on-link attacker 👀 Way easier to pull off, so the bar is lower.

The same logic goes further: the pattern of services a device offers could also help fingerprint it. That may or may not be true, since services can be designed or updated to avoid leaking fingerprints ✨ Either way, the discovery service design should avoid making a bad situation worse and should, as much as possible, avoid giving new fingerprinting info 🌸

3.2.6. Privacy Implication of Discovering Services 🧚

Consumers of services do discovery too, and in doing so they reveal some info, like which services they're interested in and which domains they're searching in 👀 When clients pick specific service instances, they also reveal their preference for those instances. For super common service types that's basically harmless 🍓 but for sensitive services, like some private messaging ones, it could be way more problematic 😬

One way to protect clients would be to somehow encrypt the requested service types. BUT, just like we noted in Section 3.2.5, traffic analysis can often still reveal the service 🙈

3.3. Security Considerations 🔐

For each of the operations described above, we also have to think about the security threats we're worried about 💜

3.3.1. Authenticity, Integrity, and Freshness 💖

Can devices (both servers and clients) trust the info they receive? Was it modified in flight by an adversary? Can devices trust where the info came from? Is the info fresh, meaning not replayed? 😳 Freshness may or may not be required, depending on whether the discovery process is meant to be online. In some cases, publishing discovery info to a shared directory or registry, instead of to each online recipient through a broadcast channel, may be enough ✨

3.3.2. Confidentiality 🤫

Confidentiality is all about restricting info access to only authorized individuals 🔒 Ideally that should only be the appropriate trusted parties, though it can be tricky to define who "the appropriate trusted parties" even are. In some use cases, it may mean that only mutually authenticated and trusting clients and servers can read messages sent to one another 🫶 The discovery process in particular is often used to find new entities the device didn't know about before, so it can be tricky to figure out how a device can have an established trust relationship with a brand-new entity it's never talked to 😵‍💫

3.3.3. Resistance to Dictionary Attacks 📖

It can be super tempting to use (publicly computable) hash functions to hide sensitive identifiers 🙃 This turns a sensitive unique identifier, like an email address, into a "scrambled" but still unique identifier. Unfortunately, simple solutions may be vulnerable to offline dictionary attacks 💀

3.3.4. Resistance to Denial-of-Service Attacks 🛡️

In any protocol where the receiver of messages has to do cryptographic operations on those messages, there's a risk of a brute-force flooding attack making the receiver burn through excessive CPU time and, where it applies, battery power just processing and discarding those messages 🔋😩

Amplification attacks also have to be taken into consideration 📢 Messages with larger payloads should only be sent as an answer to a query sent by a verified client.

3.3.5. Resistance to Sender Impersonation 🎭

Sender impersonation is an attack where messages, like service offers, get forged by entities that don't have the corresponding secret key material 🕵️ These attacks may be used to learn the identity of a communicating party, actively or passively 👀

3.3.6. Sender Deniability 🫥

Being able to deny you sent something, like broadcasting a discovery request, may be desirable or even necessary in some use cases 🦋 This property makes sure eavesdroppers can't prove senders issued a specific message meant for one or more peers ✨

3.4. Operational Considerations ⚙️

3.4.1. Power Management 🔋

Lots of modern devices, especially battery-powered ones, use power management techniques to save energy 💡 One such technique is for a device to transfer info about itself to a proxy, which acts on the device's behalf for some functions while the device itself goes to sleep to cut down on power use 😴 When the proxy decides some action is needed that only the device itself can perform, the proxy may have some way to wake the device, as described for example in [SLEEP-PROXY] ⏰

In many cases, the device may not trust the network proxy enough to share all its confidential key material with it 🥺 That makes it tough to combine private discovery, which relies on per-query cryptographic operations, with energy-saving techniques that have (somewhat untrusted) network proxies answer queries for sleeping devices 😭

3.4.2. Protocol Efficiency 🏃‍♀️

Designing a discovery protocol with the security properties we want can end up being inefficient 😮‍💨 To do the necessary operations, the protocol may need to send and receive a large number of network packets, or need an inordinate number of multicast transmissions. That can eat an unreasonable amount of network capacity, which is especially rough when it's shared wireless spectrum 📶 It may also cause unnecessary power consumption, which is particularly bad for battery devices and can make discovery slow 🐌

Designing a discovery protocol that hides what it's doing from unauthorized observers and still performs efficiently is a genuinely hard challenge 🧠✨

3.4.3. Secure Initialization and Trust Models 🤝

One challenge hiding in all the stuff above: whenever we talk about "trusted entities" versus "untrusted entities," there has to be some way to initially establish trust that converts an "untrusted entity" into a "trusted entity" 🔑

This document doesn't define the specific way trust gets established 🙅‍♀️ Protocol designers can rely on a bunch of existing tech, including PKI, Trust On First Use (TOFU), or using a short passphrase or PIN with cryptographic algorithms, like Secure Remote Password (SRP) [RFC5054], or a Password-Authenticated Key Exchange like J-PAKE [RFC8236] using a Schnorr Non-interactive Zero-Knowledge Proof [RFC8235] 🧩

Designers should also watch out for a specific usability pitfall when trust is established right before discovery is performed 😬 Users have a tendency to "click OK" just to get their task done 🖱️ That implicit vulnerability is avoided if trust establishment requires more significant user participation, like entering a password or PIN 🔐

3.4.4. External Dependencies 🌐

Trust establishment may depend on external parties 🫣 Optionally, this might involve synchronous communication. Systems with that kind of dependency may be attacked by interfering with communication to the external dependencies 💥 Where possible, those dependencies should be minimized. Local trust models are best for secure initialization in the presence of active attackers 🏡💜

4. Requirements for a DNS-SD Privacy Extension ✨

Okay bestie, now that we've covered all the spicy threats 🌸, it's time for the requirements! These are the things a privacy-preserving DNS-SD has to actually do. 💅

If we build to these requirements, the goal is a solution that never sends privacy-violating DNS-SD messages and doesn't accidentally open new doors for attackers to mess with how DNS-SD works. 🔐

This doc also gives advice on which privacy-protecting mechanisms should be used on deeper-layer network protocols, and on how to actually connect to services in a privacy-preserving way. Writing requirements for those is out of scope though 👀. To mitigate privacy attacks on lower layers, both servers and clients must use privacy options available at lower layers and, for example, avoid publishing static IPv4 or IPv6 addresses or static IEEE 802 Media Access Control (MAC) addresses. For services advertised on a single network link, link-local IP addresses should be used; see [RFC3927] and [RFC4291] for IPv4 and IPv6, respectively. Static servers advertising services globally via DNS can hide their IP addresses from unauthorized clients using the split mode topology shown in Encrypted Server Name Indication [ESNI]. Hiding static MAC addresses can be achieved via MAC address randomization (see [RFC7844]). 🫶

4.1. Private Client Requirements 🙈

For all three scenarios described in Section 3.1, client privacy requires DNS-SD messages to:

  1. Avoid disclosure of the client's identity, either directly or via inference, to nodes other than select servers.
  2. Avoid exposure of linkable identifiers that allow tracing client devices.
  3. Avoid disclosure of the client's interest in specific service instances or service types to nodes other than select servers.

When listing and resolving services via current DNS-SD deployments, clients typically disclose their interest in specific service types and specific instances of these types, respectively. It's giving overshare 😭.

In addition to the exposure and disclosure risks noted above, protocols and implementations will have to consider fingerprinting attacks (see Section 3.2.5) that could retrieve similar information. 🕵️‍♀️

4.2. Private Server Requirements 🎀

Servers like the "printer" discussed in Section 3.1.1 are public, but the servers discussed in Sections 3.1.2 and 3.1.3 are, by essence, private. Server privacy requires DNS-SD messages to:

  1. Avoid disclosure of the server's identity, either directly or via inference, to nodes other than authorized clients. In particular, servers must avoid publishing static identifiers, such as hostnames or service names. When those fields are required by the protocol, servers should publish randomized values. (See [RFC8117] for a discussion of hostnames.)
  2. Avoid exposure of linkable identifiers that allow tracing servers.
  3. Avoid disclosure to unauthorized clients of Service Instance Names or service types of offered services.
  4. Avoid disclosure to unauthorized clients of information about the services they offer.
  5. Avoid disclosure of static IPv4 or IPv6 addresses.

When offering services via current DNS-SD deployments, servers typically disclose their hostnames (SRV, A/AAAA), instance names of offered services (PTR, SRV), and information about services (TXT). Heeding these requirements protects a server's privacy on the DNS-SD level. 🦋

The current DNS-SD user interfaces present the list of discovered service names to the users and let them pick a service from the list. Using random identifiers for service names renders that UI flow unusable. 💀 Privacy-respecting discovery protocols will have to solve this issue, for example, by presenting authenticated or decrypted service names instead of the randomized values. ✨

4.3. Security and Operation 🔥

In order to be secure and feasible, a DNS-SD privacy extension needs to consider security and operational requirements including:

  1. Avoiding significant CPU overhead on nodes or significantly higher network load. Such overhead or load would make nodes vulnerable to denial-of-service attacks. Further, it would increase power consumption, which is damaging for IoT devices. 🔋
  2. Avoiding designs in which a small message can trigger a large amount of traffic towards an unverified address, as this could be exploited in amplification attacks. 🚨

5. IANA Considerations 🌈

Nothing for IANA this time! 🙌 This document has no IANA actions.

6. References 📚

6.1. Normative References

6.2. Informative References

Acknowledgments 🫶

This document is packed with contributions from Stuart Cheshire and Chris Wood, so big thanks to them! 💜 Thanks also to Florian Adamsky for an extensive review and suggestions on how the threat model is organized, to Barry Leiba for an extensive review, and to Roman Danyliw, Ben Kaduk, Adam Roach, and Alissa Cooper for their comments during IESG review. 👑

Authors' Addresses 💌

Christian Huitema
Private Octopus Inc.
Friday Harbor, WA 98250
United States of America

Email: huitema@huitema.net
URI:   http://privateoctopus.com/


Daniel Kaiser
University of Luxembourg
6, avenue de la Fonte
L-4364 Esch-sur-Alzette
Luxembourg

Email: daniel.kaiser@uni.lu
URI:   https://secan-lab.uni.lu/
📦 where this page comes from