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