idnits 2.17.1 draft-ietf-dnssd-prireq-05.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 (February 21, 2020) is 1526 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: August 24, 2020 University of Luxembourg 6 February 21, 2020 8 DNS-SD Privacy and Security Requirements 9 draft-ietf-dnssd-prireq-05 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 August 24, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . 16 87 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 88 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 89 7. Informative References . . . . . . . . . . . . . . . . . . . 17 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 92 1. Introduction 94 DNS Service Discovery (DNS-SD) [RFC6763] over Multicast DNS (mDNS) 95 [RFC6762] enables zero-configuration service discovery in local 96 networks. It is very convenient for users, but it requires the 97 public exposure of the offering and requesting identities along with 98 information about the offered and requested services. Parts of the 99 published information can seriously breach the user's privacy. These 100 privacy issues and potential solutions are discussed in [KW14a], 101 [KW14b] and [K17]. While the multicast nature of mDNS makes these 102 risks obvious, most risks derive from the observability of 103 transactions. These risks also need to be mitigated when using 104 server-based variants of DNS-SD. 106 There are cases when nodes connected to a network want to provide or 107 consume services without exposing their identity to the other parties 108 connected to the same network. Consider for example a traveler 109 wanting to upload pictures from a phone to a laptop when connected to 110 the Wi-Fi network of an Internet cafe, or two travelers who want to 111 share files between their laptops when waiting for their plane in an 112 airport lounge. 114 We expect that these exchanges will start with a discovery procedure 115 using DNS-SD over mDNS. One of the devices will publish the 116 availability of a service, such as a picture library or a file store 117 in our examples. The user of the other device will discover this 118 service, and then connect to it. 120 When analyzing these scenarios in Section 3.1, we find that the DNS- 121 SD messages leak identifying information such as the service instance 122 name, the host name, or service properties. 124 Identity In this document, the term "identity" refers to the 125 identity of the entity (legal person) operating a device. 127 Disclosing an Identity In this document "disclosing an identity" 128 means showing the identity of operating entities to devices 129 external to the discovery process; e.g., devices on the same 130 network link that are listening to the network traffic but are not 131 actually involved in the discovery process. This document focuses 132 on identity disclosure by data conveyed via messages on the 133 service discovery protocol layer. Still, identity leaks on deeper 134 layers, e.g., the IP layer, are mentioned. 136 Disclosing Information In this document "disclosing information" is 137 also focused on disclosure by data conveyed via messages on the 138 service discovery protocol layer. 140 2. Threat Model 142 This document considers the following attacker types sorted by 143 increasing power. All these attackers can either be passive, i.e. 145 they just listen to network traffic they have access to, or active, 146 i.e. they additionally can craft and send (malicious) packets. 148 external An external attacker is not on the same network link as 149 victim devices engaging in service discovery; thus, the external 150 attacker is in a different multicast domain. 152 on-link An on-link attacker is on the same network link as victim 153 devices engaging in service discovery; thus, the external attacker 154 is in the same multicast domain. This attacker can also mount all 155 attacks an external attacker can mount. 157 MITM A Man in the Middle (MITM) attacker either controls (parts of) 158 a network link or can trick two parties to send traffic via him; 159 thus, the MITM attacker has access to unicast traffic between 160 devices engaging in service discovery. This attacker can also 161 mount all attacks an on-link attacker can mount. 163 3. Threat Analysis 165 In this section we analyse how the attackers described in the 166 previous section might threaten the privacy of entities operating 167 devices engaging in service discovery. We focus on attacks 168 leveraging data transmitted in service discovery protocol messages. 170 3.1. Service Discovery Scenarios 172 In this section, we review common service discovery scenarios and 173 discuss privacy threats and their privacy requirements. In all three 174 of these common scenarios the attacker is of the type passive on- 175 link. 177 3.1.1. Private Client and Public Server 179 Perhaps the simplest private discovery scenario involves a single 180 client connecting to a public server through a public network. A 181 common example would be a traveler using a publicly available printer 182 in a business center, in an hotel, or at an airport. 184 ( Taking notes: 185 ( David is printing 186 ( a document 187 ~~~~~~~~~~~ 188 o 189 ___ o ___ 190 / \ _|___|_ 191 | | client server |* *| 192 \_/ __ \_/ 193 | / / Discovery +----------+ | 194 /|\ /_/ <-----------> | +----+ | /|\ 195 / | \__/ +--| |--+ / | \ 196 / | |____/ / | \ 197 / | / | \ 198 / \ / \ 199 / \ / \ 200 / \ / \ 201 / \ / \ 202 / \ / \ 204 David adversary 206 In that scenario, the server is public and wants to be discovered, 207 but the client is private. The adversary will be listening to the 208 network traffic, trying to identify the visitors' devices and their 209 activity. Identifying devices leads to identifying people, either 210 just for tracking people or as a preliminary to targeted attacks. 212 The requirement in that scenario is that the discovery activity 213 should not disclose the identity of the client. 215 3.1.2. Private Client and Private Server 217 The second private discovery scenario involves a private client 218 connecting to a private server. A common example would be two people 219 engaging in a collaborative application in a public place, such as 220 for example an airport's lounge. 222 ( Taking notes: 223 ( David is meeting 224 ( with Stuart 225 ~~~~~~~~~~~ 226 o 227 ___ ___ o ___ 228 / \ / \ _|___|_ 229 | | server client | | |* *| 230 \_/ __ __ \_/ \_/ 231 | / / Discovery \ \ | | 232 /|\ /_/ <-----------> \_\ /|\ /|\ 233 / | \__/ \__/ | \ / | \ 234 / | | \ / | \ 235 / | | \ / | \ 236 / \ / \ / \ 237 / \ / \ / \ 238 / \ / \ / \ 239 / \ / \ / \ 240 / \ / \ / \ 242 David Stuart Adversary 244 In that scenario, the collaborative application on one of the devices 245 will act as a server, and the application on the other device will 246 act as a client. The server wants to be discovered by the client, 247 but has no desire to be discovered by anyone else. The adversary 248 will be listening to network traffic, attempting to discover the 249 identity of devices as in the first scenario, and also attempting to 250 discover the patterns of traffic, as these patterns reveal the 251 business and social interactions between the owners of the devices. 253 The requirement in that scenario is that the discovery activity 254 should not disclose the identity of either the client or the server. 256 3.1.3. Wearable Client and Server 258 The third private discovery scenario involves wearable devices. A 259 typical example would be the watch on someone's wrist connecting to 260 the phone in their pocket. 262 ( Taking notes: 263 ( David is here. His watch is 264 ( talking to his phone 265 ~~~~~~~~~~~ 266 o 267 ___ o ___ 268 / \ _|___|_ 269 | | client |* *| 270 \_/ \_/ 271 | _/ | 272 /|\ // /|\ 273 / | \__/ ^ / | \ 274 / |__ | Discovery / | \ 275 / |\ \ v / | \ 276 / \\_\ / \ 277 / \ server / \ 278 / \ / \ 279 / \ / \ 280 / \ / \ 282 David Adversary 284 This third scenario is in many ways similar to the second scenario. 285 It involves two devices, one acting as server and the other acting as 286 client, and it leads to the same requirement of the discovery traffic 287 not disclosing the identity of either the client or the server. The 288 main difference is that the devices are managed by a single owner, 289 which can lead to different methods for establishing secure relations 290 between the devices. There is also an added emphasis on hiding the 291 type of devices that the person wears. 293 In addition to tracking the identity of the owner of the devices, the 294 adversary is interested in the characteristics of the devices, such 295 as type, brand, and model. Identifying the type of device can lead 296 to further attacks, from theft to device specific hacking. The 297 combination of devices worn by the same person will also provide a 298 "fingerprint" of the person, allowing identification. 300 This scenario also represents the general case of bringing private 301 IoT devices into public places. A wearable IoT device might act as a 302 DNS-SD/mDNS client which allows attackers to infer information about 303 devices' owners. While the attacker might be a person as in the 304 example figure, this could also be abused for large scale data 305 collection installing stationary IoT-device-tracking servers in 306 frequented public places. 308 3.2. DNS-SD Privacy Considerations 310 While the discovery process illustrated in the scenarios in 311 Section 3.1 most likely would be based on [RFC6762] as a means for 312 making service information available, this document considers all 313 kinds of means for making DNS-SD resource records available. These 314 means comprise but are not limited to mDNS [RFC6762], DNS servers 315 ([RFC1033] [RFC1034], [RFC1035]), e.g. using SRP 316 [I-D.ietf-dnssd-srp], and multi-link [RFC7558] networks. 318 The discovery scenarios in Section 3.1 illustrate three separate 319 abstract privacy requirements that vary based on the use case. These 320 are not limited to mDNS. 322 1. Client identity privacy: Client identities are not leaked during 323 service discovery or use. 325 2. Multi-entity, mutual client and server identity privacy: Neither 326 client nor server identities are leaked during service discovery 327 or use. 329 3. Single-entity, mutual client and server identity privacy: 330 Identities of clients and servers owned and managed by the same 331 legal person are not leaked during service discovery or use. 333 In this section, we describe aspects of DNS-SD that make these 334 requirements difficult to achieve in practice. While it is intended 335 to be thorough, it is not possible to be exhaustive. 337 Client identity privacy, if not addressed properly, can be thwarted 338 by a passive attacker (see Section 2). The type of passive attacker 339 necessary depends on the means of making service information 340 available. Information conveyed via multicast messages can be 341 obtained by an on-link attacker, while unicast messages are only 342 available to MITM attackers. Using multi-link service discovery 343 solutions [RFC7558], external attackers have to be taken into 344 consideration as well, e.g., when relaying multicast messages to 345 other links. 347 Server identity privacy can be thwarted by a passive attacker in the 348 same way as client identity privacy. Additionally, active attackers 349 querying for information have to be taken into consideration as well. 350 This is mainly relevant for unicast based discovery, where listening 351 to discovery traffic requires a MITM attacker; however, an external 352 active attacker might be able to learn the server identity by just 353 querying for service information, e.g. via DNS. 355 3.2.1. Information made available via DNS-SD Resource Records 357 DNS-Based Service Discovery (DNS-SD) is defined in [RFC6763]. It 358 allows nodes to publish the availability of an instance of a service 359 by inserting specific records in the DNS ([RFC1033], [RFC1034], 360 [RFC1035]) or by publishing these records locally using multicast DNS 361 (mDNS) [RFC6762]. Available services are described using three types 362 of records: 364 PTR Record: Associates a service type in the domain with an 365 "instance" name of this service type. 367 SRV Record: Provides the node name, port number, priority and weight 368 associated with the service instance, in conformance with 369 [RFC2782]. 371 TXT Record: Provides a set of attribute-value pairs describing 372 specific properties of the service instance. 374 3.2.2. Privacy Implication of Publishing Service Instance Names 376 In the first phase of discovery, clients obtain all PTR records 377 associated with a service type in a given naming domain. Each PTR 378 record contains a Service Instance Name defined in Section 4 of 379 [RFC6763]: 381 Service Instance Name = . . 383 The portion of the Service Instance Name is meant to 384 convey enough information for users of discovery clients to easily 385 select the desired service instance. Nodes that use DNS-SD over mDNS 386 [RFC6762] in a mobile environment will rely on the specificity of the 387 instance name to identify the desired service instance. In our 388 example of users wanting to upload pictures to a laptop in an 389 Internet Cafe, the list of available service instances may look like: 391 Alice's Images . _imageStore._tcp . local 392 Alice's Mobile Phone . _presence._tcp . local 393 Alice's Notebook . _presence._tcp . local 394 Bob's Notebook . _presence._tcp . local 395 Carol's Notebook . _presence._tcp . local 397 Alice will see the list on her phone and understand intuitively that 398 she should pick the first item. The discovery will "just work". 399 (Note that our examples of service names conform to the specification 400 in section 4.1 of [RFC6763], but may require some character escaping 401 when entered in conventional DNS software.) 402 However, DNS-SD/mDNS will reveal to anybody that Alice is currently 403 visiting the Internet Cafe. It further discloses the fact that she 404 uses two devices, shares an image store, and uses a chat application 405 supporting the _presence protocol on both of her devices. She might 406 currently chat with Bob or Carol, as they are also using a _presence 407 supporting chat application. This information is not just available 408 to devices actively browsing for and offering services, but to 409 anybody passively listening to the network traffic, i.e. a passive 410 on-link attacker. 412 3.2.3. Privacy Implication of Publishing Node Names 414 The SRV records contain the DNS name of the node publishing the 415 service. Typical implementations construct this DNS name by 416 concatenating the "host name" of the node with the name of the local 417 domain. The privacy implications of this practice are reviewed in 418 [RFC8117]. Depending on naming practices, the host name is either a 419 strong identifier of the device, or at a minimum a partial 420 identifier. It enables tracking of both the device, and, by 421 extension, the device's owner. 423 3.2.4. Privacy Implication of Publishing Service Attributes 425 The TXT record's attribute-value pairs contain information on the 426 characteristics of the corresponding service instance. This in turn 427 reveals information about the devices that publish services. The 428 amount of information varies widely with the particular service and 429 its implementation: 431 o Some attributes like the paper size available in a printer, are 432 the same on many devices, and thus only provide limited 433 information to a tracker. 435 o Attributes that have freeform values, such as the name of a 436 directory, may reveal much more information. 438 Combinations of attributes have more information power than specific 439 attributes, and can potentially be used for "fingerprinting" a 440 specific device. 442 Information contained in TXT records does not only breach privacy by 443 making devices trackable, but might directly contain private 444 information about the user. For instance the _presence service 445 reveals the "chat status" to everyone in the same network. Users 446 might not be aware of that. 448 Further, TXT records often contain version information about services 449 allowing potential attackers to identify devices running exploit- 450 prone versions of a certain service. 452 3.2.5. Device Fingerprinting 454 The combination of information published in DNS-SD has the potential 455 to provide a "fingerprint" of a specific device. Such information 456 includes: 458 o List of services published by the device, which can be retrieved 459 because the SRV records will point to the same host name. 461 o Specific attributes describing these services. 463 o Port numbers used by the services. 465 o Priority and weight attributes in the SRV records. 467 This combination of services and attributes will often be sufficient 468 to identify the version of the software running on a device. If a 469 device publishes many services with rich sets of attributes, the 470 combination may be sufficient to identify the specific device. 472 An argument is sometimes made that devices providing services can be 473 identified by observing the local traffic, and that trying to hide 474 the presence of the service is futile. However, 476 1. Providing privacy at the discovery layer is of the essence for 477 enabling automatically configured privacy-preserving network 478 applications. Application layer protocols are not forced to 479 leverage the offered privacy, but if device tracking is not 480 prevented at the deeper layers, including the service discovery 481 layer, obfuscating a certain service's protocol at the 482 application layer is futile. 484 2. Further, in the case of mDNS based discovery, even if the 485 application layer does not protect privacy, typically services 486 are provided via unicast which requires a MITM attacker, while 487 identifying services based on multicast discovery messages just 488 requires an on-link attacker. 490 The same argument can be extended to say that the pattern of services 491 offered by a device allows for fingerprinting the device. This may 492 or may not be true, since we can expect that services will be 493 designed or updated to avoid leaking fingerprints. In any case, the 494 design of the discovery service should avoid making a bad situation 495 worse, and should as much as possible avoid providing new 496 fingerprinting information. 498 3.2.6. Privacy Implication of Discovering Services 500 The consumers of services engage in discovery, and in doing so reveal 501 some information such as the list of services they are interested in 502 and the domains in which they are looking for the services. When the 503 clients select specific instances of services, they reveal their 504 preference for these instances. This can be benign if the service 505 type is very common, but it could be more problematic for sensitive 506 services, such as for example some private messaging services. 508 One way to protect clients would be to somehow encrypt the requested 509 service types. Of course, just as we noted in Section 3.2.5, traffic 510 analysis can often reveal the service. 512 3.3. Security Considerations 514 For each of the operations described above, we must also consider 515 security threats we are concerned about. 517 3.3.1. Authenticity, Integrity & Freshness 519 Can devices (both servers and clients) trust the information they 520 receive? Has it been modified in flight by an adversary? Can 521 devices trust the source of the information? Is the source of 522 information fresh, i.e., not replayed? Freshness may or may not be 523 required depending on whether the discovery process is meant to be 524 online. In some cases, publishing discovery information to a shared 525 directory or registry, rather than to each online recipient through a 526 broadcast channel, may suffice. 528 3.3.2. Confidentiality 530 Confidentiality is about restricting information access to only 531 authorized individuals. Ideally this should only be the appropriate 532 trusted parties, though it can be challenging to define who are "the 533 appropriate trusted parties." In some use cases, this may mean that 534 only mutually authenticated and trusting clients and servers can read 535 messages sent for one another. The process of service discovery in 536 particular is often used to discover new entities that the device did 537 not previously know about. It may be tricky to work out how a device 538 can have an established trust relationship with a new entity it has 539 never previously communicated with. 541 3.3.3. Resistance to Dictionary Attacks 543 It can be tempting to use (publicly computable) hash functions to 544 obscure sensitive identifiers. This transforms a sensitive unique 545 identifier such as an email address into a "scrambled" but still 546 unique identifier. Unfortunately simple solutions may be vulnerable 547 to offline dictionary attacks. 549 3.3.4. Resistance to Denial-of-Service Attacks 551 In any protocol where the receiver of messages has to perform 552 cryptographic operations on those messages, there is a risk of a 553 brute-force flooding attack causing the receiver to expend excessive 554 amounts of CPU time and, where appliciable, battery power just 555 processing and discarding those messages. 557 Also, amplification attacks have to be taken into consideration. 558 Messages with larger payloads should only be sent as an answer to a 559 query sent by a verified client. 561 3.3.5. Resistance to Sender Impersonation 563 Sender impersonation is an attack wherein messages such as service 564 offers are forged by entities who do not possess the corresponding 565 secret key material. These attacks may be used to learn the identity 566 of a communicating party, actively or passively. 568 3.3.6. Sender Deniability 570 Deniability of sender activity, e.g., of broadcasting a discovery 571 request, may be desirable or necessary in some use cases. This 572 property ensures that eavesdroppers cannot prove senders issued a 573 specific message destined for one or more peers. 575 3.4. Operational Considerations 577 3.4.1. Power Management 579 Many modern devices, especially battery-powered devices, use power 580 management techniques to conserve energy. One such technique is for 581 a device to transfer information about itself to a proxy, which will 582 act on behalf of the device for some functions, while the device 583 itself goes to sleep to reduce power consumption. When the proxy 584 determines that some action is required which only the device itself 585 can perform, the proxy may have some way to wake the device, as 586 implied in RFC6762 [RFC6762] 587 In many cases, the device may not trust the network proxy 588 sufficiently to share all its confidential key material with the 589 proxy. This poses challenges for combining private discovery that 590 relies on per-query cryptographic operations, with energy-saving 591 techniques that rely on having (somewhat untrusted) network proxies 592 answer queries on behalf of sleeping devices. 594 3.4.2. Protocol Efficiency 596 Creating a discovery protocol that has the desired security 597 properties may result in a design that is not efficient. To perform 598 the necessary operations the protocol may need to send and receive a 599 large number of network packets. This may consume an unreasonable 600 amount of network capacity, particularly problematic when it is a 601 shared wireless spectrum. Further it may cause an unnecessary level 602 of power consumption which is particularly problematic on battery 603 devices, and may result in the discovery process being slow. 605 It is a difficult challenge to design a discovery protocol that has 606 the property of obscuring the details of what it is doing from 607 unauthorized observers, while also managing to do that efficiently. 609 3.4.3. Secure Initialization and Trust Models 611 One of the challenges implicit in the preceding discussions is that 612 whenever we discuss "trusted entities" versus "untrusted entities", 613 there needs to be some way that trust is initially established, to 614 convert an "untrusted entity" into a "trusted entity". 616 The purpose of this document is not to define the specific way in 617 which trust can be established. Protocol designers may rely on a 618 number of existing technologies, including PKI, Trust On First Use 619 (TOFU), or using a short passphrase or PIN with cryptographic 620 algorithms such as Secure Remote Password (SRP) [RFC5054] or a 621 Password Authenticated Key Exchange like J-PAKE [RFC8236] using a 622 Schnorr Non-interactive Zero-Knowledge Proof [RFC8235]. 624 Protocol designers should consider a specific usability pitfall when 625 trust is established immediately prior to performing discovery. 626 Users will have a tendency to "click OK" in order to achieve their 627 task. This implicit vulnerability is avoided if the trust 628 establishment requires active participation of the user, such as 629 entering a password or PIN. 631 3.4.4. External Dependencies 633 Trust establishment may depend on external parties. Optionally, this 634 might involve synchronous communication. Systems which have such a 635 dependency may be attacked by interfering with communication to 636 external dependencies. Where possible, such dependencies should be 637 minimized. Local trust models are best for secure initialization in 638 the presence of active attackers. 640 4. Requirements for a DNS-SD Privacy Extension 642 Given the considerations discussed in the previous sections, we state 643 requirements for privacy preserving DNS-SD in the following 644 subsections. 646 Defining a solution according to these requirements is intended to 647 lead to a solution that does not transmit privacy violating DNS-SD 648 messages and further does not open pathways to new attacks against 649 the operation of DNS-SD. 651 However, while this document gives advice on which privacy protecting 652 mechanisms should be used on deeper layer network protocols and on 653 how to actually connect to services in a privacy preserving way, 654 stating corresponding requirements is out of the scope of this 655 document. To mitigate attacks against privacy on lower layers, both 656 servers and clients must use privacy options available at lower 657 layers, and for example avoid publishing static IPv4 or IPv6 658 addresses, or static IEEE 802 MAC addresses. For services advertised 659 on a single network link, link local IP addresses should be used; see 660 [RFC3927] and [RFC4291] for IPv4 and IPv6, respectively. Static 661 servers advertising services globally via DNS can hide their IP 662 addresses from unauthorized clients using the split mode topology 663 shown in [I-D.ietf-tls-esni]. Hiding static MAC addresses can be 664 achieved via MAC address randomization (see [RFC7844]). 666 4.1. Private Client Requirements 668 For all three scenarios described in Section 3.1, client privacy 669 requires DNS-SD messages to: 671 1. Avoid disclosure of the client's identity, either directly or via 672 inference, to nodes other than select servers. 674 2. Avoid exposure of linkable identifiers that allow tracing client 675 devices. 677 3. Avoid disclosure of the client's interest in specific service 678 instances or service types to nodes other than select servers. 680 When listing and resolving services via current DNS-SD deployments, 681 clients typically disclose their interest in specific services types 682 and specific instances of these types, respectively. 684 In addition to the exposure and disclosure risks noted above, 685 protocols and implementations will have to consider fingerprinting 686 attacks (see Section 3.2.5) that could retrieve similar information. 688 4.2. Private Server Requirements 690 Servers like the "printer" discussed in scenario 1 are public, but 691 the servers discussed in scenarios 2 and 3 are by essence private. 692 Server privacy requires DNS-SD messages to: 694 1. Avoid disclosure of the server's identity, either directly or via 695 inference, to nodes other than authorized clients. In 696 particular, Servers must avoid publishing static identifiers such 697 as host names or service names. When those fields are required 698 by the protocol, servers should publish randomized values. (See 699 [RFC8117] for a discussion of host names.) 701 2. Avoid exposure of linkable identifiers that allow tracing 702 servers. 704 3. Avoid disclosure of service instance names or service types of 705 offered services to unauthorized clients. 707 4. Avoid disclosure of information about the services they offer to 708 unauthorized clients. 710 5. Avoid disclosure of static IPv4 or IPv6 addresses. 712 When offering services via current DNS-SD deployments, servers 713 typically disclose their hostnames (SRV, A/AAAA), instance names of 714 offered services (PRT, SRV), and information about services (TXT). 715 Heeding these requirements protects a server's privacy on the DNS-SD 716 level. 718 4.3. Security and Operation 720 In order to be secure and feasible, a DNS-SD privacy extension needs 721 to consider security and operational requirements including: 723 1. Avoiding significant CPU overhead on nodes or significantly 724 higher network load. Such overhead or load would make nodes 725 vulnerable to denial of service attacks. Further, it would 726 increase power consumption which is critical for IoT devices. 728 2. Avoiding designs in which a small message can trigger a large 729 amount of traffic towards an unverified address, as this could be 730 exploited in amplification attacks. 732 5. IANA Considerations 734 This draft does not require any IANA action. 736 6. Acknowledgments 738 This draft incorporates many contributions from Stuart Cheshire and 739 Chris Wood. Thanks to Florian Adamsky for extensive review and 740 suggestions on the organization of the threat model. 742 7. Informative References 744 [I-D.ietf-dnssd-srp] 745 Cheshire, S. and T. Lemon, "Service Registration Protocol 746 for DNS-Based Service Discovery", draft-ietf-dnssd-srp-02 747 (work in progress), July 2019. 749 [I-D.ietf-tls-esni] 750 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 751 "Encrypted Server Name Indication for TLS 1.3", draft- 752 ietf-tls-esni-05 (work in progress), November 2019. 754 [K17] Kaiser, D., "Efficient Privacy-Preserving 755 Configurationless Service Discovery Supporting Multi-Link 756 Networks", 2017, 757 . 759 [KW14a] Kaiser, D. and M. Waldvogel, "Adding Privacy to Multicast 760 DNS Service Discovery", DOI 10.1109/TrustCom.2014.107, 761 2014, . 764 [KW14b] Kaiser, D. and M. Waldvogel, "Efficient Privacy Preserving 765 Multicast DNS Service Discovery", 766 DOI 10.1109/HPCC.2014.141, 2014, 767 . 770 [RFC1033] Lottor, M., "Domain Administrators Operations Guide", 771 RFC 1033, DOI 10.17487/RFC1033, November 1987, 772 . 774 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 775 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 776 . 778 [RFC1035] Mockapetris, P., "Domain names - implementation and 779 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 780 November 1987, . 782 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 783 specifying the location of services (DNS SRV)", RFC 2782, 784 DOI 10.17487/RFC2782, February 2000, 785 . 787 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 788 Configuration of IPv4 Link-Local Addresses", RFC 3927, 789 DOI 10.17487/RFC3927, May 2005, 790 . 792 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 793 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 794 2006, . 796 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 797 "Using the Secure Remote Password (SRP) Protocol for TLS 798 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 799 2007, . 801 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 802 DOI 10.17487/RFC6762, February 2013, 803 . 805 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 806 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 807 . 809 [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 810 "Requirements for Scalable DNS-Based Service Discovery 811 (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, 812 DOI 10.17487/RFC7558, July 2015, 813 . 815 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 816 Profiles for DHCP Clients", RFC 7844, 817 DOI 10.17487/RFC7844, May 2016, 818 . 820 [RFC8117] Huitema, C., Thaler, D., and R. Winter, "Current Hostname 821 Practice Considered Harmful", RFC 8117, 822 DOI 10.17487/RFC8117, March 2017, 823 . 825 [RFC8235] Hao, F., Ed., "Schnorr Non-interactive Zero-Knowledge 826 Proof", RFC 8235, DOI 10.17487/RFC8235, September 2017, 827 . 829 [RFC8236] Hao, F., Ed., "J-PAKE: Password-Authenticated Key Exchange 830 by Juggling", RFC 8236, DOI 10.17487/RFC8236, September 831 2017, . 833 Authors' Addresses 835 Christian Huitema 836 Private Octopus Inc. 837 Friday Harbor, WA 98250 838 U.S.A. 840 Email: huitema@huitema.net 841 URI: http://privateoctopus.com/ 843 Daniel Kaiser 844 University of Luxembourg 845 6, avenue de la Fonte 846 Esch-sur-Alzette 4364 847 Luxembourg 849 Email: daniel.kaiser@uni.lu 850 URI: https://secan-lab.uni.lu/