idnits 2.17.1 draft-ietf-dnssd-privacy-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 18, 2018) is 2172 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-03 == Outdated reference: A later version (-25) exists of draft-ietf-dnssd-push-14 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 1 error (**), 0 flaws (~~), 3 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: October 20, 2018 University of Konstanz 6 April 18, 2018 8 Privacy Extensions for DNS-SD 9 draft-ietf-dnssd-privacy-04 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 https://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 October 20, 2018. 47 Copyright Notice 49 Copyright (c) 2018 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 (https://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 . . . . . . . 7 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 . . . . . . . . . . . . . . 9 76 3.2.2. Using a Predictable Nonce . . . . . . . . . . . . . . 9 77 3.2.3. Using a Short Proof . . . . . . . . . . . . . . . . . 10 78 3.2.4. Direct Queries . . . . . . . . . . . . . . . . . . . 12 79 3.3. Private Discovery Service . . . . . . . . . . . . . . . . 12 80 3.3.1. A Note on Private DNS Services . . . . . . . . . . . 13 81 3.4. Randomized Host Names . . . . . . . . . . . . . . . . . . 14 82 3.5. Timing of Obfuscation and Randomization . . . . . . . . . 14 83 4. Private Discovery Service Specification . . . . . . . . . . . 14 84 4.1. Host Name Randomization . . . . . . . . . . . . . . . . . 15 85 4.2. Device Pairing . . . . . . . . . . . . . . . . . . . . . 15 86 4.3. Private Discovery Server . . . . . . . . . . . . . . . . 15 87 4.3.1. Establishing TLS Connections . . . . . . . . . . . . 15 88 4.4. Publishing Private Discovery Service Instances . . . . . 16 89 4.5. Discovering Private Discovery Service Instances . . . . . 17 90 4.6. Direct Discovery of Private Discovery Service Instances . 18 91 4.7. Using the Private Discovery Service . . . . . . . . . . . 19 92 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 93 5.1. Attacks Against the Pairing System . . . . . . . . . . . 19 94 5.2. Denial of Discovery of the Private Discovery Service . . 19 95 5.3. Replay Attacks Against Discovery of the Private Discovery 96 Service . . . . . . . . . . . . . . . . . . . . . . . . . 20 97 5.4. Denial of Private Discovery Service . . . . . . . . . . . 20 98 5.5. Replay Attacks against the Private Discovery Service . . 20 99 5.6. Replay attacks and clock synchronization . . . . . . . . 21 100 5.7. Fingerprinting the number of published instances . . . . 21 101 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 102 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 103 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 104 8.1. Normative References . . . . . . . . . . . . . . . . . . 22 105 8.2. Informative References . . . . . . . . . . . . . . . . . 23 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 108 1. Introduction 110 DNS-SD [RFC6763] over mDNS [RFC6762] enables configurationless 111 service discovery in local networks. It is very convenient for 112 users, but it requires the public exposure of the offering and 113 requesting identities along with information about the offered and 114 requested services. Parts of the published information can seriously 115 breach the user's privacy. These privacy issues and potential 116 solutions are discussed in [KW14a] and [KW14b]. 118 There are cases when nodes connected to a network want to provide or 119 consume services without exposing their identity to the other parties 120 connected to the same network. Consider for example a traveler 121 wanting to upload pictures from a phone to a laptop when connected to 122 the Wi-Fi network of an Internet cafe, or two travelers who want to 123 share files between their laptops when waiting for their plane in an 124 airport lounge. 126 We expect that these exchanges will start with a discovery procedure 127 using DNS-SD [RFC6763] over mDNS [RFC6762]. One of the devices will 128 publish the availability of a service, such as a picture library or a 129 file store in our examples. The user of the other device will 130 discover this service, and then connect to it. 132 When analyzing these scenarios in Section 2, we find that the DNS-SD 133 messages leak identifying information such as the instance name, the 134 host name or service properties. We review the design constraint of 135 a solution in Section 3, and describe the proposed solution in 136 Section 4. 138 While we focus on a mDNS-based distribution of the DNS-SD resource 139 records, our solution is agnostic about the distribution method and 140 also works with other distribution methods, e.g. the classical 141 hierarchical DNS. 143 1.1. Requirements 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 2. Privacy Implications of DNS-SD 151 DNS-Based Service Discovery (DNS-SD) is defined in [RFC6763]. It 152 allows nodes to publish the availability of an instance of a service 153 by inserting specific records in the DNS ([RFC1033], [RFC1034], 154 [RFC1035]) or by publishing these records locally using multicast DNS 155 (mDNS) [RFC6762]. Available services are described using three types 156 of records: 158 PTR Record: Associates a service type in the domain with an 159 "instance" name of this service type. 161 SRV Record: Provides the node name, port number, priority and weight 162 associated with the service instance, in conformance with 163 [RFC2782]. 165 TXT Record: Provides a set of attribute-value pairs describing 166 specific properties of the service instance. 168 In the remaining subsections, we will review the privacy issues 169 related to publishing instance names, node names, service attributes 170 and other data, as well as review the implications of using the 171 discovery service as a client. 173 2.1. Privacy Implication of Publishing Service Instance Names 175 In the first phase of discovery, the client obtains all the PTR 176 records associated with a service type in a given naming domain. 177 Each PTR record contains a Service Instance Name defined in Section 4 178 of [RFC6763]: 180 Service Instance Name = . . 182 The portion of the Service Instance Name is meant to 183 convey enough information for users of discovery clients to easily 184 select the desired service instance. Nodes that use DNS-SD over mDNS 185 [RFC6762] in a mobile environment will rely on the specificity of the 186 instance name to identify the desired service instance. In our 187 example of users wanting to upload pictures to a laptop in an 188 Internet Cafe, the list of available service instances may look like: 190 Alice's Images . _imageStore._tcp . local 191 Alice's Mobile Phone . _presence._tcp . local 192 Alice's Notebook . _presence._tcp . local 193 Bob's Notebook . _presence._tcp . local 194 Carol's Notebook . _presence._tcp . local 196 Alice will see the list on her phone and understand intuitively that 197 she should pick the first item. The discovery will "just work". 199 However, DNS-SD/mDNS will reveal to anybody that Alice is currently 200 visiting the Internet Cafe. It further discloses the fact that she 201 uses two devices, shares an image store, and uses a chat application 202 supporting the _presence protocol on both of her devices. She might 203 currently chat with Bob or Carol, as they are also using a _presence 204 supporting chat application. This information is not just available 205 to devices actively browsing for and offering services, but to 206 anybody passively listening to the network traffic. 208 2.2. Privacy Implication of Publishing Node Names 210 The SRV records contain the DNS name of the node publishing the 211 service. Typical implementations construct this DNS name by 212 concatenating the "host name" of the node with the name of the local 213 domain. The privacy implications of this practice are reviewed in 214 [RFC8117]. Depending on naming practices, the host name is either a 215 strong identifier of the device, or at a minimum a partial 216 identifier. It enables tracking of both the device, and, by 217 extension, the device's owner. 219 2.3. Privacy Implication of Publishing Service Attributes 221 The TXT record's attribute-value pairs contain information on the 222 characteristics of the corresponding service instance. This in turn 223 reveals information about the devices that publish services. The 224 amount of information varies widely with the particular service and 225 its implementation: 227 o Some attributes like the paper size available in a printer, are 228 the same on many devices, and thus only provide limited 229 information to a tracker. 231 o Attributes that have freeform values, such as the name of a 232 directory, may reveal much more information. 234 Combinations of attributes have more information power than specific 235 attributes, and can potentially be used for "fingerprinting" a 236 specific device. 238 Information contained in TXT records does not only breach privacy by 239 making devices trackable, but might directly contain private 240 information about the user. For instance the _presence service 241 reveals the "chat status" to everyone in the same network. Users 242 might not be aware of that. 244 Further, TXT records often contain version information about services 245 allowing potential attackers to identify devices running exploit- 246 prone versions of a certain service. 248 2.4. Device Fingerprinting 250 The combination of information published in DNS-SD has the potential 251 to provide a "fingerprint" of a specific device. Such information 252 includes: 254 o The list of services published by the device, which can be 255 retrieved because the SRV records will point to the same host 256 name. 258 o The specific attributes describing these services. 260 o The port numbers used by the services. 262 o The values of the priority and weight attributes in the SRV 263 records. 265 This combination of services and attributes will often be sufficient 266 to identify the version of the software running on a device. If a 267 device publishes many services with rich sets of attributes, the 268 combination may be sufficient to identify the specific device. 270 A sometimes heard argument is that devices providing services can be 271 identified by observing the local traffic, and that trying to hide 272 the presence of the service is futile. This argument, however, does 273 not carry much weight because 275 1. proving privacy at the discovery layer is of the essence for 276 enabling automatically configured privacy-preserving network 277 applications. Application layer protocols are not forced to 278 leverage the offered privacy, but if device tracking is not 279 prevented at the deeper layers, including the service discovery 280 layer, obfuscating a certain service's protocol at the 281 application layer is futile. 283 2. Further, even if the application layer does not protect privacy, 284 it is hard to record and analyse the unicast traffic (which most 285 applications will generate) compared to just listening to the 286 multicast messages sent by DNS-SD/mDNS. 288 The same argument can be extended to say that the pattern of services 289 offered by a device allows for fingerprinting the device. This may 290 or may not be true, since we can expect that services will be 291 designed or updated to avoid leaking fingerprints. In any case, the 292 design of the discovery service should avoid making a bad situation 293 worse, and should as much as possible avoid providing new 294 fingerprinting information. 296 2.5. Privacy Implication of Discovering Services 298 The consumers of services engage in discovery, and in doing so reveal 299 some information such as the list of services they are interested in 300 and the domains in which they are looking for the services. When the 301 clients select specific instances of services, they reveal their 302 preference for these instances. This can be benign if the service 303 type is very common, but it could be more problematic for sensitive 304 services, such as for example some private messaging services. 306 One way to protect clients would be to somehow encrypt the requested 307 service types. Of course, just as we noted in Section 2.4, traffic 308 analysis can often reveal the service. 310 3. Design of the Private DNS-SD Discovery Service 312 In this section, we present the design of a two-stage solution that 313 enables private use of DNS-SD, without affecting existing users. The 314 solution is largely based on the architecture proposed in [KW14b] and 315 [K17], which separates the general private discovery problem in three 316 components. The first component is an offline pairing mechanism, 317 which is performed only once per pair of users. It establishes a 318 shared secret over an authenticated channel, allowing devices to 319 authenticate using this secret without user interaction at any later 320 point in time. We use the pairing system proposed in 321 [I-D.ietf-dnssd-pairing]. 323 The further two components are online (in contrast to pairing they 324 are performed anew each time joining a network) and compose the two 325 service discovery stages, namely 327 o Discovery of the Private Discovery Service -- the first stage -- 328 in which hosts discover the Private Discovery Service (PDS), a 329 special service offered by every host supporting our extension. 330 After the discovery, hosts connect to the PSD offered by paired 331 peers. 333 o Actual Service Discovery -- the second stage -- is performed 334 through the Private Discovery Service, which only accepts 335 encrypted messages associated with an authenticated session; thus 336 not compromising privacy. 338 In other words, the hosts first discover paired peers and then 339 directly engage in privacy preserving service discovery. 341 The stages are independent with respect to means used for 342 transmitting the necessary data. While in our extension the messages 343 for the first stage are transmitted using IP multicast, the messages 344 for the second stage are transmitted via unicast. One could also 345 imagine using a Distributed Hash Table for the first stage, being 346 completely independent of multicast. 348 3.1. Device Pairing 350 Any private discovery solution needs to differentiate between 351 authorized devices, which are allowed to get information about 352 discoverable entities, and other devices, which should not be aware 353 of the availability of private entities. The commonly used solution 354 to this problem is establishing a "device pairing". 356 Device pairing has to be performed only once per pair of users. This 357 is important for user-friendliness, as it is the only step that 358 demands user-interaction. After this single pairing, privacy 359 preserving service discovery works fully automatically. In this 360 document, we utilize [I-D.ietf-dnssd-pairing] as the pairing 361 mechanism. 363 The pairing yields a mutually authenticated shared secret, and 364 optionally mutually authenticated public keys or certificates added 365 to a local web of trust. Public key technology has many advantages, 366 but shared secrets are typically easier to handle on small devices. 368 3.2. Discovery of the Private Discovery Service 370 The first stage of service discovery is to check whether instances of 371 compatible Private Discovery Services are available in the local 372 scope. The goal of that stage is to identify devices that share a 373 pairing with the querier, and are available locally. The service 374 instances can be browsed using regular DNS-SD procedures, and then 375 filtered so that only instances offered by paired devices are 376 retained. 378 3.2.1. Obfuscated Instance Names 380 The instance names for the Private Discovery Service are obfuscated, 381 so that authorized peers can associate the instance with its 382 publisher, but unauthorized peers can only observe what looks like a 383 random name. To achieve this, the names are composed as the 384 concatenation of a nonce and a proof, which is composed by hashing 385 the nonce with a pairing key: 387 PrivateInstanceName = | 388 proof = hash(|) 390 The publisher will publish as many instances as it has established 391 pairings. 393 The discovering party that looks for instances of the service will 394 receive lists of advertisements from nodes present on the network. 395 For each advertisement, it will parse the instance name, and then, 396 for each available pairing key, compares the proof to the hash of the 397 nonce concatenated with this pairing key. If there is no match, it 398 discards the instance name. If there is a match, it has discovered a 399 peer. 401 3.2.2. Using a Predictable Nonce 403 Assume that there are N nodes on the local scope, and that each node 404 has on average M pairings. Each node will publish on average M 405 records, and the node engaging in discovery may have to process on 406 average N*M instance names. The discovering node will have to 407 compute on average M potential hashes for each nonce. The number of 408 hash computations would scale as O(N*M*M), which means that it could 409 cause a significant drain of resource in large networks. 411 In order to minimize the amount of computing resource, we suggest 412 that the nonce be derived from the current time, for example set to a 413 representation of the current time rounded to some period. With this 414 convention, receivers can predict the nonces that will appear in the 415 published instances. 417 The publishers will have to create new records at the end of each 418 rounding period. If the rounding period is set too short, they will 419 have to repeat that very often, which is inefficient. On the other 420 hand, if the rounding period is too long, the system may be exposed 421 to replay attacks. We initially proposed a value of about 5 minutes, 422 which would work well for the mDNS variant of DNS-SD. However, this 423 may cause an excessive number of updates for the DNS server based 424 version of DNS-SD. We propose to set a value of about 30 minutes, 425 which seems to be a reasonable compromise. 427 Receivers can pre-calculate all the M relevant proofs once per time 428 interval and then establish a mapping from the corresponding instance 429 names to the pairing data in form of a hash table. These M relevant 430 proofs are the proofs resulting from hashing a host's M pairing keys 431 alongside the current nonce. Each time they receive an instance 432 name, they can test in O(1) time if the received service information 433 is relevant or not. 435 Unix defines a 32 bit time stamp as the number of seconds elapsed 436 since January 1st, 1970 not counting leap seconds. The most 437 significant 20 bits of this 32 bit number represent the number of 438 2048 seconds intervals since the epoch. 2048 seconds correspond to 34 439 minutes and 8 seconds, which is close enough to our design goal of 30 440 minutes. We will thus use this 20 bit number as nonce, which for 441 simplicity will be padded zeroes to 24 bits and encoded in 3 octets. 443 For coping with time skew, receivers pre-calculate proofs for the 444 respective next time interval and store hash tables for the last, the 445 current, and the next time interval. When receiving a service 446 instance name, receivers first check whether the nonce corresponds to 447 the current, the last or the next time interval, and if so, check 448 whether the instance name is in the corresponding hash table. For 449 (approximately) meeting our design goal of 5 min validity, the last 450 time interval may only be considered if the current one is less than 451 half way over and the next time interval may only be considered if 452 the current time interval is more than half way over. 454 Publishers will need to compute O(M) hashes at most once per time 455 stamp interval. If records can be created "on the fly", publishers 456 will only need to perform that computation upon receipt of the first 457 query during a given interval, and cache the computed results for the 458 remainder of the interval. There are however scenarios in which 459 records have to be produced in advance, for example when records are 460 published within a scope defined by a domain name and managed by a 461 "classic" DNS server. In such scenarios, publishers will need to 462 perform the computations and publication exactly once per time stamp 463 interval. 465 3.2.3. Using a Short Proof 467 Devices will have to publish as many instance names as they have 468 peers. The instance names will have to be represented via a text 469 string, which means that the binary concatenation of nonce and proof 470 will have to be encoded using a binary-to-text conversion such as 471 BASE64 ([RFC2045] section 6.8) or BASE32 ([RFC4648] section 6). 473 Using long proofs, such as the full output of SHA256 [RFC4055], would 474 generate fairly long instance names: 48 characters using BASE64, or 475 56 using BASE32. These long names would inflate the network traffic 476 required when discovering the privacy service. They would also limit 477 the number of DNS-SD PTR records that could be packed in a single 478 1500 octet sized packet, to 23 or fewer with BASE64, or 20 or fewer 479 with BASE32. 481 Shorter proofs lead to shorter messages, which is more efficient as 482 long as we do not encounter too many collisions. A collision will 483 happen if the proof computed by the publisher using one key matches a 484 proof computed by a receiver using another key. If a receiver 485 mistakenly believes that a proof fits one of its peers, it will 486 attempt to connect to the service as explained in section Section 4.5 487 but in the absence of the proper pairwise shared key, the connection 488 will fail. This will not create an actual error, but the probability 489 of such events should be kept low. 491 The following table provides the probability that a discovery agent 492 maintaining 100 pairings will observe a collision after receiving 493 100000 advertisement records. It also provides the number of 494 characters required for the encoding of the corresponding instance 495 name in BASE64 or BASE32, assuming 24 bit nonces. 497 +-------+------------+--------+--------+ 498 | Proof | Collisions | BASE64 | BASE32 | 499 +-------+------------+--------+--------+ 500 | 24 | 5.96046% | 8 | 16 | 501 | 32 | 0.02328% | 11 | 16 | 502 | 40 | 0.00009% | 12 | 16 | 503 | 48 | 3.6E-09 | 12 | 16 | 504 | 56 | 1.4E-11 | 15 | 16 | 505 +-------+------------+--------+--------+ 507 Table 1 509 The table shows that for a proof, 24 bits would be too short. 32 bits 510 might be long enough, but the BASE64 encoding requires padding if the 511 input is not an even multiple of 24 bits, and BASE32 requires padding 512 if the input is not a multiple of 40 bits. Given that, the desirable 513 proof lengths are thus 48 bits if using BASE64, or 56 bits if using 514 BASE32. The resulting instance name will be either 12 characters 515 long with BASE64, allowing 54 advertisements in an 1500 byte mDNS 516 message, or 16 characters long with BASE32, allowing 47 517 advertisements per message. 519 In the specification section, we will assume BASE64, and 48 bit 520 proofs composed of the first 6 bytes of a SHA256 hash. 522 3.2.4. Direct Queries 524 The preceding sections assume that the discovery is performed using 525 the classic DNS-SD process, in which a query for all available 526 "instance names" of a service provides a list of PTR records. The 527 discoverer will then select the instance names that correspond to its 528 peers, and request the SRV and TXT records corresponding to the 529 service instance, and then obtain the relevant A or AAAA records. 530 This is generally required in DNS-SD because the instance names are 531 not known in advance, but for the Private Discovery Service the 532 instance names can be predicted, and a more efficient Direct Query 533 method can be used. 535 At a given time, the node engaged in discovery can predict the nonce 536 that its peer will use, since that nonce is composed by rounding the 537 current time. The node can also compute the proofs that its peers 538 might use, since it knows the nonce and the keys. The node can thus 539 build a list of instance names, and directly query the SRV records 540 corresponding to these names. If peers are present, they will answer 541 directly. 543 This "direct query" process will result in fewer network messages 544 than the regular DNS-SD query process in some circumstances, 545 depending on the number of peers per node and the number of nodes 546 publishing the presence discovery service in the desired scope. 548 When using mDNS, it is possible to pack multiple queries in a single 549 broadcast message. Using name compression and 12 characters per 550 instance name, it is possible to pack 70 queries in a 1500 octet mDNS 551 multicast message. It is also possible to request unicast replies to 552 the queries, resulting in significant efficiency gains in wireless 553 networks. 555 3.3. Private Discovery Service 557 The Private Discovery Service discovery allows discovering a list of 558 available paired devices, and verifying that either party knows the 559 corresponding shared secret. At that point, the querier can engage 560 in a series of directed discoveries. 562 We have considered defining an ad-hoc protocol for the private 563 discovery service, but found that just using TLS would be much 564 simpler. The directed Private Discovery Service is just a regular 565 DNS-SD service, accessed over TLS, using the encapsulation of DNS 566 over TLS defined in [RFC7858]. The main difference with plain DNS 567 over TLS is the need for an authentication based on pre-shared keys. 569 We assume that the pairing process has provided each pair of 570 authorized client and server with a shared secret. We can use that 571 shared secret to provide mutual authentication of clients and servers 572 using "Pre-Shared Key" authentication, as defined in [RFC4279] and 573 incorporated in the latest version of TLS [I-D.ietf-tls-tls13]. 575 One difficulty is the reliance on a key identifier in the protocol. 576 For example, in TLS 1.3 the PSK extension is defined as: 578 opaque psk_identity<0..2^16-1>; 580 struct { 581 select (Role) { 582 case client: 583 psk_identity identities<2..2^16-1>; 585 case server: 586 uint16 selected_identity; 587 } 588 } PreSharedKeyExtension 590 According to the protocol, the PSK identity is passed in clear text 591 at the beginning of the key exchange. This is logical, since server 592 and clients need to identify the secret that will be used to protect 593 the connection. But if we used a static identifier for the key, 594 adversaries could use that identifier to track server and clients. 595 The solution is to use a time-varying identifier, constructed exactly 596 like the "proof" described in Section 3.2, by concatenating a nonce 597 and the hash of the nonce with the shared secret. 599 3.3.1. A Note on Private DNS Services 601 Our solution uses a variant of the DNS over TLS protocol [RFC7858] 602 defined by the DNS Private Exchange working group (DPRIVE). DPRIVE 603 further published an UDP variant, DNS over DTLS [RFC8094], which 604 would also be a candidate. 606 DPRIVE and Private Discovery, however, solve two somewhat different 607 problems. While DPRIVE is concerned with the confidentiality of DNS 608 transactions addressing the problems outlined in [RFC7626], DPRIVE 609 does not address the confidentiality or privacy issues with 610 publication of services, and is not a direct solution to DNS-SD 611 privacy: 613 o Discovery queries are scoped by the domain name within which 614 services are published. As nodes move and visit arbitrary 615 networks, there is no guarantee that the domain services for these 616 networks will be accessible using DNS over TLS or DNS over DTLS. 618 o Information placed in the DNS is considered public. Even if the 619 server does support DNS over TLS, third parties will still be able 620 to discover the content of PTR, SRV and TXT records. 622 o Neither DNS over TLS nor DNS over DTLS applies to mDNS. 624 In contrast, we propose using mutual authentication of the client and 625 server as part of the TLS solution, to ensure that only authorized 626 parties learn the presence of a service. 628 3.4. Randomized Host Names 630 Instead of publishing their actual host names in the SRV records, 631 nodes could publish randomized host names. That is the solution 632 argued for in [RFC8117]. 634 Randomized host names will prevent some of the tracking. Host names 635 are typically not visible by the users, and randomizing host names 636 will probably not cause much usability issues. 638 3.5. Timing of Obfuscation and Randomization 640 It is important that the obfuscation of instance names is performed 641 at the right time, and that the obfuscated names change in synchrony 642 with other identifiers, such as MAC Addresses, IP Addresses or host 643 names. If the randomized host name changed but the instance name 644 remained constant, an adversary would have no difficulty linking the 645 old and new host names. Similarly, if IP or MAC addresses changed 646 but host names remained constant, the adversary could link the new 647 addresses to the old ones using the published name. 649 The problem is handled in [RFC8117], which recommends to pick a new 650 random host name at the time of connecting to a new network. New 651 instance names for the Private Discovery Services should be composed 652 at the same time. 654 4. Private Discovery Service Specification 656 The proposed solution uses the following components: 658 o Host name randomization to prevent tracking. 660 o Device pairing yielding pairwise shared secrets. 662 o A Private Discovery Server (PDS) running on each host. 664 o Discovery of the PDS instances using DNS-SD. 666 These components are detailed in the following subsections. 668 4.1. Host Name Randomization 670 Nodes publishing services with DNS-SD and concerned about their 671 privacy MUST use a randomized host name. The randomized name MUST be 672 changed when network connectivity changes, to avoid the correlation 673 issues described in Section 3.5. The randomized host name MUST be 674 used in the SRV records describing the service instance, and the 675 corresponding A or AAAA records MUST be made available through DNS or 676 mDNS, within the same scope as the PTR, SRV and TXT records used by 677 DNS-SD. 679 If the link-layer address of the network connection is properly 680 obfuscated (e.g. using MAC Address Randomization), the Randomized 681 Host Name MAY be computed using the algorithm described in section 682 3.7 of [RFC7844]. If this is not possible, the randomized host name 683 SHOULD be constructed by simply picking a 48 bit random number 684 meeting the Randomness Requirements for Security expressed in 685 [RFC4075], and then use the hexadecimal representation of this number 686 as the obfuscated host name. 688 4.2. Device Pairing 690 Nodes that want to leverage the Private Directory Service for private 691 service discovery among peers MUST share a secret with each of these 692 peers. Each shared secret MUST be a 256 bit randomly chosen number. 693 We RECOMMEND using the pairing mechanism proposed in 694 [I-D.ietf-dnssd-pairing] to establish these secrets. 696 4.3. Private Discovery Server 698 A Private Discovery Server (PDS) is a minimal DNS server running on 699 each host. Its task is to offer resource records corresponding to 700 private services only to authorized peers. These peers MUST share a 701 secret with the host (see Section 4.2). To ensure privacy of the 702 requests, the service is only available over TLS [RFC5246], and the 703 shared secrets are used to mutually authenticate peers and servers. 705 The Private Name Server SHOULD support DNS push notifications 706 [I-D.ietf-dnssd-push], e.g. to facilitate an up-to-date contact list 707 in a chat application without polling. 709 4.3.1. Establishing TLS Connections 711 The PDS MUST only answer queries via DNS over TLS [RFC7858] and MUST 712 use a PSK authenticated TLS handshake [RFC4279]. The client and 713 server SHOULD negotiate a forward secure cipher suite such as DHE-PSK 714 or ECDHE-PSK when available. The shared secret exchanged during 715 pairing MUST be used as PSK. To guarantee interoperability, 716 implementations of the Private Name Server MUST support 717 TLS_PSK_WITH_AES_256_GCM_SHA384. 719 When using the PSK based authentication, the "psk_identity" parameter 720 identifying the pre-shared key MUST be identical to the "Instance 721 Identifier" defined in Section 4.4, i.e. 24 bit nonce and 48 bit 722 proof encoded in BASE64 as 12 character string. The server will use 723 the pairing key associated with this instance identifier. 725 4.4. Publishing Private Discovery Service Instances 727 Nodes that provide the Private Discovery Service SHOULD advertise 728 their availability by publishing instances of the service through 729 DNS-SD. 731 The DNS-SD service type for the Private Discovery Service is 732 "_pds._tcp". 734 Each published instance describes one server and one pairing. In the 735 case where a node manages more than one pairing, it should publish as 736 many instances as necessary to advertise the PDS to all paired peers. 738 Each instance name is composed as follows: 740 pick a 24 bit nonce, set to the 20 most significant bits of the 741 32 bit Unix GMT time padded with 4 zeroes. 743 For example, on August 22, 2017 at 20h 4 min and 54 seconds 744 international time, the Unix 32 bit time had the 745 hexadecimal value 0x599C8E68. The corresponding nonce 746 would be set to the 24 bits: 0x599C80. 748 compute a 48 bit proof: 749 proof = first 48 bits of HASH(|) 751 set the 72 bit binary identifier as the concatenation 752 of nonce and proof 754 set instance_name = BASE64(binary identifier) 756 In this formula, HASH SHOULD be the function SHA256 defined in 757 [RFC4055], and BASE64 is defined in section 6.8 of [RFC2045]. The 758 concatenation of a 24 bit nonce and 48 bit proof result in a 72 bit 759 string. The BASE64 conversion is 12 characters long per [RFC6763]. 761 4.5. Discovering Private Discovery Service Instances 763 Nodes that wish to discover Private Discovery Service Instances 764 SHOULD issue a DNS-SD discovery request for the service type 765 "_pds._tcp". They MAY, as an alternative, use the Direct Discovery 766 procedure defined in Section 4.6. When using the Direct Discovery 767 procedure over mDNS, nodes SHOULD always set the QU-bit (unicast 768 response requested, see [RFC6762] Section 5.4) because responses 769 related to a "_pds._tcp" instance are only relevant for the querying 770 node itself. 772 When nodes send a DNS-SD discovery request, they will receive in 773 response a series of PTR records, each providing the name of one of 774 the instances present in the scope. 776 For each time interval, the querier SHOULD pre-calculate a hash table 777 mapping instance names to pairings according to the following 778 conceptual algorithm: 780 nonce = 20 bit rounded time stamp of the \ 781 respective next time interval padded to \ 782 24 bits with four zeroes 783 for each available pairing 784 retrieve the key Xj of pairing number j 785 compute F = first 48 bits of hash(nonce, Xj) 786 construct the binary instance_name as described \ 787 in the previous section 788 instance_names[nonce][instance_name] = Xj; 790 The querier SHOULD store the hash tables for the previous, the 791 current, and the next time interval. 793 The querier SHOULD examine each instance to see whether it 794 corresponds to one of its available pairings, according to the 795 following conceptual algorithm: 797 for each received instance_name: 798 convert the instance name to binary using BASE64 799 if the conversion fails, 800 discard the instance. 801 if the binary instance length is not 72 bits, 802 discard the instance. 804 nonce = first 24 bits of binary. 806 Check that the 4 least significant bits of the nonce 807 have the value 0, and that the 20 most significant 808 bits of the nonce match the first 20 bits of 809 the current time, or the previous interval (20 bit number 810 minus 1) if the current interval is less than half over, 811 or the next interval (20 bit number plus 1) if the 812 current interval is more than half over. If the 813 nonce does not match an acceptable value, discard 814 the instance. 816 if ((Xj = instance_names[nonce][instance_name]) != null) 817 mark the pairing number j as available 819 The check of the current time is meant to mitigate replay attacks, 820 while not mandating a time synchronization precision better than 15 821 minutes. 823 Once a pairing has been marked available, the querier SHOULD try 824 connecting to the corresponding instance, using the selected key. 825 The connection is likely to succeed, but it MAY fail for a variety of 826 reasons. One of these reasons is the probabilistic nature of the 827 proof, which entails a small chance of "false positive" match. This 828 will occur if the hash of the nonce with two different keys produces 829 the same result. In that case, the TLS connection will fail with an 830 authentication error or a decryption error. 832 4.6. Direct Discovery of Private Discovery Service Instances 834 Nodes that wish to discover Private Discovery Service Instances MAY 835 use the following Direct Discovery procedure instead of the regular 836 DNS-SD Discovery explained in Section 4.5. 838 To perform Direct Discovery, nodes should compose a list of Private 839 Discovery Service Instances Names. There will be one name for each 840 pairing available to the node. The Instance name for each name will 841 be composed of a nonce and a proof, using the algorithm specified in 842 Section 4.4. 844 The querier will issue SRV record queries for each of these names. 845 The queries will only succeed if the corresponding instance is 846 present, in which case a pairing is discovered. After that, the 847 querier SHOULD try connecting to the corresponding instance, as 848 explained in Section 4.4. 850 4.7. Using the Private Discovery Service 852 Once instances of the Private Discovery Service have been discovered, 853 peers can establish TLS connections and send DNS requests over these 854 connections, as specified in DNS-SD. 856 5. Security Considerations 858 This document specifies a method for protecting the privacy of nodes 859 that offer and query for services. This is especially useful when 860 operating in a public space. Hiding the identity of the publishing 861 nodes prevents some forms of "targeting" of high value nodes. 862 However, adversaries can attempt various attacks to break the 863 anonymity of the service, or to deny it. A list of these attacks and 864 their mitigations are described in the following sections. 866 5.1. Attacks Against the Pairing System 868 There are a variety of attacks against pairing systems, which may 869 result in compromised pairing secrets. If an adversary manages to 870 acquire a compromised key, the adversary will be able to perform 871 private service discovery according to Section 4.5. This will allow 872 tracking of the service. The adversary will also be able to discover 873 which private services are available for the compromised pairing. 875 Attacks on pairing systems are detailed in [I-D.ietf-dnssd-pairing]. 877 5.2. Denial of Discovery of the Private Discovery Service 879 The algorithm described in Section 4.5 scales as O(M*N), where M is 880 the number of pairings per node and N is the number of nodes in the 881 local scope. Adversaries can attack this service by publishing 882 "fake" instances, effectively increasing the number N in that scaling 883 equation. 885 Similar attacks can be mounted against DNS-SD: creating fake 886 instances will generally increase the noise in the system and make 887 discovery less usable. Private Discovery Service discovery SHOULD 888 use the same mitigations as DNS-SD. 890 The attack could be amplified if the clients needed to compute proofs 891 for all the nonces presented in Private Discovery Service Instance 892 names. This is mitigated by the specification of nonces as rounded 893 time stamps in Section 4.5. If we assume that timestamps must not be 894 too old, there will be a finite number of valid rounded timestamps at 895 any time. Even if there are many instances present, they would all 896 pick their nonces from this small number of rounded timestamps, and a 897 smart client will make sure that proofs are only computed once per 898 valid time stamp. 900 5.3. Replay Attacks Against Discovery of the Private Discovery Service 902 Adversaries can record the service instance names published by 903 Private Discovery Service instances, and replay them later in 904 different contexts. Peers engaging in discovery can be misled into 905 believing that a paired server is present. They will attempt to 906 connect to the absent peer, and in doing so will disclose their 907 presence in a monitored scope. 909 The binary instance identifiers defined in Section 4.4 start with 24 910 bits encoding the most significant bits of the "UNIX" time. In order 911 to protect against replay attacks, clients SHOULD verify that this 912 time is reasonably recent, as specified in Section 4.5. 914 5.4. Denial of Private Discovery Service 916 The Private Discovery Service is only available through a mutually 917 authenticated TLS connection, which provides state-of-the-art 918 protection mechanisms. However, adversaries can mount a denial of 919 service attack against the service. In the absence of shared 920 secrets, the connections will fail, but the servers will expend some 921 CPU cycles defending against them. 923 To mitigate such attacks, nodes SHOULD restrict the range of network 924 addresses from which they accept connections, matching the expected 925 scope of the service. 927 This mitigation will not prevent denial of service attacks performed 928 by locally connected adversaries; but protecting against local denial 929 of service attacks is generally very difficult. For example, local 930 attackers can also attack mDNS and DNS-SD by generating a large 931 number of multicast requests. 933 5.5. Replay Attacks against the Private Discovery Service 935 Adversaries may record the PSK Key Identifiers used in successful 936 connections to a private discovery service. They could attempt to 937 replay them later against nodes advertising the private service at 938 other times or at other locations. If the PSK identifier is still 939 valid, the server will accept the TLS connection, and in doing so 940 will reveal being the same server observed at a previous time or 941 location. 943 The PSK identifiers defined in Section 4.3.1 start with the 24 most 944 significant bits of the "UNIX" time. In order to mitigate replay 945 attacks, servers SHOULD verify that this time is reasonably recent, 946 and fail the connection if it is too old, or if it occurs too far in 947 the future. 949 The processing of timestamps is however affected by the accuracy of 950 computer clocks. If the check is too strict, reasonable connections 951 could fail. To further mitigate replay attacks, servers MAY record 952 the list of valid PSK identifiers received in a recent past, and fail 953 connections if one of these identifiers is replayed. 955 5.6. Replay attacks and clock synchronization 957 The mitigation of replay attacks relies on verification of the time 958 encoded in the nonce. This verification assumes that the hosts 959 engaged in discovery have a reasonably accurate sense of the current 960 time. 962 5.7. Fingerprinting the number of published instances 964 Adversaries could monitor the number of instances published by a 965 particular device, which in the absence of mitigations will reflect 966 the number of pairings established by that device. This number will 967 probably vary between 1 and maybe 100, providing the adversary with 968 maybe 6 or 7 bits of input in a fingerprinting algorithm. 970 Devices MAY protect against this fingerprinting by publishing a 971 number of "fake" instances in addition to the real ones. The fake 972 instance identifiers will contain the same nonce as the genuine 973 instance identifiers, and random bits instead of the proof. Peers 974 should be able to quickly discard these fake instances, as the proof 975 will not match any of the values that they expect. One plausible 976 padding strategy is to ensure that the total number of published 977 instances, either fake or genuine, matches one of a few values such 978 as 16, 32, 64, or higher powers of 2. 980 6. IANA Considerations 982 This draft does not require any IANA action. 984 7. Acknowledgments 986 This draft results from initial discussions with Dave Thaler, and 987 encouragements from the DNS-SD working group members. We would like 988 to thank Stephane Bortzmeyer and Ted Lemon for their detailed reviews 989 of the working draft. 991 8. References 993 8.1. Normative References 995 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 996 Extensions (MIME) Part One: Format of Internet Message 997 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 998 . 1000 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1001 Requirement Levels", BCP 14, RFC 2119, 1002 DOI 10.17487/RFC2119, March 1997, 1003 . 1005 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 1006 Algorithms and Identifiers for RSA Cryptography for use in 1007 the Internet X.509 Public Key Infrastructure Certificate 1008 and Certificate Revocation List (CRL) Profile", RFC 4055, 1009 DOI 10.17487/RFC4055, June 2005, 1010 . 1012 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 1013 Configuration Option for DHCPv6", RFC 4075, 1014 DOI 10.17487/RFC4075, May 2005, 1015 . 1017 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 1018 Ciphersuites for Transport Layer Security (TLS)", 1019 RFC 4279, DOI 10.17487/RFC4279, December 2005, 1020 . 1022 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1023 (TLS) Protocol Version 1.2", RFC 5246, 1024 DOI 10.17487/RFC5246, August 2008, 1025 . 1027 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1028 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1029 . 1031 8.2. Informative References 1033 [I-D.ietf-dnssd-pairing] 1034 Huitema, C. and D. Kaiser, "Device Pairing Using Short 1035 Authentication Strings", draft-ietf-dnssd-pairing-03 (work 1036 in progress), September 2017. 1038 [I-D.ietf-dnssd-push] 1039 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 1040 draft-ietf-dnssd-push-14 (work in progress), March 2018. 1042 [I-D.ietf-tls-tls13] 1043 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1044 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 1045 March 2018. 1047 [K17] Kaiser, D., "Efficient Privacy-Preserving 1048 Configurationless Service Discovery Supporting Multi-Link 1049 Networks", 2017, 1050 . 1052 [KW14a] Kaiser, D. and M. Waldvogel, "Adding Privacy to Multicast 1053 DNS Service Discovery", DOI 10.1109/TrustCom.2014.107, 1054 2014, . 1057 [KW14b] Kaiser, D. and M. Waldvogel, "Efficient Privacy Preserving 1058 Multicast DNS Service Discovery", 1059 DOI 10.1109/HPCC.2014.141, 2014, 1060 . 1063 [RFC1033] Lottor, M., "Domain Administrators Operations Guide", 1064 RFC 1033, DOI 10.17487/RFC1033, November 1987, 1065 . 1067 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1068 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1069 . 1071 [RFC1035] Mockapetris, P., "Domain names - implementation and 1072 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1073 November 1987, . 1075 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1076 specifying the location of services (DNS SRV)", RFC 2782, 1077 DOI 10.17487/RFC2782, February 2000, 1078 . 1080 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1081 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1082 . 1084 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1085 DOI 10.17487/RFC6762, February 2013, 1086 . 1088 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 1089 DOI 10.17487/RFC7626, August 2015, 1090 . 1092 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 1093 Profiles for DHCP Clients", RFC 7844, 1094 DOI 10.17487/RFC7844, May 2016, 1095 . 1097 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1098 and P. Hoffman, "Specification for DNS over Transport 1099 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1100 2016, . 1102 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 1103 Transport Layer Security (DTLS)", RFC 8094, 1104 DOI 10.17487/RFC8094, February 2017, 1105 . 1107 [RFC8117] Huitema, C., Thaler, D., and R. Winter, "Current Hostname 1108 Practice Considered Harmful", RFC 8117, 1109 DOI 10.17487/RFC8117, March 2017, 1110 . 1112 Authors' Addresses 1114 Christian Huitema 1115 Private Octopus Inc. 1116 Friday Harbor, WA 98250 1117 U.S.A. 1119 Email: huitema@huitema.net 1120 URI: http://privateoctopus.com/ 1121 Daniel Kaiser 1122 University of Konstanz 1123 Konstanz 78457 1124 Germany 1126 Email: daniel.kaiser@uni-konstanz.de