idnits 2.17.1 draft-ietf-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: ---------------------------------------------------------------------------- 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 10, 2017) is 2575 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) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-05) exists of draft-ietf-dnssd-pairing-01 == Outdated reference: A later version (-25) exists of draft-ietf-dnssd-push-09 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-18 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 1 error (**), 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 Private Octopus Inc. 4 Intended status: Standards Track D. Kaiser 5 Expires: September 11, 2017 University of Konstanz 6 March 10, 2017 8 Privacy Extensions for DNS-SD 9 draft-ietf-dnssd-privacy-01.txt 11 Abstract 13 DNS-SD (DNS Service Discovery) normally discloses information about 14 both the devices offering services and the devices requesting 15 services. This information includes host names, network parameters, 16 and possibly a further description of the corresponding service 17 instance. Especially when mobile devices engage in DNS Service 18 Discovery over Multicast DNS at a public hotspot, a serious privacy 19 problem arises. 21 We propose to solve this problem by a two-stage approach. In the 22 first stage, hosts discover Private Discovery Service Instances via 23 DNS-SD using special formats to protect their privacy. These service 24 instances correspond to Private Discovery Servers running on peers. 25 In the second stage, hosts directly query these Private Discovery 26 Servers via DNS-SD over TLS. A pairwise shared secret necessary to 27 establish these connections is only known to hosts authorized by a 28 pairing system. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 11, 2017. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Privacy Implications of DNS-SD . . . . . . . . . . . . . . . 4 67 2.1. Privacy Implication of Publishing Service Instance Names 4 68 2.2. Privacy Implication of Publishing Node Names . . . . . . 5 69 2.3. Privacy Implication of Publishing Service Attributes . . 5 70 2.4. Device Fingerprinting . . . . . . . . . . . . . . . . . . 6 71 2.5. Privacy Implication of Discovering Services . . . . . . . 6 72 3. Design of the Private DNS-SD Discovery Service . . . . . . . 7 73 3.1. Device Pairing . . . . . . . . . . . . . . . . . . . . . 8 74 3.2. Discovery of the Private Discovery Service . . . . . . . 8 75 3.2.1. Obfuscated Instance Names . . . . . . . . . . . . . . 8 76 3.2.2. Using a Predictable Nonce . . . . . . . . . . . . . . 9 77 3.2.3. Using a Short Proof . . . . . . . . . . . . . . . . . 10 78 3.2.4. Direct Queries . . . . . . . . . . . . . . . . . . . 11 79 3.3. Private Discovery Service . . . . . . . . . . . . . . . . 11 80 3.3.1. A Note on Private DNS Services . . . . . . . . . . . 12 81 3.4. Randomized Host Names . . . . . . . . . . . . . . . . . . 13 82 3.5. Timing of Obfuscation and Randomization . . . . . . . . . 13 83 4. Private Discovery Service Specification . . . . . . . . . . . 14 84 4.1. Host Name Randomization . . . . . . . . . . . . . . . . . 14 85 4.2. Device Pairing . . . . . . . . . . . . . . . . . . . . . 14 86 4.3. Private Discovery Server . . . . . . . . . . . . . . . . 15 87 4.3.1. Establishing TLS Connections . . . . . . . . . . . . 15 88 4.4. Publishing Private Discovery Service Instances . . . . . 15 89 4.5. Discovering Private Discovery Service Instances . . . . . 16 90 4.6. Direct Discovery of Private Discovery Service Instances . 17 91 4.7. Using the Private Discovery Service . . . . . . . . . . . 17 92 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 93 5.1. Attacks Against the Pairing System . . . . . . . . . . . 18 94 5.2. Denial of Discovery of the Private Discovery Service . . 18 95 5.3. Replay Attacks Against Discovery of the Private Discovery 96 Service . . . . . . . . . . . . . . . . . . . . . . . . . 18 97 5.4. Denial of Private Discovery Service . . . . . . . . . . . 19 98 5.5. Replay Attacks against the Private Discovery Service . . 19 99 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 100 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 101 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 102 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 103 8.2. Informative References . . . . . . . . . . . . . . . . . 21 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 106 1. Introduction 108 DNS-SD [RFC6763] over mDNS [RFC6762] enables configurationless 109 service discovery in local networks. It is very convenient for 110 users, but it requires the public exposure of the offering and 111 requesting identities along with information about the offered and 112 requested services. Some of the information published by the 113 announcements can be very revealing. These privacy issues and 114 potential solutions are 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] over mDNS [RFC6762]. One of the devices will 126 publish the availability of a service, such as a picture library or a 127 file store in our examples. The user of the other device will 128 discover this 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 the instance name, the 132 host name or service properties. We review the design constraint of 133 a solution in Section 3, and describe the proposed solution in 134 Section 4. 136 While we focus on a mDNS-based distribution of the DNS-SD resource 137 records, our solution is agnostic about the distribution method and 138 also works with other distribution methods, e.g. the classical 139 hierarchical DNS. 141 1.1. Requirements 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 2. Privacy Implications of DNS-SD 149 DNS-Based Service Discovery (DNS-SD) is defined in [RFC6763]. It 150 allows nodes to publish the availability of an instance of a service 151 by inserting specific records in the DNS ([RFC1033], [RFC1034], 152 [RFC1035]) or by publishing these records locally using multicast DNS 153 (mDNS) [RFC6762]. Available services are described using three types 154 of records: 156 PTR Record: Associates a service type in the domain with an 157 "instance" name of this service type. 159 SRV Record: Provides the node name, port number, priority and weight 160 associated with the service instance, in conformance with 161 [RFC2782]. 163 TXT Record: Provides a set of attribute-value pairs describing 164 specific properties of the service instance. 166 In the remaining subsections, we will review the privacy issues 167 related to publishing instance names, node names, service attributes 168 and other data, as well as review the implications of using the 169 discovery service as a client. 171 2.1. Privacy Implication of Publishing Service Instance Names 173 In the first phase of discovery, the client obtains all the PTR 174 records associated with a service type in a given naming domain. 175 Each PTR record contains a Service Instance Name defined in Section 4 176 of [RFC6763]: 178 Service Instance Name = . . 180 The portion of the Service Instance Name is meant to 181 convey enough information for users of discovery clients to easily 182 select the desired service instance. Nodes that use DNS-SD over mDNS 183 [RFC6762] in a mobile environment will rely on the specificity of the 184 instance name to identify the desired service instance. In our 185 example of users wanting to upload pictures to a laptop in an 186 Internet Cafe, the list of available service instances may look like: 188 Alice's Images . _imageStore._tcp . local 189 Alice's Mobile Phone . _presence._tcp . local 190 Alice's Notebook . _presence._tcp . local 191 Bob's Notebook . _presence._tcp . local 192 Carol's Notebook . _presence._tcp . local 194 Alice will see the list on her phone and understand intuitively that 195 she should pick the first item. The discovery will "just work". 197 However, DNS-SD/mDNS will reveal to anybody that Alice is currently 198 visiting the Internet Cafe. It further discloses the fact that she 199 uses two devices, shares an image store, and uses a chat application 200 supporting the _presence protocol on both of her devices. She might 201 currently chat with Bob or Carol, as they are also using a _presence 202 supporting chat application. This information is not just available 203 to devices actively browsing for and offering services, but to 204 anybody passively listing to the network traffic. 206 2.2. Privacy Implication of Publishing Node Names 208 The SRV records contain the DNS name of the node publishing the 209 service. Typical implementations construct this DNS name by 210 concatenating the "host name" of the node with the name of the local 211 domain. The privacy implications of this practice are reviewed in 212 [RFC8117]. Depending on naming practices, the host name is either a 213 strong identifier of the device, or at a minimum a partial 214 identifier. It enables tracking of the device, and by extension of 215 the device's owner. 217 2.3. Privacy Implication of Publishing Service Attributes 219 The TXT record's attribute and value pairs contain information on the 220 characteristics of the corresponding service instance. This in turn 221 reveals information about the devices that publish services. The 222 amount of information varies widely with the particular service and 223 its implementation: 225 o Some attributes like the paper size available in a printer, are 226 the same on many devices, and thus only provide limited 227 information to a tracker. 229 o Attributes that have freeform values, such as the name of a 230 directory, may reveal much more information. 232 Combinations of attributes have more information power than specific 233 attributes, and can potentially be used for "fingerprinting" a 234 specific device. 236 Information contained in TXT records does not only breach privacy by 237 making devices trackable, but might directly contain private 238 information about the user. For instance the _presence service 239 reveals the "chat status" to everyone in the same network. Users 240 might not be aware of that. 242 Further, TXT records often contain version information about services 243 allowing potential attackers to identify devices running exploit- 244 prone versions of a certain service. 246 2.4. Device Fingerprinting 248 The combination of information published in DNS-SD has the potential 249 to provide a "fingerprint" of a specific device. Such information 250 includes: 252 o The list of services published by the device, which can be 253 retrieved because the SRV records will point to the same host 254 name. 256 o The specific attributes describing these services. 258 o The port numbers used by the services. 260 o The values of the priority and weight attributes in the SRV 261 records. 263 This combination of services and attributes will often be sufficient 264 to identify the version of the software running on a device. If a 265 device publishes many services with rich sets of attributes, the 266 combination may be sufficient to identify the specific device. 268 There is however an argument that devices providing services can be 269 discovered by observing the local traffic, and that trying to hide 270 the presence of the service is futile. The same argument can be 271 extended to say that the pattern of services offered by a device 272 allows for fingerprinting the device. This may or may not be true, 273 since we can expect that services will be designed or updated to 274 avoid leaking fingerprints. In any case, the design of the discovery 275 service should avoid making a bad situation worse, and should as much 276 as possible avoid providing new fingerprinting information. 278 2.5. Privacy Implication of Discovering Services 280 The consumers of services engage in discovery, and in doing so reveal 281 some information such as the list of services they are interested in 282 and the domains in which they are looking for the services. When the 283 clients select specific instances of services, they reveal their 284 preference for these instances. This can be benign if the service 285 type is very common, but it could be more problematic for sensitive 286 services, such as for example some private messaging services. 288 One way to protect clients would be to somehow encrypt the requested 289 service types. Of course, just as we noted in Section 2.4, traffic 290 analysis can often reveal the service. 292 3. Design of the Private DNS-SD Discovery Service 294 In this section, we present the design of a two-stage solution that 295 enables private use of DNS-SD, without affecting existing users. The 296 solution is largely based on the architecture proposed in [KW14b], 297 which separates the general private discovery problem in three 298 components. The first component is an offline pairing mechanism, 299 which is performed only once per pair of users. It establishes a 300 shared secret over an authenticated channel, allowing devices to 301 authenticate using this secret without user interaction at any later 302 point in time. We use the pairing system proposed in 303 [I-D.ietf-dnssd-pairing]. 305 The further two components are online (in contrast to pairing they 306 are performed anew each time joining a network) and compose the two 307 service discovery stages, namely 309 o Discovery of the Private Discovery Service -- the first stage -- 310 in which hosts discover the Private Discovery Service (PDS), a 311 special service offered by every host supporting our extension. 312 After the discovery, hosts connect to the PSD offered by paired 313 peers. 315 o Actual Service Discovery -- the second stage -- is performed 316 through the Private Discovery Service, which only accepts 317 encrypted messages associated with an authenticated session; thus 318 not compromising privacy. 320 In other words, the hosts first discover paired peers and then 321 directly engage in privacy preserving service discovery. 323 The stages are independent with respect to means used for 324 transmitting the necessary data. While in our extension the messages 325 for the first stage are transmitted using IP multicast, the messages 326 for the second stage are transmitted via unicast. One could also 327 imagine using a Distributed Hash Table for the first stage, being 328 completely independent of multicast. 330 3.1. Device Pairing 332 Any private discovery solution needs to differentiate between 333 authorized devices, which are allowed to get information about 334 discoverable entities, and other devices, which should not be aware 335 of the availability of private entities. The commonly used solution 336 to this problem is establishing a "device pairing". 338 Device pairing has to be performed only once per pair of users. This 339 is important for user-friendliness, as it is the only step that 340 demands user-interaction. After this single pairing, privacy 341 preserving service discovery works fully automatically. In this 342 document, we leverage [I-D.ietf-dnssd-pairing] as pairing mechanism. 344 The pairing yields a mutually authenticated shared secret, and 345 optionally mutually authenticated public keys or certificates added 346 to a local web of trust. Public key technology has many advantages, 347 but shared secrets are typically easier to handle on small devices. 349 3.2. Discovery of the Private Discovery Service 351 The first stage of service discovery is to check whether instances of 352 compatible Private Discovery Services are available in the local 353 scope. The goal of that stage is to identify devices that share a 354 pairing with the querier, and are available locally. The service 355 instances can be discovered using regular DNS-SD procedures, but the 356 list of discovered services will have to be filtered so only paired 357 devices are retained. 359 3.2.1. Obfuscated Instance Names 361 The instance names for the Private Discovery Service are obfuscated, 362 so that authorized peers can associate the instance with its 363 publisher, but unauthorized peers can only observe what looks like a 364 random name. To achieve this, the names are composed as the 365 concatenation of a nonce and a proof, which is composed by hashing 366 the nonce with a pairing key: 368 PrivateInstanceName = | 369 proof = hash(|) 371 The publisher will publish as many instances as it has established 372 pairings. 374 The discovering party that looks for instances of the service will 375 receive lists of advertisements from nodes present on the network. 376 For each advertisement, it will parse the instance name, and then, 377 for each available pairing key, compares the proof to the hash of the 378 nonce concatenated with this pairing key. If there is no match, it 379 discards the instance name. If there is a match, it has discovered a 380 peer. 382 3.2.2. Using a Predictable Nonce 384 Assume that there are N nodes on the local scope, and that each node 385 has on average M pairings. Each node will publish on average M 386 records, and the node engaging in discovery may have to process on 387 average N*M instance names. The discovering node will have to 388 compute on average M potential hashes for each nonce. The number of 389 hash computations would scale as O(N*M*M), which means that it could 390 cause a significant drain of resource in large networks. 392 In order to minimize the amount of computing resource, we suggest 393 that the nonce be derived from the current time, for example set to a 394 representation of the current time rounded to some period. With this 395 convention, receivers can predict the nonces that will appear in the 396 published instances. They will only need to compute O(M) hashes, 397 instead of O(N*M*M). 399 The publishers will have to create new records at the end of each 400 rounding period. If the rounding period is set too short, they will 401 have to repeat that very often, which is inefficient. On the other 402 hand, if the rounding period is too long, the system may be exposed 403 to replay attacks. We propose to set a value of about 5 minutes, 404 which seems to be a reasonable compromise. 406 Unix defines a 32 bit time stamp as the number of seconds elapsed 407 since January 1st, 1970 not counting leap seconds. The most 408 significant 24 bits of this 32 bit number represent the number of 256 409 seconds intervals since the epoch. 256 seconds correspond to 4 410 minutes and 16 seconds, which is close enough to our design goal of 5 411 minutes. We will thus use this 24 bit number as nonce, represented 412 as 3 octets. 414 Publishers will need to compute O(M) hashes at most once per time 415 stamp interval. If records can be created "on the fly", publishers 416 will only need to perform that computation upon receipt of the first 417 query during a given interval, and cache the computed results for the 418 remainder of the interval. There are however scenarios in which 419 records have to be produced in advance, for example when records are 420 published within a scope defined by a domain name and managed by a 421 "classic" DNS server. In such scenarios, publishers will need to 422 perform the computations and publication exactly once per time stamp 423 interval. 425 3.2.3. Using a Short Proof 427 Devices will have to publish as many instance names as they have 428 peers. The instance names will have to be represented via a text 429 string, which means that the binary concatenation of nonce and proof 430 will have to be encoded using a binary-to-text conversion such as 431 BASE64 ([RFC2045] section 6.8) or BASE32 ([RFC4648] section 6). 433 Using long proofs, such as the full output of SHA256 [RFC4055], would 434 generate fairly long instance names: 48 characters using BASE64, or 435 56 using BASE56. These long names would inflate the network traffic 436 required when discovering the privacy service. They would also limit 437 the number of DNS-SD PTR records that could be packed in a single 438 1500 octet sized packet, to 23 or fewer with BASE64, or 20 or fewer 439 with BASE32. 441 Shorter proofs lead to shorter messages, which is more efficient as 442 long as we do not encounter too many collisions. A collision will 443 happen if the proof computed by the publisher using one key matches a 444 proof computed by a receiver using another key. If a receiver 445 mistakenly believes that a proof fits one of its peers, it will 446 attempt to connect to the service as explained in section Section 4.5 447 but in the absence of the proper pairwise shared key, the connection 448 will fail. This will not create an actual error, but the probability 449 of such events should be kept low. 451 The following table provides the probability that a discovery agent 452 maintaining 100 pairings will observe a collision after receiving 453 100000 advertisement records. It also provides the number of 454 characters required for the encoding of the corresponding instance 455 name in BASE64 or BASE32, assuming 24 bit nonces. 457 +-------+------------+--------+--------+ 458 | Proof | Collisions | BASE64 | BASE32 | 459 +-------+------------+--------+--------+ 460 | 24 | 5.96046% | 8 | 16 | 461 | 32 | 0.02328% | 11 | 16 | 462 | 40 | 0.00009% | 12 | 16 | 463 | 48 | 3.6E-09 | 12 | 16 | 464 | 56 | 1.4E-11 | 15 | 16 | 465 +-------+------------+--------+--------+ 467 Table 1 469 The table shows that for a proof, 24 bits would be too short. 32 bits 470 might be long enough, but the BASE64 encoding requires padding if the 471 input is not an even multiple of 24 bits, and BASE32 requires padding 472 if the input is not a multiple of 40 bits. Given that, the desirable 473 proof lengths are thus 48 bits if using BASE64, or 56 bits if using 474 BASE32. The resulting instance name will be either 12 characters 475 long with BASE64, allowing 54 advertisements in an 1500 byte mDNS 476 message, or 16 characters long with BASE32, allowing 47 477 advertisements per message. 479 In the specification section, we will assume BASE64, and 48 bit 480 proofs composed of the first 6 bytes of a SHA256 hash. 482 3.2.4. Direct Queries 484 The preceding sections assume that the discovery is performed using 485 the classic DNS-SD process, in which a query for all available 486 "instance names" of a service provides a list of PTR records. The 487 discoverer will then select the instance names that correspond to its 488 peers, and request the SRV and TXT records corresponding to the 489 service instance, and then obtain the relevant A or AAAA records. 490 This is generally required in DNS-SD because the instance names are 491 not known in advance, but for the Private Discovery Service the 492 instance names can be predicted, and a more efficient Direct Query 493 method can be used. 495 At a given time, the node engaged in discovery can predict the nonce 496 that its peer will use, since that nonce is composed by rounding the 497 current time. The node can also compute the proofs that its peers 498 might use, since it knows the nonce and the keys. The node can thus 499 build a list of instance names, and directly query the SRV records 500 corresponding to these names. If peers are present, they will answer 501 directly. 503 This "direct query" process will result in fewer network messages 504 than the regular DNS-SD query process in some circumstances, 505 depending on the number of peers per node and the number of nodes 506 publishing the presence discovery service in the desired scope. 508 When using mDNS, it is possible to pack multiple queries in a single 509 broadcast message. Using name compression and 12 characters per 510 instance name, it is possible to pack 70 queries in a 1500 octet mDNS 511 multicast message. It is also possible to request unicast replies to 512 the queries, resulting in significant efficiency gains in wireless 513 networks. 515 3.3. Private Discovery Service 517 The Private Discovery Service discovery allows discovering a list of 518 available paired devices, and verifying that either party knows the 519 corresponding shared secret. At that point, the querier can engage 520 in a series of directed discoveries. 522 We have considered defining an ad-hoc protocol for the private 523 discovery service, but found that just using TLS would be much 524 simpler. The Directed Private Discovery service is just a regular 525 DNS-SD service, accessed over TLS, using the encapsulation of DNS 526 over TLS defined in [RFC7858]. The main difference with simple DNS 527 over TLS is the need for authentication. 529 We assume that the pairing process has provided each pair of 530 authorized client and server with a shared secret. We can use that 531 shared secret to provide mutual authentication of clients and servers 532 using "Pre Shared Key" authentication, as defined in [RFC4279] and 533 incorporated in the latest version of TLS [I-D.ietf-tls-tls13]. 535 One difficulty is the reliance on a key identifier in the protocol. 536 For example, in TLS 1.3 the PSK extension is defined as: 538 opaque psk_identity<0..2^16-1>; 540 struct { 541 select (Role) { 542 case client: 543 psk_identity identities<2..2^16-1>; 545 case server: 546 uint16 selected_identity; 547 } 548 } PreSharedKeyExtension 550 According to the protocol, the PSK identity is passed in clear text 551 at the beginning of the key exchange. This is logical, since server 552 and clients need to identify the secret that will be used to protect 553 the connection. But if we used a static identifier for the key, 554 adversaries could use that identifier to track server and clients. 555 The solution is to use a time-varying identifier, constructed exactly 556 like the "proof" described in Section 3.2, by concatenating a nonce 557 and the hash of the nonce with the shared secret. 559 3.3.1. A Note on Private DNS Services 561 Our solution uses a variant of the DNS over TLS protocol [RFC7858] 562 defined by the DNS Private Exchange working group (DPRIVE). DPRIVE 563 is also working on an UDP variant, DNS over DTLS 564 [I-D.ietf-dprive-dnsodtls], which would also be a candidate. 566 DPRIVE and Private Discovery solve however two somewhat different 567 problems. DPRIVE is concerned with the confidentiality of DNS 568 transactions, addressing the problems outlined in [RFC7626]. 569 However, DPRIVE does not address the confidentiality or privacy 570 issues with publication of services, and is not a direct solution to 571 DNS-SD privacy: 573 o Discovery queries are scoped by the domain name within which 574 services are published. As nodes move and visit arbitrary 575 networks, there is no guarantee that the domain services for these 576 networks will be accessible using DNS over TLS or DNS over DTLS. 578 o Information placed in the DNS is considered public. Even if the 579 server does support DNS over TLS, third parties will still be able 580 to discover the content of PTR, SRV and TXT records. 582 o Neither DNS over TLS nor DNS over DTLS applies to MDNS. 584 In contrast, we propose using mutual authentication of the client and 585 server as part of the TLS solution, to ensure that only authorized 586 parties learn the presence of a service. 588 3.4. Randomized Host Names 590 Instead of publishing their actual name in the SRV records, nodes 591 could publish a randomized name. That is the solution argued for in 592 [RFC8117]. 594 Randomized host names will prevent some of the tracking. Host names 595 are typically not visible by the users, and randomizing host names 596 will probably not cause much usability issues. 598 3.5. Timing of Obfuscation and Randomization 600 It is important that the obfuscation of instance names is performed 601 at the right time, and that the obfuscated names change in synchrony 602 with other identifiers, such as MAC Addresses, IP Addresses or host 603 names. If the randomized host name changed but the instance name 604 remained constant, an adversary would have no difficulty linking the 605 old and new host names. Similarly, if IP or MAC addresses changed 606 but host names remained constant, the adversary could link the new 607 addresses to the old ones using the published name. 609 The problem is handled in [RFC8117], which recommends to pick a new 610 random host name at the time of connecting to a new network. New 611 instance names for the Private Discovery Services should be composed 612 at the same time. 614 4. Private Discovery Service Specification 616 The proposed solution uses the following components: 618 o Host name randomization to prevent tracking. 620 o Device pairing yielding pairwise shared secrets. 622 o A Private Discovery Server (PDS) running on each host. 624 o Discovery of the PDS instances using DNS-SD. 626 These components are detailed in the following subsections. 628 4.1. Host Name Randomization 630 Nodes publishing services with DNS-SD and concerned about their 631 privacy MUST use a randomized host name. The randomized name MUST be 632 changed when network connectivity changes, to avoid the correlation 633 issues described in Section 3.5. The randomized host name MUST be 634 used in the SRV records describing the service instance, and the 635 corresponding A or AAAA records MUST be made available through DNS or 636 MDNS, within the same scope as the PTR, SRV and TXT records used by 637 DNS-SD. 639 If the link-layer address of the network connection is properly 640 obfuscated (e.g. using MAC Address Randomization), the Randomized 641 Host Name MAY be computed using the algorithm described in section 642 3.7 of [RFC7844]. If this is not possible, the randomized host name 643 SHOULD be constructed by simply picking a 48 bit random number 644 meeting the Randomness Requirements for Security expressed in 645 [RFC4075], and then use the hexadecimal representation of this number 646 as the obfuscated host name. 648 4.2. Device Pairing 650 Nodes that want to leverage the Private Directory Service for private 651 service discovery among peers MUST share a secret with each of these 652 peers. Each shared secret MUST be a 256 bit randomly chosen number. 653 We RECOMMEND using the pairing mechanism proposed in 654 [I-D.ietf-dnssd-pairing] to establish these secrets. 656 [[TODO: Should we support mutually authenticated certificates? They 657 can also be used to initiate TLS and have several advantages, i.e. 658 allow setting an expiry date.]] 660 4.3. Private Discovery Server 662 A Private Discovery Server (PDS) is a minimal DNS server running on 663 each host. Its task is to offer resource records corresponding to 664 private services only to authorized peers. These peers MUST share a 665 secret with the host (see Section 4.2). To ensure privacy of the 666 requests, the service is only available over TLS [RFC5246], and the 667 shared secrets are used to mutually authenticate peers and servers. 669 The Private Name Server SHOULD support DNS push notifications 670 [I-D.ietf-dnssd-push], e.g. to facilitate an up-to-date contact list 671 in a chat application without polling. 673 4.3.1. Establishing TLS Connections 675 The PDS MUST only answer queries via DNS over TLS [RFC7858] and MUST 676 use a PSK authenticated TLS handshake [RFC4279]. The client and 677 server SHOULD negotiate a forward secure cipher suite such as DHE-PSK 678 or ECDHE-PSK when available. The shared secret exchanged during 679 pairing MUST be used as PSK. To guarantee interoperability, 680 implementations of the Private Name Server MUST support 681 TLS_PSK_WITH_AES_256_GCM_SHA384. 683 When using the PSK based authentication, the "psk_identity" parameter 684 identifying the pre-shared key MUST be identical to the "Instance 685 Identifier" defined in Section 4.4, i.e. 24 bit nonce and 48 bit 686 proof encoded in BASE64 as 12 character string. The server will use 687 the pairing key associated with this instance identifier. 689 4.4. Publishing Private Discovery Service Instances 691 Nodes that provide the Private Discovery Service SHOULD advertise 692 their availability by publishing instances of the service through 693 DNS-SD. 695 The DNS-SD service type for the Private Discovery Service is 696 "_pds._tcp". 698 Each published instance describes one server and one pairing. In the 699 case where a node manages more than one pairing, it should publish as 700 many instances as necessary to advertise all available pairings. 702 Each instance name is composed as follows: 704 pick a 24 bit nonce, set to the 24 most 705 significant bits of the 32 bit Unix GMT time. 707 compute a 48 bit proof: 708 proof = first 48 bits of HASH(|) 710 set the 72 bit binary identifier as the concatenation 711 of nonce and proof 713 set instance-ID = BASE64(binary identifier) 715 In this formula, HASH SHOULD be the function SHA256 defined in 716 [RFC4055], and BASE64 is defined in section 6.8 of [RFC2045]. The 717 concatenation of a 24 bit nonce and 48 bit proof result in a 72 bit 718 string. The BASE64 conversion is 12 characters long per [RFC6763]. 720 4.5. Discovering Private Discovery Service Instances 722 Nodes that wish to discover Private Discovery Service Instances 723 SHOULD issue a DNS-SD discovery request for the service type 724 "_pds._tcp". They MAY, as an alternative, use the Direct Discovery 725 procedure defined in Section 4.6. If nodes send a DNS-SD discovery 726 request, they will receive in response a series of PTR records, 727 providing the names of the instances present in the scope. 729 The querier SHOULD examine each instance to see whether it 730 corresponds to one of its available pairings, according to the 731 following conceptual algorithm: 733 for each received instance name: 734 convert the instance name to binary using BASE64 735 if the conversion fails, 736 discard the instance. 737 if the binary instance length is not multiple 72 bits, 738 discard the instance. 740 nonce = first 24 bits of binary. 742 if nonce does not match the first 24 bits of the current 743 time plus or minus 1 minute, discard the instance. 745 for each available pairing 746 retrieve the key Xj of pairing number j 747 compute F = first 48 bits of hash(nonce, Xj) 748 if F is equal to the last 48 bits of 749 the binary instance ID 750 mark the pairing number j as available 752 The check of the current time is meant to mitigate replay attacks, 753 while not mandating a time synchronization precision better than one 754 minute. 756 Once a pairing has been marked available, the querier SHOULD try 757 connecting to the corresponding instance, using the selected key. 758 The connection is likely to succeed, but it MAY fail for a variety of 759 reasons. One of these reasons is the probabilistic nature of the 760 hint, which entails a small chance of "false positive" match. This 761 will occur if the hash of the nonce with two different keys produces 762 the same result. In that case, the TLS connection will fail with an 763 authentication error or a decryption error. 765 4.6. Direct Discovery of Private Discovery Service Instances 767 Nodes that wish to discover Private Discovery Service Instances MAY 768 use the following Direct Discovery procedure instead of the regular 769 DNS-SD Discovery explained in Section 4.5. 771 To perform Direct Discovery, nodes should compose a list of Private 772 Discovery Service Instances Names. There will be one name for each 773 pairing available to the node. The Instance ID for each name will be 774 composed of a nonce and a proof, using the algorithm specified in 775 Section 4.4. 777 The querier will issue SRV record queries for each of these names. 778 The queries will only succeed if the corresponding instance is 779 present, in which case a pairing is discovered. After that, the 780 querier SHOULD try connecting to the corresponding instance, as 781 explained in Section 4.4. 783 4.7. Using the Private Discovery Service 785 Once instances of the Private Discovery Service have been discovered, 786 peers can establish TLS connections and send DNS requests over these 787 connections, as specified in DNS-SD. 789 5. Security Considerations 791 This document specifies a method to protect the privacy of service 792 publishing nodes. This is especially useful when operating in a 793 public space. Hiding the identity of the publishing nodes prevents 794 some forms of "targeting" of high value nodes. However, adversaries 795 can attempt various attacks to break the anonymity of the service, or 796 to deny it. A list of these attacks and their mitigations are 797 described in the following sections. 799 5.1. Attacks Against the Pairing System 801 There are a variety of attacks against pairing systems, which may 802 result in compromised pairing secrets. If an adversary manages to 803 acquire a compromised key, the adversary will be able to perform 804 private service discovery according to Section 4.5. This will allow 805 tracking of the service. The adversary will also be able to discover 806 which private services are available for the compromised pairing. 808 Attacks on pairing systems are detailed in [I-D.ietf-dnssd-pairing]. 810 5.2. Denial of Discovery of the Private Discovery Service 812 The algorithm described in Section 4.5 scales as O(M*N), where M is 813 the number of pairings per node and N is the number of nodes in the 814 local scope. Adversaries can attack this service by publishing 815 "fake" instances, effectively increasing the number N in that scaling 816 equation. 818 Similar attacks can be mounted against DNS-SD: creating fake 819 instances will generally increase the noise in the system and make 820 discovery less usable. Private Discovery Service discovery SHOULD 821 use the same mitigations as DNS-SD. 823 The attack could be amplified if the clients needed to compute proofs 824 for all the nonces presented in Private Discovery Service Instance 825 names. This is mitigated by the specification of nonces as rounded 826 time stamps in Section 4.5. If we assume that timestamps must not be 827 too old, there will be a finite number of valid rounded timestamps at 828 any time. Even if there are many instances present, they would all 829 pick their nonces from this small number of rounded timestamps, and a 830 smart client will make sure that proofs are only computed once per 831 valid time stamp. 833 5.3. Replay Attacks Against Discovery of the Private Discovery Service 835 Adversaries can record the service instance names published by 836 Private Discovery Service instances, and replay them later in 837 different contexts. Peers engaging in discovery can be misled into 838 believing that a paired server is present. They will attempt to 839 connect to the absent peer, and in doing so will disclose their 840 presence in a monitored scope. 842 The binary instance identifiers defined in Section 4.4 start with 24 843 bits encoding the most significant bits of the "UNIX" time. In order 844 to protect against replay attacks, clients SHOULD verify that this 845 time is reasonably recent, as specified in Section 4.5. 847 [[TODO: Should we somehow encode the scope in the identifier? Having 848 both scope and time would really mitigate that attack. For example, 849 one could add a local IPv4 or IPv6 prefix in the nonce. However, 850 this won't work in networks behind NAT. It would also increase the 851 size of the instance ID.]] 853 5.4. Denial of Private Discovery Service 855 The Private Discovery Service is only available through a mutually 856 authenticated TLS connection, which provides state-of-the-art 857 protection mechanisms. However, adversaries can mount a denial of 858 service attack against the service. In the absence of shared 859 secrets, the connections will fail, but the servers will expend some 860 CPU cycles defending against them. 862 To mitigate such attacks, nodes SHOULD restrict the range of network 863 addresses from which they accept connections, matching the expected 864 scope of the service. 866 This mitigation will not prevent denial of service attacks performed 867 by locally connected adversaries; but protecting against local denial 868 of service attacks is generally very difficult. For example, local 869 attackers can also attack mDNS and DNS-SD by generating a large 870 number of multicast requests. 872 5.5. Replay Attacks against the Private Discovery Service 874 Adversaries may record the PSK Key Identifiers used in successful 875 connections to a private discovery service. They could attempt to 876 replay them later against nodes advertising the private service at 877 other times or at other locations. If the PSK Identifier is still 878 valid, the server will accept the TLS connection, and in doing so 879 will reveal being the same server observed at a previous time or 880 location. 882 The PSK identifiers defined in Section 4.3.1 start with the 24 most 883 significant bits of the "UNIX" time. In order to mitigate replay 884 attacks, servers SHOULD verify that this time is reasonably recent, 885 and fail the connection if it is too old, or if it occurs too far in 886 the future. 888 The processing of timestamps is however affected by the accuracy of 889 computer clocks. If the check is too strict, reasonable connections 890 could fail. To further mitigate replay attacks, servers MAY record 891 the list of valid PSK identifiers received in a recent past, and fail 892 connections if one of these identifiers is replayed. 894 6. IANA Considerations 896 This draft does not require any IANA action. (Or does it? What 897 about the _pds tag?) 899 7. Acknowledgments 901 This draft results from initial discussions with Dave Thaler, and 902 encouragements from the DNS-SD working group members. 904 8. References 906 8.1. Normative References 908 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 909 Extensions (MIME) Part One: Format of Internet Message 910 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 911 . 913 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 914 Requirement Levels", BCP 14, RFC 2119, 915 DOI 10.17487/RFC2119, March 1997, 916 . 918 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 919 Algorithms and Identifiers for RSA Cryptography for use in 920 the Internet X.509 Public Key Infrastructure Certificate 921 and Certificate Revocation List (CRL) Profile", RFC 4055, 922 DOI 10.17487/RFC4055, June 2005, 923 . 925 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 926 Configuration Option for DHCPv6", RFC 4075, 927 DOI 10.17487/RFC4075, May 2005, 928 . 930 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 931 Ciphersuites for Transport Layer Security (TLS)", 932 RFC 4279, DOI 10.17487/RFC4279, December 2005, 933 . 935 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 936 (TLS) Protocol Version 1.2", RFC 5246, 937 DOI 10.17487/RFC5246, August 2008, 938 . 940 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 941 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 942 . 944 8.2. Informative References 946 [I-D.ietf-dnssd-pairing] 947 Huitema, C. and D. Kaiser, "Device Pairing Using Short 948 Authentication Strings", draft-ietf-dnssd-pairing-01 (work 949 in progress), March 2017. 951 [I-D.ietf-dnssd-push] 952 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 953 draft-ietf-dnssd-push-09 (work in progress), October 2016. 955 [I-D.ietf-dprive-dnsodtls] 956 Reddy, T., Wing, D., and P. Patil, "Specification for DNS 957 over Datagram Transport Layer Security (DTLS)", draft- 958 ietf-dprive-dnsodtls-15 (work in progress), December 2016. 960 [I-D.ietf-tls-tls13] 961 Rescorla, E., "The Transport Layer Security (TLS) Protocol 962 Version 1.3", draft-ietf-tls-tls13-18 (work in progress), 963 October 2016. 965 [KW14a] Kaiser, D. and M. Waldvogel, "Adding Privacy to Multicast 966 DNS Service Discovery", DOI 10.1109/TrustCom.2014.107, 967 2014, . 970 [KW14b] Kaiser, D. and M. Waldvogel, "Efficient Privacy Preserving 971 Multicast DNS Service Discovery", 972 DOI 10.1109/HPCC.2014.141, 2014, 973 . 976 [RFC1033] Lottor, M., "Domain Administrators Operations Guide", 977 RFC 1033, DOI 10.17487/RFC1033, November 1987, 978 . 980 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 981 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 982 . 984 [RFC1035] Mockapetris, P., "Domain names - implementation and 985 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 986 November 1987, . 988 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 989 specifying the location of services (DNS SRV)", RFC 2782, 990 DOI 10.17487/RFC2782, February 2000, 991 . 993 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 994 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 995 . 997 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 998 DOI 10.17487/RFC6762, February 2013, 999 . 1001 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 1002 DOI 10.17487/RFC7626, August 2015, 1003 . 1005 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 1006 Profiles for DHCP Clients", RFC 7844, 1007 DOI 10.17487/RFC7844, May 2016, 1008 . 1010 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1011 and P. Hoffman, "Specification for DNS over Transport 1012 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1013 2016, . 1015 [RFC8117] Huitema, C., Thaler, D., and R. Winter, "Current Hostname 1016 Practice Considered Harmful", RFC 8117, 1017 DOI 10.17487/RFC8117, March 2017, 1018 . 1020 Authors' Addresses 1022 Christian Huitema 1023 Private Octopus Inc. 1024 Friday Harbor, WA 98250 1025 U.S.A. 1027 Email: huitema@huitema.net 1028 URI: http://privateoctopus.com/ 1029 Daniel Kaiser 1030 University of Konstanz 1031 Konstanz 78457 1032 Germany 1034 Email: daniel.kaiser@uni-konstanz.de