idnits 2.17.1 draft-ietf-dnssd-prireq-03.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 (December 20, 2019) is 1588 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: June 22, 2020 University of Luxembourg 6 December 20, 2019 8 DNS-SD Privacy and Security Requirements 9 draft-ietf-dnssd-prireq-03 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 over Multicast DNS at a public 18 hotspot, serious privacy problems arise. We analyze the requirements 19 of a privacy respecting 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 June 22, 2020. 38 Copyright Notice 40 Copyright (c) 2019 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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Service Discovery Scenarios . . . . . . . . . . . . . . . 4 60 3.1.1. Private Client and Public Server . . . . . . . . . . 4 61 3.1.2. Private Client and Private Server . . . . . . . . . . 5 62 3.1.3. Wearable Client and Server . . . . . . . . . . . . . 6 63 3.2. DNS-SD Privacy Considerations . . . . . . . . . . . . . . 7 64 3.2.1. Information made available via DNS-SD Resource 65 Records . . . . . . . . . . . . . . . . . . . . . . . 8 66 3.2.2. Privacy Implication of Publishing Service Instance 67 Names . . . . . . . . . . . . . . . . . . . . . . . . 9 68 3.2.3. Privacy Implication of Publishing Node Names . . . . 9 69 3.2.4. Privacy Implication of Publishing Service Attributes 10 70 3.2.5. Device Fingerprinting . . . . . . . . . . . . . . . . 10 71 3.2.6. Privacy Implication of Discovering Services . . . . . 11 72 3.3. Security Considerations . . . . . . . . . . . . . . . . . 12 73 3.3.1. Authenticity, Integrity & Freshness . . . . . . . . . 12 74 3.3.2. Confidentiality . . . . . . . . . . . . . . . . . . . 12 75 3.3.3. Resistance to Dictionary Attacks . . . . . . . . . . 12 76 3.3.4. Resistance to Denial-of-Service Attacks . . . . . . . 12 77 3.3.5. Resistance to Sender Impersonation . . . . . . . . . 13 78 3.3.6. Sender Deniability . . . . . . . . . . . . . . . . . 13 79 3.4. Operational Considerations . . . . . . . . . . . . . . . 13 80 3.4.1. Power Management . . . . . . . . . . . . . . . . . . 13 81 3.4.2. Protocol Efficiency . . . . . . . . . . . . . . . . . 13 82 3.4.3. Secure Initialization and Trust Models . . . . . . . 14 83 3.4.4. External Dependencies . . . . . . . . . . . . . . . . 15 84 4. Requirements for a DNS-SD Privacy Extension . . . . . . . . . 15 85 4.1. Private Client Requirements . . . . . . . . . . . . . . . 16 86 4.2. Private Server Requirements . . . . . . . . . . . . . . . 16 87 4.3. Security and Operation . . . . . . . . . . . . . . . . . 17 88 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 89 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 90 7. Informative References . . . . . . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Introduction 95 DNS-SD [RFC6763] over mDNS [RFC6762] enables zero-configuration 96 service discovery in local networks. It is very convenient for 97 users, but it requires the public exposure of the offering and 98 requesting identities along with information about the offered and 99 requested services. Parts of the published information can seriously 100 breach the user's privacy. These privacy issues and potential 101 solutions are discussed in [KW14a], [KW14b] and [K17]. 103 There are cases when nodes connected to a network want to provide or 104 consume services without exposing their identity to the other parties 105 connected to the same network. Consider for example a traveler 106 wanting to upload pictures from a phone to a laptop when connected to 107 the Wi-Fi network of an Internet cafe, or two travelers who want to 108 share files between their laptops when waiting for their plane in an 109 airport lounge. 111 We expect that these exchanges will start with a discovery procedure 112 using DNS-SD [RFC6763] over mDNS [RFC6762]. One of the devices will 113 publish the availability of a service, such as a picture library or a 114 file store in our examples. The user of the other device will 115 discover this service, and then connect to it. 117 When analyzing these scenarios in Section 3.2, we find that the DNS- 118 SD messages leak identifying information such as the service instance 119 name, the host name, or service properties. 121 1.1. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 Identity In this document, the term "identity" refers to the 128 identity of the entitiy (legal person) operating a device. 130 Disclosing an Identity In this document "disclosing an identiy" 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 by data conveyed via messages on the 141 service discovery protocol layer. 143 2. Threat Model 145 This document considers the following attacker types sorted by 146 increasing power. All these attackers can either be passive, i.e. 147 they just listen to network traffic they have access to, or active, 148 i.e. they additionally can craft and send (malicious) packets. 150 external An external attacker is not on the same network link as 151 victim devices engaging in service discovery; thus, the external 152 attacker is in a different multicast domain. 154 on-link An on-link attacker is on the same network link as victim 155 devices engaging in service discovery; thus, the external attacker 156 is in the same multicast domain. This attacker can also mount all 157 attacks an external attacker can mount. 159 MITM A Man in the Middle (MITM) attacker either controls (parts of) 160 a network link or can trick two parties to send traffic via him; 161 thus, the MITM attacker has access to unicast traffic between 162 devices engaging in service discovery. This attacker can also 163 mount all attacks an on-link attacker can mount. 165 3. Threat Analysis 167 In this section we analyse how the attackers described in the 168 previous section might threaten the privacy of legal persons 169 operating devices engaging in service discovery. We focus on attacks 170 leveraging data transmitted in service discovery protocol messages. 172 3.1. Service Discovery Scenarios 174 In this section, we review common service discovery scenarios and 175 discuss privacy threats and their privacy requirements. In all three 176 of these common scenarios the attacker is of the type passive on- 177 link. 179 3.1.1. Private Client and Public Server 181 Perhaps the simplest private discovery scenario involves a single 182 client connecting to a public server through a public network. A 183 common example would be a traveler using a publicly available printer 184 in a business center, in an hotel, or at an airport. 186 ( Taking notes: 187 ( David is printing 188 ( a document 189 ~~~~~~~~~~~ 190 o 191 ___ o ___ 192 / \ _|___|_ 193 | | client server |* *| 194 \_/ __ \_/ 195 | / / Discovery +----------+ | 196 /|\ /_/ <-----------> | +----+ | /|\ 197 / | \__/ +--| |--+ / | \ 198 / | |____/ / | \ 199 / | / | \ 200 / \ / \ 201 / \ / \ 202 / \ / \ 203 / \ / \ 204 / \ / \ 206 David adversary 208 In that scenario, the server is public and wants to be discovered, 209 but the client is private. The adversary will be listening to the 210 network traffic, trying to identify the visitors' devices and their 211 activity. Identifying devices leads to identifying people, either 212 just for tracking people or as a preliminary to targeted attacks. 214 The requirement in that scenario is that the discovery activity 215 should not disclose the identity of the client. 217 3.1.2. Private Client and Private Server 219 The second private discovery scenario involves a private client 220 connecting to a private server. A common example would be two people 221 engaging in a collaborative application in a public place, such as 222 for example an airport's lounge. 224 ( Taking notes: 225 ( David is meeting 226 ( with Stuart 227 ~~~~~~~~~~~ 228 o 229 ___ ___ o ___ 230 / \ / \ _|___|_ 231 | | server client | | |* *| 232 \_/ __ __ \_/ \_/ 233 | / / Discovery \ \ | | 234 /|\ /_/ <-----------> \_\ /|\ /|\ 235 / | \__/ \__/ | \ / | \ 236 / | | \ / | \ 237 / | | \ / | \ 238 / \ / \ / \ 239 / \ / \ / \ 240 / \ / \ / \ 241 / \ / \ / \ 242 / \ / \ / \ 244 David Stuart Adversary 246 In that scenario, the collaborative application on one of the devices 247 will act as a server, and the application on the other device will 248 act as a client. The server wants to be discovered by the client, 249 but has no desire to be discovered by anyone else. The adversary 250 will be listening to network traffic, attempting to discover the 251 identity of devices as in the first scenario, and also attempting to 252 discover the patterns of traffic, as these patterns reveal the 253 business and social interactions between the owners of the devices. 255 The requirement in that scenario is that the discovery activity 256 should not disclose the identity of either the client or the server. 258 3.1.3. Wearable Client and Server 260 The third private discovery scenario involves wearable devices. A 261 typical example would be the watch on someone's wrist connecting to 262 the phone in their pocket. 264 ( Taking notes: 265 ( David' is here. His watch is 266 ( talking to his phone 267 ~~~~~~~~~~~ 268 o 269 ___ o ___ 270 / \ _|___|_ 271 | | client |* *| 272 \_/ \_/ 273 | _/ | 274 /|\ // /|\ 275 / | \__/ ^ / | \ 276 / |__ | Discovery / | \ 277 / |\ \ v / | \ 278 / \\_\ / \ 279 / \ server / \ 280 / \ / \ 281 / \ / \ 282 / \ / \ 284 David Adversary 286 This third scenario is in many ways similar to the second scenario. 287 It involves two devices, one acting as server and the other acting as 288 client, and it leads to the same requirement of the discovery traffic 289 not disclosing the identity of either the client or the server. The 290 main difference is that the devices are managed by a single owner, 291 which can lead to different methods for establishing secure relations 292 between the devices. There is also an added emphasis on hiding the 293 type of devices that the person wears. 295 In addition to tracking the identity of the owner of the devices, the 296 adversary is interested in the characteristics of the devices, such 297 as type, brand, and model. Identifying the type of device can lead 298 to further attacks, from theft to device specific hacking. The 299 combination of devices worn by the same person will also provide a 300 "fingerprint" of the person, allowing identification. 302 3.2. DNS-SD Privacy Considerations 304 While the discovery process illustrated in the scenarios in Section 2 305 most likely would be based on [RFC6762] as a means for making service 306 information available, this document considers all kinds of means for 307 making DNS-SD resource records available. These means comprise but 308 are not limited to mDNS [RFC6762], DNS servers ([RFC1033] [RFC1034], 309 [RFC1035]), e.g. using SRP [I-D.ietf-dnssd-srp], and multi-link 310 [RFC7558] networks. 312 The discovery scenarios in Section 3.1 illustrate three separate 313 abstract privacy requirements that vary based on the use case. These 314 are not limited to mDNS. 316 1. Client identity privacy: Client identities are not leaked during 317 service discovery or use. 319 2. Multi-entity, mutual client and server identity privacy: Neither 320 client nor server identities are leaked during service discovery 321 or use. 323 3. Single-entity, mutual client and server identity privacy: 324 Identities of clients and servers owned and managed by the same 325 legal person are not leaked during service discovery or use. 327 In this section, we describe aspects of DNS-SD that make these 328 requirements difficult to achieve in practice. 330 Client identity privacy, if not addressed properly, can be thwarted 331 by a passive attacker (see Section 2). The type of passive attacker 332 necessary depends on the means of making service information 333 available. Information conveyed via multicast messages can be 334 obtained by an on-link attacker, while unicast messages are only 335 available to MITM attackers. Using multi-link service discovery 336 solutions [RFC7558], external attackers have to be taken into 337 consideration as well, e.g., when relaying multicast messages to 338 other links. 340 Server identity privacy can be thwarted by a passive attacker in the 341 same way as client identity privacy. Additionally, active attackers 342 querying for information have to be taken into consideration as well. 343 This is mainly relevant for unicast based discovery, where listening 344 to discovery traffic requires a MITM attacker; however, an external 345 active attacker might be able to learn the server identity by just 346 querying for service information, e.g. via DNS. 348 3.2.1. Information made available via DNS-SD Resource Records 350 DNS-Based Service Discovery (DNS-SD) is defined in [RFC6763]. It 351 allows nodes to publish the availability of an instance of a service 352 by inserting specific records in the DNS ([RFC1033], [RFC1034], 353 [RFC1035]) or by publishing these records locally using multicast DNS 354 (mDNS) [RFC6762]. Available services are described using three types 355 of records: 357 PTR Record: Associates a service type in the domain with an 358 "instance" name of this service type. 360 SRV Record: Provides the node name, port number, priority and weight 361 associated with the service instance, in conformance with 362 [RFC2782]. 364 TXT Record: Provides a set of attribute-value pairs describing 365 specific properties of the service instance. 367 3.2.2. Privacy Implication of Publishing Service Instance Names 369 In the first phase of discovery, clients obtain all PTR records 370 associated with a service type in a given naming domain. Each PTR 371 record contains a Service Instance Name defined in Section 4 of 372 [RFC6763]: 374 Service Instance Name = . . 376 The portion of the Service Instance Name is meant to 377 convey enough information for users of discovery clients to easily 378 select the desired service instance. Nodes that use DNS-SD over mDNS 379 [RFC6762] in a mobile environment will rely on the specificity of the 380 instance name to identify the desired service instance. In our 381 example of users wanting to upload pictures to a laptop in an 382 Internet Cafe, the list of available service instances may look like: 384 Alice's Images . _imageStore._tcp . local 385 Alice's Mobile Phone . _presence._tcp . local 386 Alice's Notebook . _presence._tcp . local 387 Bob's Notebook . _presence._tcp . local 388 Carol's Notebook . _presence._tcp . local 390 Alice will see the list on her phone and understand intuitively that 391 she should pick the first item. The discovery will "just work". 393 However, DNS-SD/mDNS will reveal to anybody that Alice is currently 394 visiting the Internet Cafe. It further discloses the fact that she 395 uses two devices, shares an image store, and uses a chat application 396 supporting the _presence protocol on both of her devices. She might 397 currently chat with Bob or Carol, as they are also using a _presence 398 supporting chat application. This information is not just available 399 to devices actively browsing for and offering services, but to 400 anybody passively listening to the network traffic, i.e. a passive 401 on-link attacker. 403 3.2.3. Privacy Implication of Publishing Node Names 405 The SRV records contain the DNS name of the node publishing the 406 service. Typical implementations construct this DNS name by 407 concatenating the "host name" of the node with the name of the local 408 domain. The privacy implications of this practice are reviewed in 409 [RFC8117]. Depending on naming practices, the host name is either a 410 strong identifier of the device, or at a minimum a partial 411 identifier. It enables tracking of both the device, and, by 412 extension, the device's owner. 414 3.2.4. Privacy Implication of Publishing Service Attributes 416 The TXT record's attribute-value pairs contain information on the 417 characteristics of the corresponding service instance. This in turn 418 reveals information about the devices that publish services. The 419 amount of information varies widely with the particular service and 420 its implementation: 422 o Some attributes like the paper size available in a printer, are 423 the same on many devices, and thus only provide limited 424 information to a tracker. 426 o Attributes that have freeform values, such as the name of a 427 directory, may reveal much more information. 429 Combinations of attributes have more information power than specific 430 attributes, and can potentially be used for "fingerprinting" a 431 specific device. 433 Information contained in TXT records does not only breach privacy by 434 making devices trackable, but might directly contain private 435 information about the user. For instance the _presence service 436 reveals the "chat status" to everyone in the same network. Users 437 might not be aware of that. 439 Further, TXT records often contain version information about services 440 allowing potential attackers to identify devices running exploit- 441 prone versions of a certain service. 443 3.2.5. Device Fingerprinting 445 The combination of information published in DNS-SD has the potential 446 to provide a "fingerprint" of a specific device. Such information 447 includes: 449 o List of services published by the device, which can be retrieved 450 because the SRV records will point to the same host name. 452 o Specific attributes describing these services. 454 o Port numbers used by the services. 456 o Priority and weight attributes in the SRV records. 458 This combination of services and attributes will often be sufficient 459 to identify the version of the software running on a device. If a 460 device publishes many services with rich sets of attributes, the 461 combination may be sufficient to identify the specific device. 463 A sometimes heard argument is that devices providing services can be 464 identified by observing the local traffic, and that trying to hide 465 the presence of the service is futile. However, 467 1. Providing privacy at the discovery layer is of the essence for 468 enabling automatically configured privacy-preserving network 469 applications. Application layer protocols are not forced to 470 leverage the offered privacy, but if device tracking is not 471 prevented at the deeper layers, including the service discovery 472 layer, obfuscating a certain service's protocol at the 473 application layer is futile. 475 2. Further, in the case of mDNS based discovery, even if the 476 application layer does not protect privacy, typically services 477 are provided via unicast which requires a MITM attacker, while 478 identifying services based on multicast discovery messages just 479 requires an on-link attacker. 481 The same argument can be extended to say that the pattern of services 482 offered by a device allows for fingerprinting the device. This may 483 or may not be true, since we can expect that services will be 484 designed or updated to avoid leaking fingerprints. In any case, the 485 design of the discovery service should avoid making a bad situation 486 worse, and should as much as possible avoid providing new 487 fingerprinting information. 489 3.2.6. Privacy Implication of Discovering Services 491 The consumers of services engage in discovery, and in doing so reveal 492 some information such as the list of services they are interested in 493 and the domains in which they are looking for the services. When the 494 clients select specific instances of services, they reveal their 495 preference for these instances. This can be benign if the service 496 type is very common, but it could be more problematic for sensitive 497 services, such as for example some private messaging services. 499 One way to protect clients would be to somehow encrypt the requested 500 service types. Of course, just as we noted in Section 3.2.5, traffic 501 analysis can often reveal the service. 503 3.3. Security Considerations 505 For each of the operations described above, we must also consider 506 security threats we are concerned about. 508 3.3.1. Authenticity, Integrity & Freshness 510 Can we trust the information we receive? Has it been modified in 511 flight by an adversary? Do we trust the source of the information? 512 Is the source of information fresh, i.e., not replayed? Freshness 513 may or may not be required depending on whether the discovery process 514 is meant to be online. In some cases, publishing discovery 515 information to a shared directory or registry, rather than to each 516 online recipient through a broadcast channel, may suffice. 518 3.3.2. Confidentiality 520 Confidentiality is about restricting information access to only 521 authorized individuals. Ideally this should only be the appropriate 522 trusted parties, though it can be challenging to define who are "the 523 appropriate trusted parties." In some uses cases, this may mean that 524 only mutually authenticated and trusting clients and servers can read 525 messages sent for one another. The "Discover" operation in 526 particular is often used to discover new entities that the device did 527 not previously know about. It may be tricky to work out how a device 528 can have an established trust relationship with a new entity it has 529 never previously communicated with. 531 3.3.3. Resistance to Dictionary Attacks 533 It can be tempting to use (publicly computable) hash functions to 534 obscure sensitive identifiers. This transforms a sensitive unique 535 identifier such as an email address into a "scrambled" but still 536 unique identifier. Unfortunately simple solutions may be vulnerable 537 to offline dictionary attacks. 539 3.3.4. Resistance to Denial-of-Service Attacks 541 In any protocol where the receiver of messages has to perform 542 cryptographic operations on those messages, there is a risk of a 543 brute-force flooding attack causing the receiver to expend excessive 544 amounts of CPU time and, where appliciable, battery power just 545 processing and discarding those messages. 547 Also, amplification attacks have to be taken into consideration. 548 Messages with larger payloads should only be sent as an answer to a 549 query sent by a verified client. 551 3.3.5. Resistance to Sender Impersonation 553 Sender impersonation is an attack wherein messages such as service 554 offers are forged by entities who do not possess the corresponding 555 secret key material. These attacks may be used to learn the identity 556 of a communicating party, actively or passively. 558 3.3.6. Sender Deniability 560 Deniability of sender activity, e.g., of broadcasting a discovery 561 request, may be desirable or necessary in some use cases. This 562 property ensures that eavesdroppers cannot prove senders issued a 563 specific message destined for one or more peers. 565 3.4. Operational Considerations 567 3.4.1. Power Management 569 Many modern devices, especially battery-powered devices, use power 570 management techniques to conserve energy. One such technique is for 571 a device to transfer information about itself to a proxy, which will 572 act on behalf of the device for some functions, while the device 573 itself goes to sleep to reduce power consumption. When the proxy 574 determines that some action is required which only the device itself 575 can perform, the proxy may have some way, such as Ethernet "Magic 576 Packet", to wake the device. 578 In many cases, the device may not trust the network proxy 579 sufficiently to share all its confidential key material with the 580 proxy. This poses challenges for combining private discovery that 581 relies on per-query cryptographic operations, with energy-saving 582 techniques that rely on having (somewhat untrusted) network proxies 583 answer queries on behalf of sleeping devices. 585 3.4.2. Protocol Efficiency 587 Creating a discovery protocol that has the desired security 588 properties may result in a design that is not efficient. To perform 589 the necessary operations the protocol may need to send and receive a 590 large number of network packets. This may consume an unreasonable 591 amount of network capacity, particularly problematic when it is a 592 shared wireless spectrum. Further it may cause an unnecessary level 593 of power consumption which is particularly problematic on battery 594 devices, and may result in the discovery process being slow. 596 It is a difficult challenge to design a discovery protocol that has 597 the property of obscuring the details of what it is doing from 598 unauthorized observers, while also managing to do that efficiently. 600 3.4.3. Secure Initialization and Trust Models 602 One of the challenges implicit in the preceding discussions is that 603 whenever we discuss "trusted entities" versus "untrusted entities", 604 there needs to be some way that trust is initially established, to 605 convert an "untrusted entity" into a "trusted entity". 607 One way to establish trust between two entities is to trust a third 608 party to make that determination for us. For example, the X.509 609 certificates used by TLS and HTTPS web browsing are based on the 610 model of trusting a third party to tell us whom to trust. There are 611 some difficulties in using this model for establishing trust for 612 service discovery uses. If we want to print our tax returns or 613 medical documents on "our" printer, then we need to know which 614 printer on the network we can trust be be "our" printer. All of the 615 printers we discover on the network may be legitimate printers made 616 by legitimate printer manufacturers, but not all of them are "our" 617 printer. A third-party certificate authority cannot tell us which 618 one of the printers is ours. 620 Another common way to establish a trust relationship is Trust On 621 First Use (TOFU), as used by ssh. The first usage is a Leap Of 622 Faith, but after that public keys are exchanged and at least we can 623 confirm that subsequent communications are with the same entity. In 624 today's world, where there may be attackers present even at that 625 first use, it would be preferable to be able to establish a trust 626 relationship without requiring an initial Leap Of Faith. 628 Techniques now exist for securely establishing a trust relationship 629 without requiring an initial Leap Of Faith. Trust can be established 630 securely using a short passphrase or PIN with cryptographic 631 algorithms such as Secure Remote Password (SRP) [RFC5054] or a 632 Password Authenticated Key Exchange like J-PAKE [RFC8236] using a 633 Schnorr Non-interactive Zero-Knowledge Proof [RFC8235]. 635 Such techniques require a user to enter the correct passphrase or PIN 636 in order for the cryptographic algorithms to establish working 637 communication. This avoids the human tendency to simply press the 638 "OK" button when asked if they want to do something on their 639 electronic device. It removes the human fallibility element from the 640 equation, and avoids the human users inadvertently sabotaging their 641 own security. 643 Without these techniques, users who try to print their tax return on 644 a printer they've never used before will be tempted to just go ahead 645 if the name looks right. With these techniques they'll be prompted 646 to enter a pairing PIN, and *cannot* ignore that warning. They can't 647 just press an "OK" button. They have to walk to the printer and read 648 the displayed PIN and enter it. And if the intended printer is not 649 displaying a pairing PIN, or is displaying a different pairing PIN, 650 that means the user may be being spoofed, and the connection will not 651 succeed, and the failure will not reveal any secret information to 652 the attacker. As much as the human desires to "just give me an OK 653 button to make it print", and the attacker desires them to click that 654 OK button, too, the cryptographic algorithms do not give the user the 655 ability to opt out of the security, and consequently do not give the 656 attacker any way to persuade the user to opt out of the security 657 protections. 659 3.4.4. External Dependencies 661 Trust establishment may depend on external, and optionally online, 662 parties. Systems which have such a dependency may be attacked by 663 interfering with communication to external dependencies. Where 664 possible, such dependencies should be minimized. Local trust models 665 are best for secure initialization in the presence of active 666 attackers. 668 4. Requirements for a DNS-SD Privacy Extension 670 Given the considerations discussed in the previous sections, we state 671 requirements for privacy preserving DNS-SD in the following 672 subsections. 674 Defining a solution according to these requirements will lead to a 675 solution that does not transmit privacy violating DNS-SD messages and 676 further does not open pathways to new attacks against the operation 677 of DNS-SD. 679 However, while this document gives advice on which privacy protecting 680 mechanisms should be used on deeper layer network protocols and on 681 how to actually connect to services in a privacy preserving way, 682 stating corresponding requirements is out of the scope of this 683 document. To mitigate attacks against privacy on lower layers, both 684 servers and clients must use privacy options available at lower 685 layers, and for example avoid publishing static IPv4 or IPv6 686 addresses, or static IEEE 802 MAC addresses. For services advertised 687 on a single network link, link local IP addresses should be used; see 688 [RFC3927] and [RFC4291] for IPv4 and IPv6, respectively. Static 689 servers advertising services globally via DNS can hide their IP 690 addresses from unauthorized clients using the split mode topology 691 shown in [I-D.ietf-tls-esni]. Hiding static MAC addresses can be 692 achieved via MAC address randomization (see [RFC7844]). 694 4.1. Private Client Requirements 696 For all three scenarios described in Section 3.1, client privacy is a 697 requirement. Client privacy, as a requirement, can be subdivided 698 into: 700 1. DNS-SD messages transmitted by clients MUST NOT disclose the 701 client's identity, either directly or via inference, to nodes 702 other than select servers. 704 1. 706 2. DNS-SD messages transmitted by clients MUST NOT contain linkable 707 identifiers that allow tracing client devices. 709 2. 711 3. DNS-SD messages transmitted by clients MUST NOT disclose the 712 client's interest in specific service instances or service types 713 to nodes other than select servers. 715 3. 717 Listing and resolving services via DNS-SD, clients typically disclose 718 their interest in specific services types and specific instances of 719 these types, respectively. 721 Privacy solutions fulfilling these requirements must be resilient to 722 fingerprinting attacks (see Section 3.2.5) that could be used for 723 breaching these requirements. 725 4.2. Private Server Requirements 727 Servers like the "printer" discussed in scenario 1 are public, but 728 the servers discussed in scenarios 2 and 3 are by essence private. 729 Private servers have server privacy as a requirement, which can be 730 subdivided into: 732 1. DNS-SD messages transmitted by servers MUST NOT disclose the 733 server's identity, either directly or via inference, to nodes 734 other than authorized clients. In particular, Servers MUST NOT 735 publish static identifiers such as host names or service names. 736 When those fields are required by the protocol, servers should 737 publish randomized values. (See [RFC8117] for a discussion of 738 host names.) 740 1. 742 2. DNS-SD messages transmitted by servers MUST NOT contain linkable 743 identifiers that allow tracing servers. 745 2. 747 3. DNS-SD messages transmitted by servers MUST NOT disclose service 748 instance names or service types of offered services to 749 unauthorized clients. 751 3. 753 4. DNS-SD messages transmitted by servers MUST NOT disclose 754 information about the services they offer to unauthorized 755 clients. 757 4. 759 5. DNS-SD messages transmitted by servers MUST NOT disclose static 760 IPv4 or IPv6 addresses. 762 5. 764 Offering services via DNS-SD, servers typically disclose their 765 hostnames (SRV, A/AAAA), instance names of offered services (PRT, 766 SRV), and information about services (TXT). Heeding these 767 requirements protects a server's privacy on the DNS-SD level. 769 4.3. Security and Operation 771 In order to be secure and feasible, a DNS-SD privacy extension must 772 also heed the following security and operational requirements. 774 All scenarios require: 776 1. DoS resistance: The privacy protecting measures added to DNS-SD 777 MUST neither add a significant CPU overhead on nodes, nor cause 778 significantly higher network load. Further, amplification 779 attacks MUST NOT be allowed. 781 5. IANA Considerations 783 This draft does not require any IANA action. 785 6. Acknowledgments 787 This draft incorporates many contributions from Stuart Cheshire and 788 Chris Wood. Thanks to Florian Adamsky for extensive review and 789 suggestions on the organization of the threat model. 791 7. Informative References 793 [I-D.ietf-dnssd-srp] 794 Cheshire, S. and T. Lemon, "Service Registration Protocol 795 for DNS-Based Service Discovery", draft-ietf-dnssd-srp-02 796 (work in progress), July 2019. 798 [I-D.ietf-tls-esni] 799 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 800 "Encrypted Server Name Indication for TLS 1.3", draft- 801 ietf-tls-esni-05 (work in progress), November 2019. 803 [K17] Kaiser, D., "Efficient Privacy-Preserving 804 Configurationless Service Discovery Supporting Multi-Link 805 Networks", 2017, 806 . 808 [KW14a] Kaiser, D. and M. Waldvogel, "Adding Privacy to Multicast 809 DNS Service Discovery", DOI 10.1109/TrustCom.2014.107, 810 2014, . 813 [KW14b] Kaiser, D. and M. Waldvogel, "Efficient Privacy Preserving 814 Multicast DNS Service Discovery", 815 DOI 10.1109/HPCC.2014.141, 2014, 816 . 819 [RFC1033] Lottor, M., "Domain Administrators Operations Guide", 820 RFC 1033, DOI 10.17487/RFC1033, November 1987, 821 . 823 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 824 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 825 . 827 [RFC1035] Mockapetris, P., "Domain names - implementation and 828 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 829 November 1987, . 831 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 832 Requirement Levels", BCP 14, RFC 2119, 833 DOI 10.17487/RFC2119, March 1997, 834 . 836 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 837 specifying the location of services (DNS SRV)", RFC 2782, 838 DOI 10.17487/RFC2782, February 2000, 839 . 841 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 842 Configuration of IPv4 Link-Local Addresses", RFC 3927, 843 DOI 10.17487/RFC3927, May 2005, 844 . 846 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 847 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 848 2006, . 850 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 851 "Using the Secure Remote Password (SRP) Protocol for TLS 852 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 853 2007, . 855 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 856 DOI 10.17487/RFC6762, February 2013, 857 . 859 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 860 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 861 . 863 [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 864 "Requirements for Scalable DNS-Based Service Discovery 865 (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, 866 DOI 10.17487/RFC7558, July 2015, 867 . 869 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 870 Profiles for DHCP Clients", RFC 7844, 871 DOI 10.17487/RFC7844, May 2016, 872 . 874 [RFC8117] Huitema, C., Thaler, D., and R. Winter, "Current Hostname 875 Practice Considered Harmful", RFC 8117, 876 DOI 10.17487/RFC8117, March 2017, 877 . 879 [RFC8235] Hao, F., Ed., "Schnorr Non-interactive Zero-Knowledge 880 Proof", RFC 8235, DOI 10.17487/RFC8235, September 2017, 881 . 883 [RFC8236] Hao, F., Ed., "J-PAKE: Password-Authenticated Key Exchange 884 by Juggling", RFC 8236, DOI 10.17487/RFC8236, September 885 2017, . 887 Authors' Addresses 889 Christian Huitema 890 Private Octopus Inc. 891 Friday Harbor, WA 98250 892 U.S.A. 894 Email: huitema@huitema.net 895 URI: http://privateoctopus.com/ 897 Daniel Kaiser 898 University of Luxembourg 899 6, avenue de la Fonte 900 Esch-sur-Alzette 4364 901 Luxembourg 903 Email: daniel.kaiser@uni.lu 904 URI: https://secan-lab.uni.lu/