idnits 2.17.1 draft-huitema-dnssd-privacy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2016) is 2969 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-ietf-dprive-dns-over-tls-07 == Outdated reference: A later version (-15) exists of draft-ietf-dprive-dnsodtls-04 == Outdated reference: A later version (-05) exists of draft-ietf-intarea-hostname-practice-00 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Huitema 3 Internet-Draft Microsoft 4 Intended status: Standards Track March 9, 2016 5 Expires: September 10, 2016 7 Privacy Extensions for DNS-SD 8 draft-huitema-dnssd-privacy-00.txt 10 Abstract 12 DNS-SD allows discovery of services published in DNS or MDNS. The 13 publication normally disclose information about the device publishing 14 the services. There are use cases where devices want to communicate 15 without disclosing their identity, for example two mobile devices 16 visiting the same hotspot. We propose a method to obfuscate the 17 identification information published by DNS-SD. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 10, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Privacy implications of DNS-SD . . . . . . . . . . . . . . . 3 56 2.1. Privacy implication of publishing instance names . . . . 3 57 2.2. Privacy implication of publishing node names . . . . . . 4 58 2.3. Privacy implication of publishing service attributes . . 4 59 2.4. Device fingerprinting . . . . . . . . . . . . . . . . . . 5 60 2.5. Privacy implication of discovering services . . . . . . . 5 61 3. Design of DNS-SD privacy mitigations . . . . . . . . . . . . 5 62 3.1. Obfuscated instance names . . . . . . . . . . . . . . . . 5 63 3.2. Randomized host names . . . . . . . . . . . . . . . . . . 6 64 3.3. Timing of obfuscation and randomization . . . . . . . . . 7 65 3.4. Fingerprint resistance . . . . . . . . . . . . . . . . . 7 66 3.5. A note on Private DNS services . . . . . . . . . . . . . 7 67 4. Privacy extensions for DNS-SD . . . . . . . . . . . . . . . . 8 68 4.1. Randomized Host Name . . . . . . . . . . . . . . . . . . 8 69 4.2. Instance Discovery Key . . . . . . . . . . . . . . . . . 8 70 4.3. Composing Obfuscated Instance Names . . . . . . . . . . . 9 71 4.4. De-Obfuscation of Instance Names . . . . . . . . . . . . 9 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 8.2. Informative References . . . . . . . . . . . . . . . . . 11 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 There are cases when nodes connected to a network want to provide or 83 consume services without exposing their identity to the other parties 84 connected to the same network. Consider for example a traveller 85 wanting to upload pictures from a phone to a laptop when connected to 86 the Wi-Fi network of an Internet cafe, or two travellers who want to 87 share files between their laptops when waiting for their plane in an 88 airport lounge. 90 We expect that these exchanges will start with a discovery procedure 91 using DNS-SD [RFC6763]. One of the devices will publish the 92 availability of a service, such as a picture library or a file store 93 in our examples. The user of the other device will discover this 94 service, and then connect to it. 96 When analysing these scenarios in Section 2, we find that the DNS-SD 97 messages leak identifying information such as instance name, host 98 name or service properties. We review the design constraint of a 99 solution in Section 3, and describe the proposed solution in 100 Section 4. 102 1.1. Requirements 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 2. Privacy implications of DNS-SD 110 DNS-Based Service Discovery (DNS-SD) is defined in [RFC6763]. It 111 allows nodes to publish the availibility of an instance of a service 112 by inserting specific records in the DNS ([RFC1033], [RFC1034], 113 [RFC1035]) or by publishing these records locally using multicast DNS 114 (MDNS) [RFC6762]. The service availability will be described in 115 three types of records: 117 PTR Record: Associate the service name in the domain with the 118 "instance" name published by the node. 120 SRV Record: Provides the node name, port number, priority and weight 121 associated with the service instance, in conformance with 122 [RFC2782]. 124 TXT Record: Provides a set of attribute-value pairs describing 125 specific properties of the service instance. 127 In the remaining subsections, we will review the privacy issues 128 related to publishing instance names, node names, service attributes 129 and other data, as well as review the implications of using the 130 discovery service as a client. 132 2.1. Privacy implication of publishing instance names 134 In the first phase of discovery, the client will obtain a copy of all 135 the PTR records associated to a service in a given naming domain. 136 Each record contains a domain name starting with an instance name. 137 Instance names are free form description of the instance, and are 138 meant to convey enough information so discovery clients can easily 139 select the desired service. Section 4 of [RFC6763] give the 140 following example for the instance names of a printer service: 142 Building 2, 1st Floor . example . com . 143 Building 2, 2nd Floor . example . com . 144 Building 2, 3rd Floor . example . com . 145 Building 2, 4th Floor . example . com . 147 Nodes that use DNS-SD in a mobile environment will rely on the 148 specificity of the instance name to identify the desired service. In 149 our example of users wanting to upload pictures to a laptop in an 150 Internet Cafe, the list of available services may look like: 152 Alice's notebook . local . 153 Bob's laptop . local . 154 Image store for Carol . local . 156 Alice will see the list on her phone and understand intuitively that 157 she should pick the fist item. The discovery will "just work." It 158 will also reveal to anybody who cares that Alice is currently 159 visiting the Internet Cafe. 161 2.2. Privacy implication of publishing node names 163 The SRV records contain the DNS name of the node publishing the 164 service. Typical implementations construct this DNS name by 165 concatenating the "host name" of the node with the name of the local 166 domain. The privacy implications of this practice are reviewed in 167 [I-D.ietf-intarea-hostname-practice]. Depending on naming practices, 168 the host name is either a strong identifier of the device, or at a 169 minimum a partial identifier. It enables tracking of the device, and 170 by extension of the device's owner. 172 2.3. Privacy implication of publishing service attributes 174 The TXT records contain a set of attribute and value pairs 175 characteristics of the service implementation. These attributes 176 reveal some information about the devices that publishes the service. 177 The amount of information will vary widely with the particular 178 service and its implementation: 180 o Some attributeslike the paper size available in a printer, are the 181 same on many devices, and thus only provides limited information 182 to a tracker. 184 o Attributes that have freeform values, such as the name of a 185 directory, may reveal much more information. 187 Combinations of attributes have more information power than specific 188 attributes, and can potentially be used for "fingerprinting" a 189 specific device. 191 2.4. Device fingerprinting 193 The combination of information published in DNS-SD has the potential 194 to provide a "fingerprint" of a specific device. Such information 195 includes: 197 o The list of services published by the device, which can be 198 retrieved because the SRV records will point to the same host 199 name. 201 o The specific attributes describing these services. 203 o The port numbers used by the services. 205 o The values of the priority and weight attributes in the SRV 206 records. 208 This combination of services and attribute will often be sufficient 209 to identify the version of the software running on a device. If a 210 device publishes many services with rich sets of attributes, the 211 combination may be sufficient to identify the specific device. 213 2.5. Privacy implication of discovering services 215 The consumers of services engage in discovery, and in doing so do 216 reveal some information such as the list of services that they are 217 interested in and the domains in which they are looking for the 218 services. When the clients select specific instances of services, 219 they reveal their preference for these instances. 221 In first analysis, the leakage of information by lients looks benign 222 compared to the disclosures made by the servers. There may be a 223 concern when the client is attempting to use rare services. 225 3. Design of DNS-SD privacy mitigations 227 Ah Ah. 229 3.1. Obfuscated instance names 231 The privacy issues described in Section 2.1 can be solved by 232 obfuscating the instance names. Instead of a user friendly 233 description of the instance, the nodes will publish a random looking 234 string of characters. To prevent tracking over time and location, 235 different string values should be used at different locations, or at 236 different times. 238 Authorized parties should be able to "de-obfuscate" the names, while 239 non-authorized third parties will not be. For example, if both Alice 240 notebook and Bob's laptop use an obfuscation process, the list of 241 available services should appear differently to them and to thrid 242 parties. Alice's phone will be able to de-obfuscate the name of 243 Alice's notebook, but not that of Bob's laptop. Bob's phone will do 244 the opposite. Carol will do neither. 246 Alice will see something like: 248 GobbeldygookBlaBlaBla (Alice's notebook) . local . 249 Abracadabragooklybok . local . 250 Image store for Carol . local . 252 Bob will see: 254 GobbeldygookBlaBlaBla . local . 255 Abracadabragooklybok (Bob's laptop) . local . 256 Image store for Carol . local . 258 Carol will see: 260 GobbeldygookBlaBlaBla . local . 261 Abracadabragooklybok . local . 262 Image store for Carol . local . 264 In that example, Alice, Bob and Carol will be able to select the 265 appropriate instance. It would probably be preferable to filter out 266 the obfuscated instance names, to avoid confusing the user. In our 267 example, Alice and Bob have updated their software to understand 268 obfuscation, and they could easily filter out the obfuscated strings 269 that they do not like. But Carol is not using this system, and we 270 could argue that her experience is suboptimal. 272 The suboptimal experience with unmodified software could be avoided 273 if the obfuscated service records were published using different 274 service names, or using different domain names. This would of course 275 make management a bit more complex, and is thus debatable. 277 3.2. Randomized host names 279 Instead of publishing their actual name in the SRV records, nodes 280 could publish a randomized name. That the solution argued for in 281 [I-D.ietf-intarea-hostname-practice]. 283 Randomized host names will prevent some of the tracking. Host names 284 are typically not visible by the users, and randomizing host names 285 will probably not cause much usability issues. 287 3.3. Timing of obfuscation and randomization 289 It is important that obfuscation of instance names be performed at 290 the right time, and that the obfuscated names change in synchrony 291 with other identifiers, such as MAC Addresses, IP Addresses or host 292 names. If the randomized host name changed but the instance name 293 remained constant, an adversary would have no difficulty linking the 294 old and new host names. Similarly, if IP or MAC addresses changed 295 but host names remained constant, the adversary could link the new 296 addresses to the old ones using the published name. 298 The problem is handled in [I-D.ietf-intarea-hostname-practice], which 299 recommends to pick a new random host name at the time of connecting 300 to a new network. The instance names should be obfuscated at the 301 same time, or maybe use the randomized host name as input in the 302 randomization process. 304 3.4. Fingerprint resistance 306 Difficult... 308 3.5. A note on Private DNS services 310 The DNS Private Exchange working group develops mechanisms to provide 311 confidentiality to DNS transactions, addressing the problems outlined 312 in [RFC7626]. The solutions being developed include DNS over TLS 313 [I-D.ietf-dprive-dns-over-tls] and DNS over DTLS 314 [I-D.ietf-dprive-dnsodtls]. 316 We could imagine that DNS-SD nodes are configure to update and 317 retrieve DNS records using DNS over TLS or DNS over DTLS, but a 318 number of problems can arise: 320 o Discovery queries are scoped by the domain name within which 321 services are published. As nodes move and visit arbitrary 322 networks, there is no guarantee that the domain services for these 323 networks will be accessible using DNS over TLS or DNS over DTLS. 325 o Information placed in the DNS is considered public. Even if the 326 server does support DNS over TLS, third parties will still be able 327 to discover the content of PTR, SRV and TXT records. 329 o Neither DNS over TLS nor DNS over DTLS applies to MDNS. 331 In short, DNS ovr TLS and DNS over DTLS solve a different problem, 332 and are not a solution for DNS-SD privacy. 334 4. Privacy extensions for DNS-SD 336 The proposed solution uses the following components: 338 o The host names are randomized to prevent tracking. 340 o Nodes provide an Instance Discovery Key to other nodes authorized 341 to discover the service instance, 343 o The Instance Discovery Key is combined with a random seed to 344 obfuscate the instance names, 346 o Nodes engaged in discovery attempt to de-obfuscate the instance 347 names using the set of Instance Discovery Key that they know 348 about, 350 These components are detailed in the following subsections. 352 4.1. Randomized Host Name 354 Nodes publishing services with DNS-SD and concerned about their 355 privacy MUST use a randomized host name. The randomized name MUST be 356 changed when network conectivity changes, to avid the correlation 357 issues described in Section 3.3. The randomized host name MUST be 358 used in the SRV records describing the service instance, and the 359 corresponding A or AAAA records MUST be made available through DNS or 360 MDNS, within the same scope as the PTR, SRV and TXT records used by 361 DNS-SD. 363 If the link-layer address of the network connection is properly 364 obfuscated (e.g. using MAC Address Randomization), The Randomized 365 Host Name MAY be computed using the algorithm described in section 366 3.7 of [I-D.ietf-dhc-anonymity-profile]. If this is not possible, 367 the randomized host name SHOULD be constructed by simply picking a 48 368 bit random number meeting the Randomness Requirements for Security 369 expressed in [RFC4075], and then use the hexadecimal representation 370 of this number as the obfuscated host name. 372 4.2. Instance Discovery Key 374 The obfuscation and de-obfuscation of instance names is controlled by 375 the Instance Discovery Key. Each device publishing a service 376 instance configures an Instance Discovery Key associated with the 377 service instance. 379 The Instance Key SHOULD be at least 16 bytes long (128 bits). Its 380 content SHOULD meet the Randomness Requirements for Security 381 expressed in [RFC4075]. 383 4.3. Composing Obfuscated Instance Names 385 The obfuscated instance name is composed of two components, a seed 386 and a hash, encoded in BASE64 ([RFC2045] section 6.8) and separated 387 by a dot: 389 instance_name = "." 391 The seed is derived algorithmically from the randomized host name. 392 If the randomized name changes, new instance names SHOULD be computed 393 and the corresponding records SHOULD be published in order to meet 394 the requirement defined in Section 3.3. 396 The complete instance name MUST be genrated using the following 397 process: 399 long_seed = HASH(randomized_host_name) 400 seed = first 12 bytes of long_seed 401 long_hash = HASH(seed | instance_discovery_key ) 402 instance_hash = first 12 bytes of long_hash 403 instance_name = BASE64(seed) "." BASE64(instance_hash) 405 In this formula, HASH SHOULD be the function SHA256 defined in 406 [RFC4055], unless otherwise specified. Implementers MAY eventually 407 replace SHA256 with a stronger algorithm. 409 The algorithm produces seeds and hash that are encoded as 16 BASE64 410 characters. The resulting instance name is 33 characters long, which 411 fits within the 63 characters limit defined in [RFC6763]. 413 4.4. De-Obfuscation of Instance Names 415 De-obfuscation of instance names assumes that authorized nodes are 416 provisioned with three elements for each discoverable instance: 418 o the de-obfuscated instance name, 420 o a copy of the instance_discovery_key, 422 o optionally, the identifier of the HASH function used by the 423 publisher. 425 A given node may be provisioned do discover many instances. For 426 example, Alice's phone may know about Alice's laptop and Alice's 427 desktop. It might also know of Bob's laptop, if Alice and Bob have 428 agreed to share such information. 430 To de-obfuscate the instance names, nodes performing discovery should 431 obtain the list of PTR records published for the service and domain 432 being searched and then do the following: 434 o Test whether the instance name contains the base64 encoding of a 435 seed and hash as defined in Section 4.3. If it is not in that 436 form, the name is not considered obfuscated. 438 o Retrieve the binary seed and hash from the base64 encoding. 440 o For each known instance discovery key, compute whether the hash of 441 the seed and key, and compare it to the published hash. 443 o If there is a hash, the de-obfuscated name of the instance is the 444 de-obfuscated name associated with the matching instance discovery 445 key 447 5. Security Considerations 449 This document specifies a method to protect the privacy of service 450 publishing nodes. This is especially useful when operating in a 451 public space. Obfuscating the identity of the publishing nodes 452 prevents some forms of "targeting" of high value nodes. 454 Obfuscating the identity of the publishing nodes does not provide any 455 form of access control. It will not prevent attackers from trying to 456 access the services. 458 The cost of the de-obfuscation algorithm scales as the product of the 459 number of authorized publishers known by the client, times the number 460 of obfuscated services published in the searched name domain. 461 Attackers could potentially publish a large number of bogus instances 462 of a service, forcing a high computation cost on discovery clients. 463 While this potential denial of service attack is concerning, we note 464 that this is merely an aggravation of a flooding attacks against DNS- 465 SD. 467 6. IANA Considerations 469 This draft does not require any IANA action. 471 7. Acknowledgments 473 This draft results from initial discussions with Dave Thaler. 475 8. References 477 8.1. Normative References 479 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 480 Extensions (MIME) Part One: Format of Internet Message 481 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 482 . 484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 485 Requirement Levels", BCP 14, RFC 2119, 486 DOI 10.17487/RFC2119, March 1997, 487 . 489 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 490 Algorithms and Identifiers for RSA Cryptography for use in 491 the Internet X.509 Public Key Infrastructure Certificate 492 and Certificate Revocation List (CRL) Profile", RFC 4055, 493 DOI 10.17487/RFC4055, June 2005, 494 . 496 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 497 Configuration Option for DHCPv6", RFC 4075, 498 DOI 10.17487/RFC4075, May 2005, 499 . 501 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 502 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 503 . 505 8.2. Informative References 507 [I-D.ietf-dhc-anonymity-profile] 508 Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 509 profile for DHCP clients", draft-ietf-dhc-anonymity- 510 profile-08 (work in progress), February 2016. 512 [I-D.ietf-dprive-dns-over-tls] 513 Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 514 and P. Hoffman, "Specification for DNS over TLS", draft- 515 ietf-dprive-dns-over-tls-07 (work in progress), March 516 2016. 518 [I-D.ietf-dprive-dnsodtls] 519 Reddy, T., Wing, D., and P. Patil, "DNS over DTLS 520 (DNSoD)", draft-ietf-dprive-dnsodtls-04 (work in 521 progress), January 2016. 523 [I-D.ietf-intarea-hostname-practice] 524 Huitema, C. and D. Thaler, "Current Hostname Practice 525 Considered Harmful", draft-ietf-intarea-hostname- 526 practice-00 (work in progress), October 2015. 528 [RFC1033] Lottor, M., "Domain Administrators Operations Guide", 529 RFC 1033, DOI 10.17487/RFC1033, November 1987, 530 . 532 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 533 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 534 . 536 [RFC1035] Mockapetris, P., "Domain names - implementation and 537 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 538 November 1987, . 540 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 541 specifying the location of services (DNS SRV)", RFC 2782, 542 DOI 10.17487/RFC2782, February 2000, 543 . 545 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 546 DOI 10.17487/RFC6762, February 2013, 547 . 549 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 550 DOI 10.17487/RFC7626, August 2015, 551 . 553 Author's Address 555 Christian Huitema 556 Microsoft 557 Redmond, WA 98052 558 U.S.A. 560 Email: huitema@microsoft.com