idnits 2.17.1 draft-ietf-dnssd-prireq-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2020) is 1503 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-25) exists of draft-ietf-dnssd-srp-02 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Huitema 3 Internet-Draft Private Octopus Inc. 4 Intended status: Informational D. Kaiser 5 Expires: September 13, 2020 University of Luxembourg 6 March 12, 2020 8 DNS-SD Privacy and Security Requirements 9 draft-ietf-dnssd-prireq-08 11 Abstract 13 DNS-SD (DNS Service Discovery) normally discloses information about 14 devices offering and requesting services. This information includes 15 host names, network parameters, and possibly a further description of 16 the corresponding service instance. Especially when mobile devices 17 engage in DNS Service Discovery at a public hotspot, serious privacy 18 problems arise. We analyze the requirements of a privacy-respecting 19 discovery service. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 13, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Service Discovery Scenarios . . . . . . . . . . . . . . . 4 59 3.1.1. Private Client and Public Server . . . . . . . . . . 4 60 3.1.2. Private Client and Private Server . . . . . . . . . . 5 61 3.1.3. Wearable Client and Server . . . . . . . . . . . . . 6 62 3.2. DNS-SD Privacy Considerations . . . . . . . . . . . . . . 8 63 3.2.1. Information made available via DNS-SD Resource 64 Records . . . . . . . . . . . . . . . . . . . . . . . 9 65 3.2.2. Privacy Implication of Publishing Service Instance 66 Names . . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.2.3. Privacy Implication of Publishing Node Names . . . . 10 68 3.2.4. Privacy Implication of Publishing Service Attributes 10 69 3.2.5. Device Fingerprinting . . . . . . . . . . . . . . . . 11 70 3.2.6. Privacy Implication of Discovering Services . . . . . 12 71 3.3. Security Considerations . . . . . . . . . . . . . . . . . 12 72 3.3.1. Authenticity, Integrity & Freshness . . . . . . . . . 12 73 3.3.2. Confidentiality . . . . . . . . . . . . . . . . . . . 12 74 3.3.3. Resistance to Dictionary Attacks . . . . . . . . . . 13 75 3.3.4. Resistance to Denial-of-Service Attacks . . . . . . . 13 76 3.3.5. Resistance to Sender Impersonation . . . . . . . . . 13 77 3.3.6. Sender Deniability . . . . . . . . . . . . . . . . . 13 78 3.4. Operational Considerations . . . . . . . . . . . . . . . 13 79 3.4.1. Power Management . . . . . . . . . . . . . . . . . . 13 80 3.4.2. Protocol Efficiency . . . . . . . . . . . . . . . . . 14 81 3.4.3. Secure Initialization and Trust Models . . . . . . . 14 82 3.4.4. External Dependencies . . . . . . . . . . . . . . . . 15 83 4. Requirements for a DNS-SD Privacy Extension . . . . . . . . . 15 84 4.1. Private Client Requirements . . . . . . . . . . . . . . . 15 85 4.2. Private Server Requirements . . . . . . . . . . . . . . . 16 86 4.3. Security and Operation . . . . . . . . . . . . . . . . . 17 87 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 88 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 91 7.2. Informative References . . . . . . . . . . . . . . . . . 17 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 94 1. Introduction 96 DNS Service Discovery (DNS-SD) [RFC6763] over Multicast DNS (mDNS) 97 [RFC6762] enables zero-configuration service discovery in local 98 networks. It is very convenient for users, but it requires the 99 public exposure of the offering and requesting identities along with 100 information about the offered and requested services. Parts of the 101 published information can seriously breach the user's privacy. These 102 privacy issues and potential solutions are discussed in [KW14a], 103 [KW14b] and [K17]. While the multicast nature of mDNS makes these 104 risks obvious, most risks derive from the observability of 105 transactions. These risks also need to be mitigated when using 106 server-based variants of DNS-SD. 108 There are cases when nodes connected to a network want to provide or 109 consume services without exposing their identities to the other 110 parties connected to the same network. Consider, for example, a 111 traveler wanting to upload pictures from a phone to a laptop when 112 both are connected to the Wi-Fi network of an Internet cafe, or two 113 travelers who want to share files between their laptops when waiting 114 for their plane in an airport lounge. 116 We expect that these exchanges will start with a discovery procedure 117 using DNS-SD over mDNS. One of the devices will publish the 118 availability of a service, such as a picture library or a file store 119 in our examples. The user of the other device will discover this 120 service, and then connect to it. 122 When analyzing these scenarios in Section 3.1, we find that the DNS- 123 SD messages leak identifying information such as the service instance 124 name, the host name, or service properties. We use the following 125 definitions: 127 Identity In this document, the term "identity" refers to the 128 identity of the entity (legal person) operating a device. 130 Disclosing an Identity In this document "disclosing an identity" 131 means showing the identity of operating entities to devices 132 external to the discovery process; e.g., devices on the same 133 network link that are listening to the network traffic but are not 134 actually involved in the discovery process. This document focuses 135 on identity disclosure by data conveyed via messages on the 136 service discovery protocol layer. Still, identity leaks on deeper 137 layers, e.g., the IP layer, are mentioned. 139 Disclosing Information In this document "disclosing information" is 140 also focused on disclosure of data conveyed via messages on the 141 service discovery protocol layer, such as generic non-identity but 142 still potentially sensitive data. 144 2. Threat Model 146 This document considers the following attacker types sorted by 147 increasing power. All these attackers can either be passive (they 148 just listen to network traffic they have access to) or active (they 149 additionally can craft and send malicious packets). 151 external An external attacker is not on the same network link as 152 victim devices engaging in service discovery; thus, the external 153 attacker is in a different multicast domain. 155 on-link An on-link attacker is on the same network link as victim 156 devices engaging in service discovery; thus, the on-link attacker 157 is in the same multicast domain. This attacker can also mount all 158 attacks an external attacker can mount. 160 MITM A Man in the Middle (MITM) attacker either controls (parts of) 161 a network link or can trick two parties to send traffic via the 162 attacker; thus, the MITM attacker has access to unicast traffic 163 between devices engaging in service discovery. This attacker can 164 also mount all attacks an on-link attacker can mount. 166 3. Threat Analysis 168 In this section we analyse how the attackers described in the 169 previous section might threaten the privacy of entities operating 170 devices engaging in service discovery. We focus on attacks 171 leveraging data transmitted in service discovery protocol messages. 173 3.1. Service Discovery Scenarios 175 In this section, we review common service discovery scenarios and 176 discuss privacy threats and their privacy requirements. In all three 177 of these common scenarios the attacker is of the type passive on- 178 link. 180 3.1.1. Private Client and Public Server 182 Perhaps the simplest private discovery scenario involves a single 183 client connecting to a public server through a public network. A 184 common example would be a traveler using a publicly available printer 185 in a business center, in an hotel, or at an airport. 187 ( Taking notes: 188 ( David is printing 189 ( a document 190 ~~~~~~~~~~~ 191 o 192 ___ o ___ 193 / \ _|___|_ 194 | | client server |* *| 195 \_/ __ \_/ 196 | / / Discovery +----------+ | 197 /|\ /_/ <-----------> | +----+ | /|\ 198 / | \__/ +--| |--+ / | \ 199 / | |____/ / | \ 200 / | / | \ 201 / \ / \ 202 / \ / \ 203 / \ / \ 204 / \ / \ 205 / \ / \ 207 David adversary 209 In that scenario, the server is public and wants to be discovered, 210 but the client is private. The adversary will be listening to the 211 network traffic, trying to identify the visitors' devices and their 212 activity. Identifying devices leads to identifying people, either 213 for surveillance of these individuals in the physical world or as a 214 preliminary step for a targeted cyber attack. 216 The requirement in that scenario is that the discovery activity 217 should not disclose the identity of the client. 219 3.1.2. Private Client and Private Server 221 The second private discovery scenario involves a private client 222 connecting to a private server. A common example would be two people 223 engaging in a collaborative application in a public place, such as an 224 airport's lounge. 226 ( Taking notes: 227 ( David is meeting 228 ( with Stuart 229 ~~~~~~~~~~~ 230 o 231 ___ ___ o ___ 232 / \ / \ _|___|_ 233 | | server client | | |* *| 234 \_/ __ __ \_/ \_/ 235 | / / Discovery \ \ | | 236 /|\ /_/ <-----------> \_\ /|\ /|\ 237 / | \__/ \__/ | \ / | \ 238 / | | \ / | \ 239 / | | \ / | \ 240 / \ / \ / \ 241 / \ / \ / \ 242 / \ / \ / \ 243 / \ / \ / \ 244 / \ / \ / \ 246 David Stuart Adversary 248 In that scenario, the collaborative application on one of the devices 249 will act as a server, and the application on the other device will 250 act as a client. The server wants to be discovered by the client, 251 but has no desire to be discovered by anyone else. The adversary 252 will be listening to network traffic, attempting to discover the 253 identity of devices as in the first scenario, and also attempting to 254 discover the patterns of traffic, as these patterns reveal the 255 business and social interactions between the owners of the devices. 257 The requirement in that scenario is that the discovery activity 258 should not disclose the identity of either the client or the server, 259 nor reveal the business and social interactions between the owners of 260 the devices. 262 3.1.3. Wearable Client and Server 264 The third private discovery scenario involves wearable devices. A 265 typical example would be the watch on someone's wrist connecting to 266 the phone in their pocket. 268 ( Taking notes: 269 ( David is here. His watch is 270 ( talking to his phone 271 ~~~~~~~~~~~ 272 o 273 ___ o ___ 274 / \ _|___|_ 275 | | client |* *| 276 \_/ \_/ 277 | _/ | 278 /|\ // /|\ 279 / | \__/ ^ / | \ 280 / |__ | Discovery / | \ 281 / |\ \ v / | \ 282 / \\_\ / \ 283 / \ server / \ 284 / \ / \ 285 / \ / \ 286 / \ / \ 288 David Adversary 290 This third scenario is in many ways similar to the second scenario. 291 It involves two devices, one acting as server and the other acting as 292 client, and it leads to the same requirement of the discovery traffic 293 not disclosing the identity of either the client or the server. The 294 main difference is that the devices are managed by a single owner, 295 which can lead to different methods for establishing secure relations 296 between the devices. There is also an added emphasis on hiding the 297 type of devices that the person wears. 299 In addition to tracking the identity of the owner of the devices, the 300 adversary is interested in the characteristics of the devices, such 301 as type, brand, and model. Identifying the type of device can lead 302 to further attacks, from theft to device-specific hacking. The 303 combination of devices worn by the same person will also provide a 304 "fingerprint" of the person, risking identification. 306 This scenario also represents the general case of bringing private 307 IoT devices into public places. A wearable IoT device might act as a 308 DNS-SD/mDNS client which allows attackers to infer information about 309 devices' owners. While the attacker might be a person as in the 310 example figure, this could also be abused for large scale data 311 collection installing stationary IoT-device-tracking servers in 312 frequented public places. 314 The issues described in Section 3.1.1 such as identifying people or 315 using the information for targeted attacks apply here too. 317 3.2. DNS-SD Privacy Considerations 319 While the discovery process illustrated in the scenarios in 320 Section 3.1 most likely would be based on [RFC6762] as a means for 321 making service information available, this document considers all 322 kinds of means for making DNS-SD resource records available. These 323 means comprise but are not limited to mDNS [RFC6762], DNS servers 324 ([RFC1033] [RFC1034], [RFC1035]), using SRP [I-D.ietf-dnssd-srp], and 325 multi-link [RFC7558] networks. 327 The discovery scenarios in Section 3.1 illustrate three separate 328 abstract privacy requirements that vary based on the use case. These 329 are not limited to mDNS. 331 1. Client identity privacy: Client identities are not leaked during 332 service discovery or use. 334 2. Multi-entity, mutual client and server identity privacy: Neither 335 client nor server identities are leaked during service discovery 336 or use. 338 3. Single-entity, mutual client and server identity privacy: 339 Identities of clients and servers owned and managed by the same 340 legal person are not leaked during service discovery or use. 342 In this section, we describe aspects of DNS-SD that make these 343 requirements difficult to achieve in practice. While it is intended 344 to be thorough, it is not possible to be exhaustive. 346 Client identity privacy, if not addressed properly, can be thwarted 347 by a passive attacker (see Section 2). The type of passive attacker 348 necessary depends on the means of making service information 349 available. Information conveyed via multicast messages can be 350 obtained by an on-link attacker. Unicast messages are easy to access 351 if the transmission is not encrypted, but could still be accessed by 352 an attacker with access to network routers or bridges. Using multi- 353 link service discovery solutions [RFC7558], external attackers have 354 to be taken into consideration as well, e.g., when relaying multicast 355 messages to other links. 357 Server identity privacy can be thwarted by a passive attacker in the 358 same way as client identity privacy. Additionally, active attackers 359 querying for information have to be taken into consideration as well. 360 This is mainly relevant for unicast-based discovery, where listening 361 to discovery traffic requires a MITM attacker; however, an external 362 active attacker might be able to learn the server identity by just 363 querying for service information, e.g. via DNS. 365 3.2.1. Information made available via DNS-SD Resource Records 367 DNS-Based Service Discovery (DNS-SD) is defined in [RFC6763]. It 368 allows nodes to publish the availability of an instance of a service 369 by inserting specific records in the DNS ([RFC1033], [RFC1034], 370 [RFC1035]) or by publishing these records locally using multicast DNS 371 (mDNS) [RFC6762]. Available services are described using three types 372 of records: 374 PTR Record: Associates a service type in the domain with an 375 "instance" name of this service type. 377 SRV Record: Provides the node name, port number, priority and weight 378 associated with the service instance, in conformance with 379 [RFC2782]. 381 TXT Record: Provides a set of attribute-value pairs describing 382 specific properties of the service instance. 384 3.2.2. Privacy Implication of Publishing Service Instance Names 386 In the first phase of discovery, clients obtain all PTR records 387 associated with a service type in a given naming domain. Each PTR 388 record contains a Service Instance Name defined in Section 4 of 389 [RFC6763]: 391 Service Instance Name = . . 393 The portion of the Service Instance Name is meant to 394 convey enough information for users of discovery clients to easily 395 select the desired service instance. Nodes that use DNS-SD over mDNS 396 [RFC6762] in a mobile environment will rely on the specificity of the 397 instance name to identify the desired service instance. In our 398 example of users wanting to upload pictures to a laptop in an 399 Internet Cafe, the list of available service instances may look like: 401 Alice's Images . _imageStore._tcp . local 402 Alice's Mobile Phone . _presence._tcp . local 403 Alice's Notebook . _presence._tcp . local 404 Bob's Notebook . _presence._tcp . local 405 Carol's Notebook . _presence._tcp . local 407 Alice will see the list on her phone and understand intuitively that 408 she should pick the first item. The discovery will "just work". 409 (Note that our examples of service names conform to the specification 410 in section 4.1 of [RFC6763], but may require some character escaping 411 when entered in conventional DNS software.) 412 However, DNS-SD/mDNS will reveal to anybody that Alice is currently 413 visiting the Internet Cafe. It further discloses the fact that she 414 uses two devices, shares an image store, and uses a chat application 415 supporting the _presence protocol on both of her devices. She might 416 currently chat with Bob or Carol, as they are also using a _presence 417 supporting chat application. This information is not just available 418 to devices actively browsing for and offering services, but to 419 anybody passively listening to the network traffic, i.e. a passive 420 on-link attacker. 422 There is, of course, also no authentication requirement to claim a 423 particular instance name, so an active attacker can provide resources 424 that claim to be Alice's but are not. 426 3.2.3. Privacy Implication of Publishing Node Names 428 The SRV records contain the DNS name of the node publishing the 429 service. Typical implementations construct this DNS name by 430 concatenating the "host name" of the node with the name of the local 431 domain. The privacy implications of this practice are reviewed in 432 [RFC8117]. Depending on naming practices, the host name is either a 433 strong identifier of the device, or at a minimum a partial 434 identifier. It enables tracking of both the device, and, by 435 extension, the device's owner. 437 3.2.4. Privacy Implication of Publishing Service Attributes 439 The TXT record's attribute-value pairs contain information on the 440 characteristics of the corresponding service instance. This in turn 441 reveals information about the devices that publish services. The 442 amount of information varies widely with the particular service and 443 its implementation: 445 o Some attributes, such as the paper size available in a printer, 446 are the same on many devices, and thus only provide limited 447 information to a tracker. 449 o Attributes that have freeform values, such as the name of a 450 directory, may reveal much more information. 452 Combinations of individual attributes have more information power 453 than specific attributes, and can potentially be used for 454 "fingerprinting" a specific device. 456 Information contained in TXT records not only breaches privacy by 457 making devices trackable, but might directly contain private 458 information about the user. For instance the _presence service 459 reveals the "chat status" to everyone in the same network. Users 460 might not be aware of that. 462 Further, TXT records often contain version information about 463 services, allowing potential attackers to identify devices running 464 exploit-prone versions of a certain service. 466 3.2.5. Device Fingerprinting 468 The combination of information published in DNS-SD has the potential 469 to provide a "fingerprint" of a specific device. Such information 470 includes: 472 o List of services published by the device, which can be retrieved 473 because the SRV records will point to the same host name. 475 o Specific attributes describing these services. 477 o Port numbers used by the services. 479 o Priority and weight attributes in the SRV records. 481 This combination of services and attributes will often be sufficient 482 to identify the version of the software running on a device. If a 483 device publishes many services with rich sets of attributes, the 484 combination may be sufficient to identify the specific device and 485 track its owner. 487 An argument is sometimes made that devices providing services can be 488 identified by observing the local traffic, and that trying to hide 489 the presence of the service is futile. However, there are good 490 reasons for the discovery service layer to avoid unnecessary 491 exposure: 493 1. Providing privacy at the discovery layer is of the essence for 494 enabling automatically configured privacy-preserving network 495 applications. Application layer protocols are not forced to 496 leverage the offered privacy, but if device tracking is not 497 prevented at the deeper layers, including the service discovery 498 layer, obfuscating a certain service's protocol at the 499 application layer is futile. 501 2. Further, in the case of mDNS based discovery, even if the 502 application layer does not protect privacy, typically services 503 are provided via unicast which requires a MITM attacker, while 504 identifying services based on multicast discovery messages just 505 requires an on-link attacker. 507 The same argument can be extended to say that the pattern of services 508 offered by a device allows for fingerprinting the device. This may 509 or may not be true, since we can expect that services will be 510 designed or updated to avoid leaking fingerprints. In any case, the 511 design of the discovery service should avoid making a bad situation 512 worse, and should as much as possible avoid providing new 513 fingerprinting information. 515 3.2.6. Privacy Implication of Discovering Services 517 The consumers of services engage in discovery, and in doing so reveal 518 some information such as the list of services they are interested in 519 and the domains in which they are looking for the services. When the 520 clients select specific instances of services, they reveal their 521 preference for these instances. This can be benign if the service 522 type is very common, but it could be more problematic for sensitive 523 services, such as some private messaging services. 525 One way to protect clients would be to somehow encrypt the requested 526 service types. Of course, just as we noted in Section 3.2.5, traffic 527 analysis can often reveal the service. 529 3.3. Security Considerations 531 For each of the operations described above, we must also consider 532 security threats we are concerned about. 534 3.3.1. Authenticity, Integrity & Freshness 536 Can devices (both servers and clients) trust the information they 537 receive? Has it been modified in flight by an adversary? Can 538 devices trust the source of the information? Is the source of 539 information fresh, i.e., not replayed? Freshness may or may not be 540 required depending on whether the discovery process is meant to be 541 online. In some cases, publishing discovery information to a shared 542 directory or registry, rather than to each online recipient through a 543 broadcast channel, may suffice. 545 3.3.2. Confidentiality 547 Confidentiality is about restricting information access to only 548 authorized individuals. Ideally this should only be the appropriate 549 trusted parties, though it can be challenging to define who are "the 550 appropriate trusted parties." In some use cases, this may mean that 551 only mutually authenticated and trusting clients and servers can read 552 messages sent for one another. The process of service discovery in 553 particular is often used to discover new entities that the device did 554 not previously know about. It may be tricky to work out how a device 555 can have an established trust relationship with a new entity it has 556 never previously communicated with. 558 3.3.3. Resistance to Dictionary Attacks 560 It can be tempting to use (publicly computable) hash functions to 561 obscure sensitive identifiers. This transforms a sensitive unique 562 identifier such as an email address into a "scrambled" but still 563 unique identifier. Unfortunately simple solutions may be vulnerable 564 to offline dictionary attacks. 566 3.3.4. Resistance to Denial-of-Service Attacks 568 In any protocol where the receiver of messages has to perform 569 cryptographic operations on those messages, there is a risk of a 570 brute-force flooding attack causing the receiver to expend excessive 571 amounts of CPU time and, where appliciable, battery power just 572 processing and discarding those messages. 574 Also, amplification attacks have to be taken into consideration. 575 Messages with larger payloads should only be sent as an answer to a 576 query sent by a verified client. 578 3.3.5. Resistance to Sender Impersonation 580 Sender impersonation is an attack wherein messages such as service 581 offers are forged by entities who do not possess the corresponding 582 secret key material. These attacks may be used to learn the identity 583 of a communicating party, actively or passively. 585 3.3.6. Sender Deniability 587 Deniability of sender activity, e.g., of broadcasting a discovery 588 request, may be desirable or necessary in some use cases. This 589 property ensures that eavesdroppers cannot prove senders issued a 590 specific message destined for one or more peers. 592 3.4. Operational Considerations 594 3.4.1. Power Management 596 Many modern devices, especially battery-powered devices, use power 597 management techniques to conserve energy. One such technique is for 598 a device to transfer information about itself to a proxy, which will 599 act on behalf of the device for some functions, while the device 600 itself goes to sleep to reduce power consumption. When the proxy 601 determines that some action is required which only the device itself 602 can perform, the proxy may have some way to wake the device, as 603 described for example in [SLEEP-PROXY]. 605 In many cases, the device may not trust the network proxy 606 sufficiently to share all its confidential key material with the 607 proxy. This poses challenges for combining private discovery that 608 relies on per-query cryptographic operations, with energy-saving 609 techniques that rely on having (somewhat untrusted) network proxies 610 answer queries on behalf of sleeping devices. 612 3.4.2. Protocol Efficiency 614 Creating a discovery protocol that has the desired security 615 properties may result in a design that is not efficient. To perform 616 the necessary operations the protocol may need to send and receive a 617 large number of network packets, or require an inordinate amount of 618 multicast transmissions. This may consume an unreasonable amount of 619 network capacity, particularly problematic when it is a shared 620 wireless spectrum. Further, it may cause an unnecessary level of 621 power consumption which is particularly problematic on battery 622 devices, and may result in the discovery process being slow. 624 It is a difficult challenge to design a discovery protocol that has 625 the property of obscuring the details of what it is doing from 626 unauthorized observers, while also managing to perform efficiently. 628 3.4.3. Secure Initialization and Trust Models 630 One of the challenges implicit in the preceding discussions is that 631 whenever we discuss "trusted entities" versus "untrusted entities", 632 there needs to be some way that trust is initially established, to 633 convert an "untrusted entity" into a "trusted entity". 635 The purpose of this document is not to define the specific way in 636 which trust can be established. Protocol designers may rely on a 637 number of existing technologies, including PKI, Trust On First Use 638 (TOFU), or using a short passphrase or PIN with cryptographic 639 algorithms such as Secure Remote Password (SRP) [RFC5054] or a 640 Password Authenticated Key Exchange like J-PAKE [RFC8236] using a 641 Schnorr Non-interactive Zero-Knowledge Proof [RFC8235]. 643 Protocol designers should consider a specific usability pitfall when 644 trust is established immediately prior to performing discovery. 645 Users will have a tendency to "click OK" in order to achieve their 646 task. This implicit vulnerability is avoided if the trust 647 establishment requires more significant participation of the user, 648 such as entering a password or PIN. 650 3.4.4. External Dependencies 652 Trust establishment may depend on external parties. Optionally, this 653 might involve synchronous communication. Systems which have such a 654 dependency may be attacked by interfering with communication to 655 external dependencies. Where possible, such dependencies should be 656 minimized. Local trust models are best for secure initialization in 657 the presence of active attackers. 659 4. Requirements for a DNS-SD Privacy Extension 661 Given the considerations discussed in the previous sections, we state 662 requirements for privacy preserving DNS-SD in the following 663 subsections. 665 Defining a solution according to these requirements is intended to 666 lead to a solution that does not transmit privacy-violating DNS-SD 667 messages and further does not open pathways to new attacks against 668 the operation of DNS-SD. 670 However, while this document gives advice on which privacy protecting 671 mechanisms should be used on deeper-layer network protocols and on 672 how to actually connect to services in a privacy-preserving way, 673 stating corresponding requirements is out of the scope of this 674 document. To mitigate attacks against privacy on lower layers, both 675 servers and clients must use privacy options available at lower 676 layers, and for example avoid publishing static IPv4 or IPv6 677 addresses, or static IEEE 802 MAC addresses. For services advertised 678 on a single network link, link local IP addresses should be used; see 679 [RFC3927] and [RFC4291] for IPv4 and IPv6, respectively. Static 680 servers advertising services globally via DNS can hide their IP 681 addresses from unauthorized clients using the split mode topology 682 shown in [I-D.ietf-tls-esni]. Hiding static MAC addresses can be 683 achieved via MAC address randomization (see [RFC7844]). 685 4.1. Private Client Requirements 687 For all three scenarios described in Section 3.1, client privacy 688 requires DNS-SD messages to: 690 1. Avoid disclosure of the client's identity, either directly or via 691 inference, to nodes other than select servers. 693 2. Avoid exposure of linkable identifiers that allow tracing client 694 devices. 696 3. Avoid disclosure of the client's interest in specific service 697 instances or service types to nodes other than select servers. 699 When listing and resolving services via current DNS-SD deployments, 700 clients typically disclose their interest in specific services types 701 and specific instances of these types, respectively. 703 In addition to the exposure and disclosure risks noted above, 704 protocols and implementations will have to consider fingerprinting 705 attacks (see Section 3.2.5) that could retrieve similar information. 707 4.2. Private Server Requirements 709 Servers like the "printer" discussed in scenario 1 are public, but 710 the servers discussed in scenarios 2 and 3 are by essence private. 711 Server privacy requires DNS-SD messages to: 713 1. Avoid disclosure of the server's identity, either directly or via 714 inference, to nodes other than authorized clients. In 715 particular, Servers must avoid publishing static identifiers such 716 as host names or service names. When those fields are required 717 by the protocol, servers should publish randomized values. (See 718 [RFC8117] for a discussion of host names.) 720 2. Avoid exposure of linkable identifiers that allow tracing 721 servers. 723 3. Avoid disclosure to unauthorized clients of service instance 724 names or service types of offered services. 726 4. Avoid disclosure to unauthorized clients of information about the 727 services they offer. 729 5. Avoid disclosure of static IPv4 or IPv6 addresses. 731 When offering services via current DNS-SD deployments, servers 732 typically disclose their hostnames (SRV, A/AAAA), instance names of 733 offered services (PRT, SRV), and information about services (TXT). 734 Heeding these requirements protects a server's privacy on the DNS-SD 735 level. 737 The current DNS-SD user interfaces present the list of discovered 738 service names to the users, and let them pick a service from the 739 list. Using random identifiers for service names renders that UI 740 flow unusable. Privacy-respecting discovery protocols will have to 741 solve this issue, for example by presenting authenticated or 742 decrypted service names instead of the randomized values. 744 4.3. Security and Operation 746 In order to be secure and feasible, a DNS-SD privacy extension needs 747 to consider security and operational requirements including: 749 1. Avoiding significant CPU overhead on nodes or significantly 750 higher network load. Such overhead or load would make nodes 751 vulnerable to denial of service attacks. Further, it would 752 increase power consumption which is damaging for IoT devices. 754 2. Avoiding designs in which a small message can trigger a large 755 amount of traffic towards an unverified address, as this could be 756 exploited in amplification attacks. 758 5. IANA Considerations 760 This draft does not require any IANA action. 762 6. Acknowledgments 764 This draft incorporates many contributions from Stuart Cheshire and 765 Chris Wood. Thanks to Florian Adamsky for extensive review and 766 suggestions on the organization of the threat model. Thanks to Barry 767 Leiba for an extensive review. Thanks to Roman Danyliw, Ben Kaduk, 768 Adam Roach and Alissa Cooper for their comments during IESG review. 770 7. References 772 7.1. Normative References 774 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 775 DOI 10.17487/RFC6762, February 2013, 776 . 778 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 779 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 780 . 782 7.2. Informative References 784 [I-D.ietf-dnssd-srp] 785 Cheshire, S. and T. Lemon, "Service Registration Protocol 786 for DNS-Based Service Discovery", draft-ietf-dnssd-srp-02 787 (work in progress), July 2019. 789 [I-D.ietf-tls-esni] 790 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 791 "Encrypted Server Name Indication for TLS 1.3", draft- 792 ietf-tls-esni-05 (work in progress), November 2019. 794 [K17] Kaiser, D., "Efficient Privacy-Preserving 795 Configurationless Service Discovery Supporting Multi-Link 796 Networks", 2017, 797 . 799 [KW14a] Kaiser, D. and M. Waldvogel, "Adding Privacy to Multicast 800 DNS Service Discovery", DOI 10.1109/TrustCom.2014.107, 801 2014, . 804 [KW14b] Kaiser, D. and M. Waldvogel, "Efficient Privacy Preserving 805 Multicast DNS Service Discovery", 806 DOI 10.1109/HPCC.2014.141, 2014, 807 . 810 [RFC1033] Lottor, M., "Domain Administrators Operations Guide", 811 RFC 1033, DOI 10.17487/RFC1033, November 1987, 812 . 814 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 815 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 816 . 818 [RFC1035] Mockapetris, P., "Domain names - implementation and 819 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 820 November 1987, . 822 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 823 specifying the location of services (DNS SRV)", RFC 2782, 824 DOI 10.17487/RFC2782, February 2000, 825 . 827 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 828 Configuration of IPv4 Link-Local Addresses", RFC 3927, 829 DOI 10.17487/RFC3927, May 2005, 830 . 832 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 833 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 834 2006, . 836 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 837 "Using the Secure Remote Password (SRP) Protocol for TLS 838 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 839 2007, . 841 [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 842 "Requirements for Scalable DNS-Based Service Discovery 843 (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, 844 DOI 10.17487/RFC7558, July 2015, 845 . 847 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 848 Profiles for DHCP Clients", RFC 7844, 849 DOI 10.17487/RFC7844, May 2016, 850 . 852 [RFC8117] Huitema, C., Thaler, D., and R. Winter, "Current Hostname 853 Practice Considered Harmful", RFC 8117, 854 DOI 10.17487/RFC8117, March 2017, 855 . 857 [RFC8235] Hao, F., Ed., "Schnorr Non-interactive Zero-Knowledge 858 Proof", RFC 8235, DOI 10.17487/RFC8235, September 2017, 859 . 861 [RFC8236] Hao, F., Ed., "J-PAKE: Password-Authenticated Key Exchange 862 by Juggling", RFC 8236, DOI 10.17487/RFC8236, September 863 2017, . 865 [SLEEP-PROXY] 866 Cheshire, S., "Understanding Sleep Proxy Service", 2009, 867 . 869 Authors' Addresses 871 Christian Huitema 872 Private Octopus Inc. 873 Friday Harbor, WA 98250 874 U.S.A. 876 Email: huitema@huitema.net 877 URI: http://privateoctopus.com/ 878 Daniel Kaiser 879 University of Luxembourg 880 6, avenue de la Fonte 881 Esch-sur-Alzette 4364 882 Luxembourg 884 Email: daniel.kaiser@uni.lu 885 URI: https://secan-lab.uni.lu/