idnits 2.17.1 draft-huitema-dnssd-privacy-01.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 pages 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 (June 10, 2016) is 2876 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) -- Looks like a reference, but probably isn't: '4' on line 828 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-25) exists of draft-ietf-dnssd-push-07 == Outdated reference: A later version (-15) exists of draft-ietf-dprive-dnsodtls-06 == Outdated reference: A later version (-05) exists of draft-ietf-intarea-hostname-practice-02 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-13 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 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 D. Kaiser 5 Expires: December 12, 2016 University of Konstanz 6 June 10, 2016 8 Privacy Extensions for DNS-SD 9 draft-huitema-dnssd-privacy-01.txt 11 Abstract 13 DNS-SD allows discovery of services published in DNS or MDNS. The 14 publication normally discloses information about the device 15 publishing the services. There are use cases where devices want to 16 communicate without disclosing their identity, for example two mobile 17 devices visiting the same hotspot. 19 We propose to solve this problem by a two-stage approach. In the 20 first stage, hosts discover Private Discovery Service Instances via 21 DNS-SD using special formats to protect their privacy. These service 22 instances correspond to Private Discovery Servers running on peers. 23 In the second stage, hosts directly query these Private Discovery 24 Servers via DNS-SD over TLS. A pairwise shared secret necessary to 25 establish these connections is only known to hosts authorized by a 26 pairing system. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 12, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Privacy Implications of DNS-SD . . . . . . . . . . . . . . . 4 65 2.1. Privacy Implication of Publishing Service Instance Names 4 66 2.2. Privacy Implication of Publishing Node Names . . . . . . 5 67 2.3. Privacy Implication of Publishing Service Attributes . . 5 68 2.4. Device Fingerprinting . . . . . . . . . . . . . . . . . . 6 69 2.5. Privacy Implication of Discovering Services . . . . . . . 6 70 3. Limits of a Simple Design . . . . . . . . . . . . . . . . . . 7 71 3.1. Obfuscated Instance Names . . . . . . . . . . . . . . . . 7 72 3.2. Names of Obfuscated Services . . . . . . . . . . . . . . 8 73 3.3. Scaling Issues with Obfuscation . . . . . . . . . . . . . 10 74 4. Design of the Private DNS-SD Discovery Service . . . . . . . 11 75 4.1. Device Pairing . . . . . . . . . . . . . . . . . . . . . 11 76 4.1.1. Shared Secret . . . . . . . . . . . . . . . . . . . . 12 77 4.1.2. Secure Authenticated Pairing Channel . . . . . . . . 12 78 4.1.3. Public Authentication Keys . . . . . . . . . . . . . 12 79 4.2. Discovery of the Private Discovery Service . . . . . . . 13 80 4.3. Private Discovery Service . . . . . . . . . . . . . . . . 14 81 4.3.1. A Note on Private DNS Services . . . . . . . . . . . 15 82 4.4. Randomized Host Names . . . . . . . . . . . . . . . . . . 16 83 4.5. Timing of Obfuscation and Randomization . . . . . . . . . 16 84 5. Private Discovery Service Specification . . . . . . . . . . . 16 85 5.1. Host Name Randomization . . . . . . . . . . . . . . . . . 17 86 5.2. Device Pairing . . . . . . . . . . . . . . . . . . . . . 17 87 5.3. Private Discovery Server . . . . . . . . . . . . . . . . 18 88 5.3.1. Establishing TLS Connections . . . . . . . . . . . . 18 89 5.4. Publishing Private Discovery Service Instances . . . . . 19 90 5.5. Discovering Private Discovery Service Instances . . . . . 19 91 5.6. Using the Private Discovery Service . . . . . . . . . . . 20 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 93 6.1. Attacks Against the Pairing System . . . . . . . . . . . 21 94 6.2. Denial of Discovery of the Private Discovery Service . . 21 95 6.3. Replay Attacks Against Discovery of the Private Discovery 96 Service . . . . . . . . . . . . . . . . . . . . . . . . . 22 97 6.4. Denial of Private Discovery Service . . . . . . . . . . . 22 98 6.5. Replay Attacks against the Private Discovery Service . . 22 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 100 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 101 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 102 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 103 9.2. Informative References . . . . . . . . . . . . . . . . . 24 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 106 1. Introduction 108 DNS-SD [RFC6763] enables distribution and discovery in local networks 109 without configuration. It is very convenient for users, but it 110 requires the public exposure of the offering and requesting 111 identities along with information about the offered and requested 112 services. Some of the information published by the announcements can 113 be very revealing. These privacy issues and potential solutions are 114 discussed in [KW14a] and [KW14b]. 116 There are cases when nodes connected to a network want to provide or 117 consume services without exposing their identity to the other parties 118 connected to the same network. Consider for example a traveler 119 wanting to upload pictures from a phone to a laptop when connected to 120 the Wi-Fi network of an Internet cafe, or two travelers who want to 121 share files between their laptops when waiting for their plane in an 122 airport lounge. 124 We expect that these exchanges will start with a discovery procedure 125 using DNS-SD [RFC6763]. One of the devices will publish the 126 availability of a service, such as a picture library or a file store 127 in our examples. The user of the other device will discover this 128 service, and then connect to it. 130 When analyzing these scenarios in Section 2, we find that the DNS-SD 131 messages leak identifying information such as instance name, host 132 name or service properties. We review the design constraint of a 133 solution in Section 4, and describe the proposed solution in 134 Section 5. 136 1.1. Requirements 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 2. Privacy Implications of DNS-SD 144 DNS-Based Service Discovery (DNS-SD) is defined in [RFC6763]. It 145 allows nodes to publish the availability of an instance of a service 146 by inserting specific records in the DNS ([RFC1033], [RFC1034], 147 [RFC1035]) or by publishing these records locally using multicast DNS 148 (mDNS) [RFC6762]. Available services are described using three types 149 of records: 151 PTR Record: Associates a service type in the domain with an 152 "instance" name of this service type. 154 SRV Record: Provides the node name, port number, priority and weight 155 associated with the service instance, in conformance with 156 [RFC2782]. 158 TXT Record: Provides a set of attribute-value pairs describing 159 specific properties of the service instance. 161 In the remaining subsections, we will review the privacy issues 162 related to publishing instance names, node names, service attributes 163 and other data, as well as review the implications of using the 164 discovery service as a client. 166 2.1. Privacy Implication of Publishing Service Instance Names 168 In the first phase of discovery, the client obtains all the PTR 169 records associated with a service type in a given naming domain. 170 Each PTR record contains a Service Instance Name defined in Section 4 171 of [RFC6763]: 173 Service Instance Name = . . 175 The portion of the Service Instance Name is meant to 176 convey enough information for users of discovery clients to easily 177 select the desired service instance. Nodes that use DNS-SD over mDNS 178 [RFC6762] in a mobile environment will rely on the specificity of the 179 instance name to identify the desired service instance. In our 180 example of users wanting to upload pictures to a laptop in an 181 Internet Cafe, the list of available service instances may look like: 183 Alice's Images . _imageStore._tcp . local 184 Alice's Mobile Phone . _presence._tcp . local 185 Alice's Notebook . _presence._tcp . local 186 Bob's Notebook . _presence._tcp . local 187 Carol's Notebook . _presence._tcp . local 188 Alice will see the list on her phone and understand intuitively that 189 she should pick the first item. The discovery will "just work". 191 However, DNS-SD/mDNS will reveal to anybody that Alice is currently 192 visiting the Internet Cafe. It further discloses the fact that she 193 uses two devices, shares an image store, and uses a chat application 194 supporting the _presence protocol on both of her devices. She might 195 currently chat with Bob or Carol, as they are also using a _presence 196 supporting chat application. This information is not just available 197 to devices actively browsing for and offering services, but to 198 anybody passively listing to the network traffic. 200 2.2. Privacy Implication of Publishing Node Names 202 The SRV records contain the DNS name of the node publishing the 203 service. Typical implementations construct this DNS name by 204 concatenating the "host name" of the node with the name of the local 205 domain. The privacy implications of this practice are reviewed in 206 [I-D.ietf-intarea-hostname-practice]. Depending on naming practices, 207 the host name is either a strong identifier of the device, or at a 208 minimum a partial identifier. It enables tracking of the device, and 209 by extension of the device's owner. 211 2.3. Privacy Implication of Publishing Service Attributes 213 The TXT record's attribute and value pairs contain information on the 214 characteristics of the corresponding service instance. This in turn 215 reveals information about the devices that publish services. The 216 amount of information varies widely with the particular service and 217 its implementation: 219 o Some attributes like the paper size available in a printer, are 220 the same on many devices, and thus only provide limited 221 information to a tracker. 223 o Attributes that have freeform values, such as the name of a 224 directory, may reveal much more information. 226 Combinations of attributes have more information power than specific 227 attributes, and can potentially be used for "fingerprinting" a 228 specific device. 230 Information contained in TXT records does not only breach privacy by 231 making devices trackable, but might directly contain private 232 information about a device user. For instance the _presence service 233 reveals the "chat status" to everyone in the same network. Users 234 might not be aware of that. 236 Further, TXT records often contain version information about services 237 allowing potential attackers to identify devices running exploit- 238 prone versions of a certain service. 240 2.4. Device Fingerprinting 242 The combination of information published in DNS-SD has the potential 243 to provide a "fingerprint" of a specific device. Such information 244 includes: 246 o The list of services published by the device, which can be 247 retrieved because the SRV records will point to the same host 248 name. 250 o The specific attributes describing these services. 252 o The port numbers used by the services. 254 o The values of the priority and weight attributes in the SRV 255 records. 257 This combination of services and attributes will often be sufficient 258 to identify the version of the software running on a device. If a 259 device publishes many services with rich sets of attributes, the 260 combination may be sufficient to identify the specific device. 262 There is however an argument that devices providing services can be 263 discovered by observing the local traffic, because different services 264 have different traffic patterns. The observation could in many cases 265 also reveal some specificities of the service's implementation. Even 266 if the traffic is encrypted, the size and the timing of packets may 267 be sufficient to reveal that information. This argument can be used 268 to assess the priority of, for example, protecting the fact that a 269 device publishes a particular service. However, we may assume that 270 the developers of sensitive services will use counter-measures to 271 defeat such traffic analysis. 273 2.5. Privacy Implication of Discovering Services 275 The consumers of services engage in discovery, and in doing so reveal 276 some information such as the list of services they are interested in 277 and the domains in which they are looking for the services. When the 278 clients select specific instances of services, they reveal their 279 preference for these instances. This can be benign if the service 280 type is very common, but it could be more problematic for sensitive 281 services, such as for example some private messaging services. 283 One way to protect clients would be to somehow encrypt the requested 284 service types. Of course, just as we noted in Section 2.4, traffic 285 analysis can often reveal the service. 287 3. Limits of a Simple Design 289 We first tried a simple design for mitigating the issues outlined in 290 Section 2. The basic idea was to advertise obfuscated names, so as 291 to not reveal the particularities of the service providers. This 292 design is tempting, because it only requires minimal changes in the 293 DNS-SD processing. However, as we will see in the following 294 subsections, it has two important drawbacks: 296 o The simple design leads to UI issues, because users of unmodified 297 DNS-SD agents will see a mix of clear text names and obfuscated 298 names, which is unpleasant. 300 o With this simple design, there is no good way to hide the type of 301 services provided or consumed by a specific node. 303 o The simple design either requires having a shared key between all 304 "authorized users" of a service, which implies substandard key 305 management practices, or publishing as many instances of a service 306 as there are authorized users, which leads to the scaling issues 307 discussed in Section 3.3. 309 Both issues are mitigated by the two-stage design presented in 310 Section 4. The following subsections detail the simple design, and 311 its drawbacks. 313 3.1. Obfuscated Instance Names 315 The privacy issues described in Section 2.1 could be solved by 316 obfuscating the instance names. Instead of a user friendly 317 description of the instance, the nodes would publish a random looking 318 string of characters. To prevent tracking over time and location, 319 different string values would be used at different locations, or at 320 different times. 322 Authorized parties have to be able to "de-obfuscate" the names, while 323 non-authorized third parties will not be. For example, if both 324 Alice's notebook and Bob's laptop use an obfuscation process, the 325 list of available services should appear differently to them and to 326 third parties. Alice's phone will be able to de-obfuscate the name 327 of Alice's notebook, but not that of Bob's laptop. Bob's phone will 328 do the opposite. Carol will do neither. 330 Alice will see something like: 332 QwertyUiopAsdfghjk (Alice's Images) . _imageStore._tcp . local 333 GobbeldygookBlaBla (Alice's Mobile Phone) . _presence._tcp . local 334 MNbvCxzLkjhGfdEdhg (Alice's Notebook) . _presence._tcp . local 335 Abracadabragooklybok (Bob's Notebook) . _presence._tcp . local 336 Carol's Notebook . _presence._tcp . local 338 Bob will see: 340 QwertyUiopAsdfghjk . _imageStore._tcp . local 341 GobbeldygookBlaBla . _presence._tcp . local 342 MNbvCxzLkjhGfdEdhg . _presence._tcp . local 343 Abracadabragooklybok (Bob's Notebook) . _presence._tcp . local 344 Carol's Notebook . _presence._tcp . local 346 Carol will see: 348 QwertyUiopAsdfghjk . _imageStore._tcp . local 349 GobbeldygookBlaBla . _presence._tcp . local 350 MNbvCxzLkjhGfdEdhg . _presence._tcp . local 351 Abracadabragooklybok . _presence._tcp . local 352 Carol's Notebook . _presence._tcp . local 354 In that example, Alice, Bob and Carol will be able to select the 355 appropriate instance. It would probably be preferable to filter out 356 the obfuscated instance names, to avoid confusing the user. In our 357 example, Alice and Bob have updated their software to understand 358 obfuscation, and they could easily filter out the obfuscated strings 359 that they do not like. But Carol is not using this system, and we 360 could argue that her experience is suboptimal. 362 3.2. Names of Obfuscated Services 364 Instead of publishing the actual service name in the SRV records, 365 nodes could publish a randomized name. There are two plausible 366 reasons for doing that: 368 o Having a different service name for privacy enhanced services will 369 ensure that hosts that are not privacy aware are not puzzled by 370 obfuscated service names. 372 o Using obfuscated service names prevents third parties from 373 discovering which service a particular host is providing or 374 consuming. 376 The first requirement can be met with a simple modification of an 377 existing name. For example, instead of publishing: 379 QwertyUiopAsdfghjk . _imageStore._tcp . local 380 GobbeldygookBlaBla . _presence._tcp . local 382 Alice could publish some kind of "translation" of the service name, 383 such as: 385 QwertyUiopAsdfghjk . _vzntrFgber._tcp . local 386 GobbeldygookBlaBla . _cerfrapr._tcp . local 388 The previous examples use rot13 translation. It does not provide any 389 particular privacy, but it does ensure that obfuscated services are 390 named differently from clear text services. 392 Making the service name actually private would require some actual 393 encryption. The main problem with such solutions is that the client 394 needs to know the service name in order to compose the DNS-SD query 395 for services. There are several options: 397 o The service name is chosen by the client. For example, the client 398 could encrypt the original service name and a nonce with a key 399 shared between client and server. Upon receiving the queries, the 400 server would attempt to decrypt the service name. If that 401 succeeds, the server would respond with PTR records created on the 402 fly for the new service name. 404 o The service name is chosen by the server and cannot be predicted 405 in advance by the client. For example, the server could encrypt a 406 nonce and the original service name. The client retrieves such 407 services by doing a wild card query, then attempting to decrypt 408 the received responses. 410 o The service name is chosen by the server in a way that can be 411 predicted in advance by the client. For example, the server could 412 encrypt some version of the data and time and the original service 413 name. The data and time are encoded with a coarse precision, 414 enabling the client to predict the value that the server is using, 415 and to send the corresponding queries. 417 None of these solutions is very attractive. Creating records on the 418 fly is a burden for the server. If clients must use wildcard 419 queries, they will need to process lots of irrelevant data. If 420 clients need to predict different instance names for each potential 421 server, they will end up sending batches of queries with many 422 different names. All of these solutions appear like big departures 423 from the simplicity and robustness of the DNS-SD design. 425 3.3. Scaling Issues with Obfuscation 427 In Section 3.1, we assumed that each advertised record contains a 428 name obfuscated with a shared key. This approach is easy to 429 understand, but it contains hidden assumptions. Let's look at one of 430 our examples: 432 Abracadabragooklybok (Bob's Notebook) . _presence._tcp . local 434 We only see one record for Bob's Notebook, obfuscated using the 435 unique shared secret associated with Bob's Notebook. That means that 436 every device paired with Bob's Notebook will have a copy of that 437 shared secret. This is a possible solution, but there are known 438 issues with having a secret shared with multiple entities: 440 o If for some reason the secret needs to be changed, every paired 441 device will need a copy of the new secret before it can 442 participate again in discovery. 444 o If one of the previous pairings becomes invalid, the only way to 445 block the corresponding devices from discovery is to change the 446 secret for all other devices. 448 Key management becomes much easier if it is strictly pair-wise. Two 449 paired devices, or to pairs of users, can simply renew their pairing 450 and get a new secret. If a device ceases to be trusted, the pairing 451 data and the corresponding secret can just be deleted and forgotten. 452 But using strictly pair-wise keys yields a scaling issue. Let's 453 assume that: 455 o Each device maintains an average of N pairings. 457 o There are on average M devices present during discovery. 459 In the single key scenario, after issuing a broadcast query, the 460 querier will receive a series of responses, each of which may well be 461 obfuscated with a different key. If the receiver has N pre-existing 462 pairings and receives M obfuscated responses, the cost will scale as 463 O(M*N), i.e. try all N pairing keys for each of the M responses to 464 see what matches. But if the keys are specific to each pair of 465 devices, the obfuscation becomes complicated. When receiving a 466 request, the publisher does not know which of its N keys the querier 467 can decrypt. One simple solution would be to send N responses, but 468 then the load on the querier will scale as O(M*N^2). That can go out 469 of hand very quickly. 471 To solve the scaling issue, we consider a two-stage solution that 472 uses an optimized discovery procedure to discover privacy-compatible 473 devices; and uses point to point encrypted exchanges to privately 474 discover the available services. 476 4. Design of the Private DNS-SD Discovery Service 478 In this section, we present the design of a two-stage solution that 479 enables private use of DNS-SD, without affecting existing users, and 480 with better scalability than the simple solution presented in 481 Section 3. The solution is largely based on the architecture 482 proposed in [KW14b], which separates the general private discovery 483 problems in three components: Pairing, discovery of a private 484 discovery service, and actual service discovery through this private 485 service. Pairing has to provide the private discovery servers with 486 means for mutual authentication, e.g. with an authenticated shared 487 secret. The private discovery servers provide actual service 488 discovery with an authenticated connection. Our solution applies 489 this architecture in the context of DNS-SD. It is based on the 490 following components: 492 o Adding a pairing system to DNS-SD, described in Section 4.1, 493 through which authorized peers can establish shared secrets; 495 o Defining the Private Discovery Service through which other 496 services can be advertised in a private manner; 498 o And, publishing availability of the Private Discovery Service 499 using DNS-SD, so that peers can discover their services without 500 compromising their privacy. 502 These are independent with respect to means used for transmitting the 503 necessary data. 505 4.1. Device Pairing 507 Any private discovery solution needs to differentiate between 508 authorized devices, which are allowed to get information about 509 discoverable entities, and other devices, which should not be aware 510 of the availability of private entities. The commonly used solution 511 to this problem is establishing a "device pairing". In our discovery 512 scenarios, we envisage two kinds of pairings: 514 1. Inter-user pairing is a pairing between devices of "friends". 515 Since it has to be performed manually, e.g. by the means 516 described above, it is important to limit it to once per pair of 517 friends. 519 2. Intra-user pairing is a pairing of devices of the same user. It 520 can be performed without any configuration by a meta-service 521 (pairing data synchronization service) in a trusted (home) 522 network. 524 The result of the pairing will be a shared secret, and optionally 525 mutually authenticated public keys added to a local web of trust. 526 Public key technology has many advantages, but shared secrets are 527 typically easier to handle on small devices. We offer both a simple 528 pairing just exchanging a shared secret, and an authenticated pairing 529 using public key technology. 531 4.1.1. Shared Secret 533 Goal of the pairing process is establishing pairwise shared secrets. 534 If two users can leverage a secure private off-channel, it suffices 535 for one user to generate the shared secret and transmit it over this 536 off-channel. It would be possible for the users to meet and orally 537 agree on a password that both users enter in their devices. This has 538 the disadvantage of user-chosen passwords to have low entropy and the 539 inconvenience of having to type the password. Leveraging QR-codes 540 can overcome these disadvantages: one user generates a shared secret, 541 displays it in form of a QR-code, and the other user scans this code. 542 Strictly speaking, displaying and scanning QR-codes does not 543 establish a secure private channel, as others could also photograph 544 this code; but it is reasonable secure for the application area of 545 private service discovery. Using Bluetooth LE might also be 546 considered satisfactory as a compromise between convenience and 547 security. 549 4.1.2. Secure Authenticated Pairing Channel 551 Optionally, various versions of authenticated DH can be used to 552 exchange a mutually authenticated shared secret (which among other 553 possibilities can leverage QR-codes for key fingerprint 554 verification). Using DH gives the benefit of provable security and 555 the possibility to perform a pairing when not being able to meet in 556 person. Further, using DH to generate the shared secret has the 557 advantage of both parties contributing to the shared secret 558 (multiparty computation). 560 4.1.3. Public Authentication Keys 562 The public/private key pair - if at all - is just used for the 563 aforementioned authenticated DH to grant a mutually authenticated 564 shared secret. Obtaining and verifying a friend's public key can be 565 achieved by different means. For obtaining the keys, we can either 566 leverage an existing PKI, e.g. the PGP web of trust, or generate our 567 own key pairs (and exchange them right before verifying). For 568 authenticating the keys, which boils down to comparing fingerprints 569 on an off-channel, we distinguish between means that demand users to 570 be in close proximity of each other, and means where users do not 571 have to meet in person. The former can e.g. be realized by verifying 572 a fingerprint leveraging QR-Codes, the latter by reading a 573 fingerprint during a phone call or using the socialist millionaires 574 protocol. 576 4.2. Discovery of the Private Discovery Service 578 The first stage of service discovery is to check whether instances of 579 compatible Private Discovery Services are available in the local 580 scope. The goal of that stage is to identify devices that share a 581 pairing with the querier, and are available locally. The service 582 instances can be discovered using regular DNS-SD procedures, but the 583 list of discovered services will have to be filtered so only paired 584 devices are retained. 586 We have demonstrated in Section 3.3 that simple obfuscation would 587 require publishing as many records per publisher as there are 588 pairings, which ends up scaling as O(M*N^2) in which M is the number 589 of devices present and N is the number of pairings per device. We 590 can mitigate this problem by using a special encoding of the instance 591 name. Suppose that the publisher manages N pairings with the 592 associated keys K1, K2, ... Kn. The instance name will be set to an 593 encoding of N "proofs" of the N keys, where each proof is computed as 594 function of the key and a nonce: 596 instance name = .. 598 Fi = hash (nonce, Ki), where hash is a cryptographic hash 599 function. 601 The querier can test the instance name by computing the same "proof" 602 for each of its own keys. Suppose that the receiver manages P 603 pairings, with the corresponding keys X1, X2, .. Xp. The receiver 604 verification procedure will be: 606 for each received instance name: 607 retrieve nonce from instance name 608 for (j = 1 to P) 609 retrieve the key Xj of pairing number j 610 compute F = hash(nonce, Xj) 611 for (i=1 to N) 612 retrieve the proof Fi 613 if F is equal to Fi 614 mark the pairing number j as available 616 The procedure presented here requires on average O(M*N) iterations of 617 the hash function, which is the same scaling as the "shared secret" 618 variant. It requires O(M*N^2) comparison operations, but these are 619 less onerous than cryptographic operations. Further, when setting 620 the nonce to a timestamp, the Fi have to be calculated only once per 621 time interval. 623 The number of pairing proofs that can be encoded in a single record 624 is limited by the maximum size of a DNS label, which is 63 bytes. 625 Since this are characters and not pure binary values, nonce and 626 proofs will have to be encoded using BASE64 ([RFC2045] section 6.8), 627 resulting in at most 378 bits. The nonce should not be repeated, and 628 the simplest way to achieve that is to set the nonce to a 32 bit 629 timestamp value. The remaining 346 bits could encode up to 10 proofs 630 of 32 bits each, which would be sufficient for many practical 631 scenarios. 633 In practice, a 32 bit proof should be sufficient to distinguish 634 between available devices. However, there is clearly a risk of 635 collision. The Private Discovery Service as described here will find 636 the available pairings, but it might also find a spurious number of 637 "false positives." The chances of that happening are however quite 638 small: less than 0.02% for a device managing 10 pairings and 639 processing 10000 responses. 641 4.3. Private Discovery Service 643 The Private Discovery Service discovery allows discovering a list of 644 available paired devices, and verifying that either party knows the 645 corresponding shared secret. At that point, the querier can engage 646 in a series of directed discoveries. 648 We have considered defining an ad-hoc protocol for the private 649 discovery service, but found that just using TLS would be much 650 simpler. The Directed Private Discovery service is just a regular 651 DNS-SD service, accessed over TLS, using the encapsulation of DNS 652 over TLS defined in [RFC7858]. The main difference with simple DNS 653 over TLS is the need for authentication. 655 We assume that the pairing process has provided each pair of 656 authorized client and server with a shared secret. We can use that 657 shared secret to provide mutual authentication of clients and servers 658 using "Pre Shared Key" authentication, as defined in [RFC4279] and 659 incorporated in the latest version of TLS [I-D.ietf-tls-tls13]. 661 One difficulty is the reliance on a key identifier in the protocol. 662 For example, in TLS 1.3 the PSK extension is defined as: 664 opaque psk_identity<0..2^16-1>; 666 struct { 667 select (Role) { 668 case client: 669 psk_identity identities<2..2^16-1>; 671 case server: 672 uint16 selected_identity; 673 } 674 } PreSharedKeyExtension 676 According to the protocol, the PSK identity is passed in clear text 677 at the beginning of the key exchange. This is logical, since server 678 and clients need to identify the secret that will be used to protect 679 the connection. But if we used a static identifier for the key, 680 adversaries could use that identifier to track server and clients. 681 The solution is to use a time-varying identifier, constructed exactly 682 like the "hint" described in Section 4.2, by concatenating a nonce 683 and the hash of the nonce with the shared secret. 685 4.3.1. A Note on Private DNS Services 687 Our solution uses a variant of the DNS over TLS protocol [RFC7858] 688 defined by the DNS Private Exchange working group (DPRIVE). DPRIVE 689 is also working on an UDP variant, DNS over DTLS 690 [I-D.ietf-dprive-dnsodtls], which would also be a candidate. 692 DPRIVE and Private Discovery solve however two somewhat different 693 problems. DPRIVE is concerned with the confidentiality to DNS 694 transactions, addressing the problems outlined in [RFC7626]. 695 However, DPRIVE does not address the confidentiality or privacy 696 issues with publication of services, and is not a direct solution to 697 DNS-SD privacy: 699 o Discovery queries are scoped by the domain name within which 700 services are published. As nodes move and visit arbitrary 701 networks, there is no guarantee that the domain services for these 702 networks will be accessible using DNS over TLS or DNS over DTLS. 704 o Information placed in the DNS is considered public. Even if the 705 server does support DNS over TLS, third parties will still be able 706 to discover the content of PTR, SRV and TXT records. 708 o Neither DNS over TLS nor DNS over DTLS applies to MDNS. 710 In contrast, we propose using mutual authentication of the client and 711 server as part of the TLS solution, to ensure that only authorized 712 parties learn the presence of a service. 714 4.4. Randomized Host Names 716 Instead of publishing their actual name in the SRV records, nodes 717 could publish a randomized name. That is the solution argued for in 718 [I-D.ietf-intarea-hostname-practice]. 720 Randomized host names will prevent some of the tracking. Host names 721 are typically not visible by the users, and randomizing host names 722 will probably not cause much usability issues. 724 4.5. Timing of Obfuscation and Randomization 726 It is important that the obfuscation of instance names is performed 727 at the right time, and that the obfuscated names change in synchrony 728 with other identifiers, such as MAC Addresses, IP Addresses or host 729 names. If the randomized host name changed but the instance name 730 remained constant, an adversary would have no difficulty linking the 731 old and new host names. Similarly, if IP or MAC addresses changed 732 but host names remained constant, the adversary could link the new 733 addresses to the old ones using the published name. 735 The problem is handled in [I-D.ietf-intarea-hostname-practice], which 736 recommends to pick a new random host name at the time of connecting 737 to a new network. New instance names for the Private Discovery 738 Services should be composed at the same time. 740 5. Private Discovery Service Specification 742 The proposed solution uses the following components: 744 o Host name randomization to prevent tracking. 746 o Device pairing yielding pairwise shared secrets. 748 o A Private Discovery Server (PDS) running on each host. 750 o Discovery of the PDS instances using DNS-SD. 752 These components are detailed in the following subsections. 754 5.1. Host Name Randomization 756 Nodes publishing services with DNS-SD and concerned about their 757 privacy MUST use a randomized host name. The randomized name MUST be 758 changed when network connectivity changes, to avoid the correlation 759 issues described in Section 4.5. The randomized host name MUST be 760 used in the SRV records describing the service instance, and the 761 corresponding A or AAAA records MUST be made available through DNS or 762 MDNS, within the same scope as the PTR, SRV and TXT records used by 763 DNS-SD. 765 If the link-layer address of the network connection is properly 766 obfuscated (e.g. using MAC Address Randomization), The Randomized 767 Host Name MAY be computed using the algorithm described in section 768 3.7 of [RFC7844]. If this is not possible, the randomized host name 769 SHOULD be constructed by simply picking a 48 bit random number 770 meeting the Randomness Requirements for Security expressed in 771 [RFC4075], and then use the hexadecimal representation of this number 772 as the obfuscated host name. 774 5.2. Device Pairing 776 Nodes that want to leverage the Private Directory Service for private 777 service discovery among peers MUST share a secret with each of these 778 peers. The shared secret MUST be a 256 bit randomly chosen number. 779 The secret SHOULD be exchanged via device Pairing. The pairing 780 process SHALL establish a mutually authenticated secure channel to 781 perform the shared secret exchange. It is RECOMMENDED for both 782 parties to contribute to the shared secret, e.g. by using a Diffie- 783 Hellman key exchange. 785 TODO: need to define the pairing service, or API. The API approach 786 assumes that pairing is outside our scope, and is done using BT-LE, 787 or any other existing mechanism. This is a bit of a cope-out. We 788 could also define a pairing system that just sets the pairing with 789 equivalent security as the "push button" or "PIN" solutions used for 790 BT or Wi-Fi. And we could at this stage leverage a pre-existing 791 security association, e.g. PGP identities or other certificates. If 792 we do that, we should probably dedicate a top level section to 793 specifying the minimal pairing service. Using a pre-existing 794 asymmetric security association, we can use a key exchange similar to 795 IKEv2 (RFC 7296). IKEv2 leverages the SIGMA protocols, which provide 796 various methods of authenticated DH. It would also be possible to 797 authenticate DH using symmetric passwords (e.g. Bellovin-Merritt). 799 5.3. Private Discovery Server 801 A Private Discovery Server (PDS) is a minimal DNS server running on 802 each host. Its task is to offer resource records corresponding to 803 private services only to authorized peers. These peers MUST share a 804 secret with the host (see Section 5.2). To ensure privacy of the 805 requests, the service is only available over TLS [RFC5246], and the 806 shared secrets are used to mutually authenticate peers and servers. 808 The Private Name Server SHOULD support DNS push notifications 809 [I-D.ietf-dnssd-push], e.g. to facilitate an up-to-date contact list 810 in a chat application without polling. 812 5.3.1. Establishing TLS Connections 814 The PDS MUST only answer queries via DNS over TLS [RFC7858] and MUST 815 use a PSK authenticated TLS handshake [RFC4279]. The client and 816 server should negotiate a forward secure cypher suite such as DHE-PSK 817 or ECDHE-PSK when available. The shared secret exchanged during 818 pairing MUST be used as PSK. 820 When using the PSK based authentication, the "psk_identity" parameter 821 identifying the pre-shared key MUST be composed as follow, using the 822 conventions of TLS [RFC7858]: 824 struct { 826 uint32 gmt_unix_time; 828 opaque random_bytes[4]; 830 } nonce; 832 long_proof = HASH(nonce | pairing_key ) 833 proof = first 12 bytes of long_proof 834 psk_identity = BASE64(nonce) "." BASE64(proof) 836 In this formula, HASH SHOULD be the function SHA256 defined in 837 [RFC4055]. Implementers MAY eventually replace SHA256 with a 838 stronger algorithm, in which cases both clients and servers will have 839 to agree on that algorithm during the pairing process. The first 32 840 bits of the nonce are set to the current time and date in standard 841 UNIX 32-bit format (seconds since the midnight starting Jan 1, 1970, 842 UTC, ignoring leap seconds) according to the client's internal clock. 843 The next 32 bits of the nonce are set to a value generated by a 844 secure random generator. 846 In this formula, the identity is finally set to a character string, 847 using BASE64 ([RFC2045] section 6.8). This transformation is meant 848 to comply with the PSK identity encoding rules specified in section 849 5.1 of [RFC4279]. 851 The server will check the received key identity, trying the key 852 against the valid keys established through pairing. If one of the 853 key matches, the TLS connection is accepted, otherwise it is 854 declined. 856 5.4. Publishing Private Discovery Service Instances 858 Nodes that provide the Private Discovery Service SHOULD advertise 859 their availability by publishing instances of the service through 860 DNS-SD. 862 The DNS-SD service type for the Private Discovery Service is 863 "_pds._tls". 865 Each published instance describes one server and up to 10 pairings. 866 In the case where a node manages more than 10 pairings, it should 867 publish as many instances as necessary to advertise all available 868 pairings. 870 Each instance name is composed as follows: 872 pick a 32 bit nonce, e.g. using the Unix GMT time. 873 set the binary identifier to the nonce. 875 for each of up to 10 pairings 876 hint = first 32 bits of HASH(|) 877 concatenate the hint to the binary identifier 879 set instance-ID = BASE64(binary identifier) 881 In this formula, HASH SHOULD be the function SHA256 defined in 882 [RFC4055], and BASE64 is defined in section 6.8 of [RFC2045]. The 883 concatenation of a 32 bit nonce and up to 10 pairing hints result a 884 bit string at most 332 bit long. The BASE64 conversion will produce 885 a string that is up to 59 characters long, which fits within the 63 886 characters limit defined in [RFC6763]. 888 5.5. Discovering Private Discovery Service Instances 890 Nodes that wish to discover Private Discovery Service Instances will 891 issue a DNS-SD discovery request for the service type. These request 892 will return a series of PTR records, providing the names of the 893 instances present in the scope. 895 The querier SHOULD examine each instance to see whether it hints at 896 one of its available pairings, according to the following conceptual 897 algorithm: 899 for each received instance name: 900 convert the instance name to binary using BASE64 901 if the conversion fails, 902 discard the instance. 903 if the binary instance length is a not multiple of 32 bits, 904 discard the instance. 906 nonce = first 32 bits of binary. 907 for each 32 bit hint after the nonce 908 for each available pairing 909 retrieve the key Xj of pairing number j 910 compute F = hash(nonce, Xj) 911 if F is equal to the 32 bit hint 912 mark the pairing number j as available 914 Once a pairing has been marked available, the querier SHOULD try 915 connecting to the corresponding instance, using the selected key. 916 The connection is likely to succeed, but it MAY fail for a variety of 917 reasons. One of these reasons is the probabilistic nature of the 918 hint, which entails a small chance of "false positive" match. This 919 will occur if the hash of the nonce with two different keys produces 920 the same result. In that case, the TLS connection will fail with an 921 authentication error or a decryption error. 923 5.6. Using the Private Discovery Service 925 Once instances of the Private Discovery Service have been discovered, 926 peers can establish TLS connections and send DNS requests over these 927 connections, as specified in DNS-SD. 929 6. Security Considerations 931 This document specifies a method to protect the privacy of service 932 publishing nodes. This is especially useful when operating in a 933 public space. Hiding the identity of the publishing nodes prevents 934 some forms of "targeting" of high value nodes. However, adversaries 935 can attempt various attacks to break the anonymity of the service, or 936 to deny it. A list of these attacks and their mitigations are 937 described in the following sections. 939 6.1. Attacks Against the Pairing System 941 There are a variety of attacks against pairing systems. They may 942 result in compromised pairing keys. If an adversary manages to 943 acquire a compromised key, the adversary will be able to perform 944 private service discovery according to Section 5.5. This will allow 945 tracking of the service. The adversary will also be able to discover 946 which private services are available for the compromised pairing. 948 To mitigate such attacks, nodes MUST be able to quickly revoke a 949 compromised pairing. This is however not sufficient, as the 950 compromise of the pairing key could remain undetected for a long 951 time. For further safety, nodes SHOULD assign a time limit to the 952 validity of pairings, discard the corresponding keys when the time 953 has passed, and establish new pairings. 955 This later requirement of limiting the Time-To-Live can raise doubts 956 about the usability of the protocol. The usability issues would be 957 mitigated if the initial pairing provided both a shared secret and 958 the means to renew that secret over time, e.g. using authenticated 959 public keys. 961 6.2. Denial of Discovery of the Private Discovery Service 963 The algorithm described in Section 5.5 scales as O(M*N), where M is 964 the number of pairing per nodes and N is the number of nodes in the 965 local scope. Adversaries can attack this service by publishing 966 "fake" instances, effectively increasing the number N in that scaling 967 equation. 969 Similar attacks can be mounted against DNS-SD: creating fake 970 instances will generally increase the noise in the system and make 971 discovery less usable. Private Discovery Service discovery SHOULD 972 use the same mitigations as DNS-SD. 974 The attack is amplified because the clients need to compute proofs 975 for all the nonces presented in Private Discovery Service Instance 976 names. One possible mitigation would be to require that such nonces 977 correspond to rounded timestamps. If we assume that timestamps must 978 not be too old, there will be a finite number of valid rounded 979 timestamps at any time. Even if there are many instances present, 980 they would all pick their nonces from this small number of rounded 981 timestamps, and a smart client could make sure that proofs are only 982 computed once per valid time stamp. 984 6.3. Replay Attacks Against Discovery of the Private Discovery Service 986 Adversaries can record the service instance names published by 987 Private Discovery Service instances, and replay them later in 988 different contexts. Peers engaging in discovery can be misled into 989 believing that a paired server is present. They will attempt to 990 connect to the absent peer, and in doing so will disclose their 991 presence in a monitored scope. 993 The binary instance identifiers defined in Section 5.4 start with 32 994 bits encoding the "UNIX" time. In order to protect against replay 995 attacks, clients MAY verify that this time is reasonably recent. 997 TODO: should we somehow encode the scope in the identifier? Having 998 both scope and time would really mitigate that attack. 1000 6.4. Denial of Private Discovery Service 1002 The Private Discovery Service is only available through a mutually 1003 authenticated TLS connection, which provides good protections. 1004 However, adversaries can mount a denial of service attack against the 1005 service. In the absence of shared secrets, the connections will 1006 fail, but the servers will expend some CPU cycles defending against 1007 them. 1009 To mitigate such attacks, nodes SHOULD restrict the range of network 1010 addresses from which they accept connections, matching the expected 1011 scope of the service. 1013 This mitigation will not prevent denial of service attacks performed 1014 by locally connected adversaries; but protecting against local denial 1015 of service attacks is generally very difficult. For example, local 1016 attackers can also attack mDNS and DNS-SD by generating a large 1017 number of multicast requests. 1019 6.5. Replay Attacks against the Private Discovery Service 1021 Adversaries may record the PSK Key Identifiers used in successful 1022 connections to a private discovery service. They could attempt to 1023 replay them later against nodes advertising the private service at 1024 other times or at other locations. If the PSK Identifier is still 1025 valid, the server will accept the TLS connection, and in doing so 1026 will reveal being the same server observed at a previous time or 1027 location. 1029 The PSK identifiers defined in Section 5.3.1 start with 32 bits 1030 encoding the "UNIX" time. In order to mitigate replay attacks, 1031 servers SHOULD verify that this time is reasonably recent, and fail 1032 the connection if it is too old, or if it occurs too far in the 1033 future. 1035 The processing of timestamps is however mitigated by the accuracy of 1036 computer clocks. If the check is too strict, reasonable connections 1037 could fail. To further mitigate replay attacks, servers MAY record 1038 the list of valid PSK identifiers received in a recent past, and fail 1039 connections if one of these identifiers is replayed. 1041 7. IANA Considerations 1043 This draft does not require any IANA action. (Or does it? What 1044 about the _pds tag?) 1046 8. Acknowledgments 1048 This draft results from initial discussions with Dave Thaler, and 1049 encouragements from the DNS-SD working group members. 1051 9. References 1053 9.1. Normative References 1055 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1056 Extensions (MIME) Part One: Format of Internet Message 1057 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 1058 . 1060 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1061 Requirement Levels", BCP 14, RFC 2119, 1062 DOI 10.17487/RFC2119, March 1997, 1063 . 1065 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 1066 Algorithms and Identifiers for RSA Cryptography for use in 1067 the Internet X.509 Public Key Infrastructure Certificate 1068 and Certificate Revocation List (CRL) Profile", RFC 4055, 1069 DOI 10.17487/RFC4055, June 2005, 1070 . 1072 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 1073 Configuration Option for DHCPv6", RFC 4075, 1074 DOI 10.17487/RFC4075, May 2005, 1075 . 1077 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 1078 Ciphersuites for Transport Layer Security (TLS)", 1079 RFC 4279, DOI 10.17487/RFC4279, December 2005, 1080 . 1082 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1083 (TLS) Protocol Version 1.2", RFC 5246, 1084 DOI 10.17487/RFC5246, August 2008, 1085 . 1087 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1088 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1089 . 1091 9.2. Informative References 1093 [I-D.ietf-dnssd-push] 1094 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 1095 draft-ietf-dnssd-push-07 (work in progress), April 2016. 1097 [I-D.ietf-dprive-dnsodtls] 1098 Reddy, T., Wing, D., and P. Patil, "DNS over DTLS 1099 (DNSoD)", draft-ietf-dprive-dnsodtls-06 (work in 1100 progress), April 2016. 1102 [I-D.ietf-intarea-hostname-practice] 1103 Huitema, C., Thaler, D., and R. Winter, "Current Hostname 1104 Practice Considered Harmful", draft-ietf-intarea-hostname- 1105 practice-02 (work in progress), May 2016. 1107 [I-D.ietf-tls-tls13] 1108 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1109 Version 1.3", draft-ietf-tls-tls13-13 (work in progress), 1110 May 2016. 1112 [KW14a] Kaiser, D. and M. Waldvogel, "Adding Privacy to Multicast 1113 DNS Service Discovery", DOI 10.1109/TrustCom.2014.107, 1114 2014, . 1117 [KW14b] Kaiser, D. and M. Waldvogel, "Efficient Privacy Preserving 1118 Multicast DNS Service Discovery", 1119 DOI 10.1109/HPCC.2014.141, 2014, 1120 . 1123 [RFC1033] Lottor, M., "Domain Administrators Operations Guide", 1124 RFC 1033, DOI 10.17487/RFC1033, November 1987, 1125 . 1127 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1128 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1129 . 1131 [RFC1035] Mockapetris, P., "Domain names - implementation and 1132 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1133 November 1987, . 1135 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1136 specifying the location of services (DNS SRV)", RFC 2782, 1137 DOI 10.17487/RFC2782, February 2000, 1138 . 1140 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1141 DOI 10.17487/RFC6762, February 2013, 1142 . 1144 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 1145 DOI 10.17487/RFC7626, August 2015, 1146 . 1148 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 1149 Profiles for DHCP Clients", RFC 7844, 1150 DOI 10.17487/RFC7844, May 2016, 1151 . 1153 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1154 and P. Hoffman, "Specification for DNS over Transport 1155 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1156 2016, . 1158 Authors' Addresses 1160 Christian Huitema 1161 Microsoft 1162 Redmond, WA 98052 1163 U.S.A. 1165 Email: huitema@microsoft.com 1166 Daniel Kaiser 1167 University of Konstanz 1168 Konstanz 78457 1169 Germany 1171 Email: daniel.kaiser@uni-konstanz.de