idnits 2.17.1 draft-ietf-dnssd-privacy-05.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 (October 15, 2018) is 1572 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-04 == Outdated reference: draft-ietf-dnssd-prireq has been published as RFC 8882 == Outdated reference: draft-ietf-dnssd-push has been published as RFC 8765 == Outdated reference: draft-ietf-tls-tls13 has been published as RFC 8446 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 1 error (**), 0 flaws (~~), 5 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: April 18, 2019 University of Konstanz 6 October 15, 2018 8 Privacy Extensions for DNS-SD 9 draft-ietf-dnssd-privacy-05 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 Revisions of this draft are currently considered in the DNSSD working 31 group. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 18, 2019. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Design of the Private DNS-SD Discovery Service . . . . . . . 4 70 2.1. Device Pairing . . . . . . . . . . . . . . . . . . . . . 5 71 2.2. Discovery of the Private Discovery Service . . . . . . . 5 72 2.2.1. Obfuscated Instance Names . . . . . . . . . . . . . . 5 73 2.2.2. Using a Predictable Nonce . . . . . . . . . . . . . . 6 74 2.2.3. Using a Short Proof . . . . . . . . . . . . . . . . . 7 75 2.2.4. Direct Queries . . . . . . . . . . . . . . . . . . . 8 76 2.3. Private Discovery Service . . . . . . . . . . . . . . . . 9 77 2.3.1. A Note on Private DNS Services . . . . . . . . . . . 10 78 2.4. Randomized Host Names . . . . . . . . . . . . . . . . . . 11 79 2.5. Timing of Obfuscation and Randomization . . . . . . . . . 11 80 3. Private Discovery Service Specification . . . . . . . . . . . 11 81 3.1. Host Name Randomization . . . . . . . . . . . . . . . . . 12 82 3.2. Device Pairing . . . . . . . . . . . . . . . . . . . . . 12 83 3.3. Private Discovery Server . . . . . . . . . . . . . . . . 12 84 3.3.1. Establishing TLS Connections . . . . . . . . . . . . 12 85 3.4. Publishing Private Discovery Service Instances . . . . . 13 86 3.5. Discovering Private Discovery Service Instances . . . . . 14 87 3.6. Direct Discovery of Private Discovery Service Instances . 15 88 3.7. Using the Private Discovery Service . . . . . . . . . . . 16 89 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 90 4.1. Attacks Against the Pairing System . . . . . . . . . . . 16 91 4.2. Denial of Discovery of the Private Discovery Service . . 16 92 4.3. Replay Attacks Against Discovery of the Private Discovery 93 Service . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 4.4. Denial of Private Discovery Service . . . . . . . . . . . 17 95 4.5. Replay Attacks against the Private Discovery Service . . 17 96 4.6. Replay attacks and clock synchronization . . . . . . . . 18 97 4.7. Fingerprinting the number of published instances . . . . 18 99 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 100 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 101 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 102 7.1. Normative References . . . . . . . . . . . . . . . . . . 19 103 7.2. Informative References . . . . . . . . . . . . . . . . . 20 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 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. Parts of the published information can seriously 113 breach the user's privacy. These privacy issues and potential 114 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 [I-D.ietf-dnssd-prireq], we find 131 that the DNS-SD messages leak identifying information such as the 132 instance name, the host name or service properties. We review the 133 design constraint of a solution in Section 2, and describe the 134 proposed solution in Section 3. 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 The solution presented here relies on 1-1 pairings between clients 142 and servers. Discussions during the IETF 101 in London showed that 143 this requirement of a full mesh of pairings poses some scalability 144 issues, as explained in [I-D.ietf-dnssd-privacyscaling]. The next 145 revision of this draft may propose a different mechanism. 147 1.1. Requirements 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 2. Design of the Private DNS-SD Discovery Service 155 In this section, we present the design of a two-stage solution that 156 enables private use of DNS-SD, without affecting existing users. The 157 solution is largely based on the architecture proposed in [KW14b] and 158 [K17], which separates the general private discovery problem in three 159 components. The first component is an offline pairing mechanism, 160 which is performed only once per pair of users. It establishes a 161 shared secret over an authenticated channel, allowing devices to 162 authenticate using this secret without user interaction at any later 163 point in time. We use the pairing system proposed in 164 [I-D.ietf-dnssd-pairing]. 166 The further two components are online (in contrast to pairing they 167 are performed anew each time joining a network) and compose the two 168 service discovery stages, namely 170 o Discovery of the Private Discovery Service -- the first stage -- 171 in which hosts discover the Private Discovery Service (PDS), a 172 special service offered by every host supporting our extension. 173 After the discovery, hosts connect to the PSD offered by paired 174 peers. 176 o Actual Service Discovery -- the second stage -- is performed 177 through the Private Discovery Service, which only accepts 178 encrypted messages associated with an authenticated session; thus 179 not compromising privacy. 181 In other words, the hosts first discover paired peers and then 182 directly engage in privacy preserving service discovery. 184 The stages are independent with respect to means used for 185 transmitting the necessary data. While in our extension the messages 186 for the first stage are transmitted using IP multicast, the messages 187 for the second stage are transmitted via unicast. One could also 188 imagine using a Distributed Hash Table for the first stage, being 189 completely independent of multicast. 191 2.1. Device Pairing 193 Any private discovery solution needs to differentiate between 194 authorized devices, which are allowed to get information about 195 discoverable entities, and other devices, which should not be aware 196 of the availability of private entities. The commonly used solution 197 to this problem is establishing a "device pairing". 199 Device pairing has to be performed only once per pair of users. This 200 is important for user-friendliness, as it is the only step that 201 demands user-interaction. After this single pairing, privacy 202 preserving service discovery works fully automatically. In this 203 document, we utilize [I-D.ietf-dnssd-pairing] as the pairing 204 mechanism. 206 The pairing yields a mutually authenticated shared secret, and 207 optionally mutually authenticated public keys or certificates added 208 to a local web of trust. Public key technology has many advantages, 209 but shared secrets are typically easier to handle on small devices. 211 2.2. Discovery of the Private Discovery Service 213 The first stage of service discovery is to check whether instances of 214 compatible Private Discovery Services are available in the local 215 scope. The goal of that stage is to identify devices that share a 216 pairing with the querier, and are available locally. The service 217 instances can be browsed using regular DNS-SD procedures, and then 218 filtered so that only instances offered by paired devices are 219 retained. 221 2.2.1. Obfuscated Instance Names 223 The instance names for the Private Discovery Service are obfuscated, 224 so that authorized peers can associate the instance with its 225 publisher, but unauthorized peers can only observe what looks like a 226 random name. To achieve this, the names are composed as the 227 concatenation of a nonce and a proof, which is composed by hashing 228 the nonce with a pairing key: 230 PrivateInstanceName = | 231 proof = hash(|) 233 The publisher will publish as many instances as it has established 234 pairings. 236 The discovering party that looks for instances of the service will 237 receive lists of advertisements from nodes present on the network. 238 For each advertisement, it will parse the instance name, and then, 239 for each available pairing key, compares the proof to the hash of the 240 nonce concatenated with this pairing key. If there is no match, it 241 discards the instance name. If there is a match, it has discovered a 242 peer. 244 2.2.2. Using a Predictable Nonce 246 Assume that there are N nodes on the local scope, and that each node 247 has on average M pairings. Each node will publish on average M 248 records, and the node engaging in discovery may have to process on 249 average N*M instance names. The discovering node will have to 250 compute on average M potential hashes for each nonce. The number of 251 hash computations would scale as O(N*M*M), which means that it could 252 cause a significant drain of resource in large networks. 254 In order to minimize the amount of computing resource, we suggest 255 that the nonce be derived from the current time, for example set to a 256 representation of the current time rounded to some period. With this 257 convention, receivers can predict the nonces that will appear in the 258 published instances. 260 The publishers will have to create new records at the end of each 261 rounding period. If the rounding period is set too short, they will 262 have to repeat that very often, which is inefficient. On the other 263 hand, if the rounding period is too long, the system may be exposed 264 to replay attacks. We initially proposed a value of about 5 minutes, 265 which would work well for the mDNS variant of DNS-SD. However, this 266 may cause an excessive number of updates for the DNS server based 267 version of DNS-SD. We propose to set a value of about 30 minutes, 268 which seems to be a reasonable compromise. 270 Receivers can pre-calculate all the M relevant proofs once per time 271 interval and then establish a mapping from the corresponding instance 272 names to the pairing data in form of a hash table. These M relevant 273 proofs are the proofs resulting from hashing a host's M pairing keys 274 alongside the current nonce. Each time they receive an instance 275 name, they can test in O(1) time if the received service information 276 is relevant or not. 278 Unix defines a 32 bit time stamp as the number of seconds elapsed 279 since January 1st, 1970 not counting leap seconds. The most 280 significant 20 bits of this 32 bit number represent the number of 281 2048 seconds intervals since the epoch. 2048 seconds correspond to 34 282 minutes and 8 seconds, which is close enough to our design goal of 30 283 minutes. We will thus use this 20 bit number as nonce, which for 284 simplicity will be padded zeroes to 24 bits and encoded in 3 octets. 286 For coping with time skew, receivers pre-calculate proofs for the 287 respective next time interval and store hash tables for the last, the 288 current, and the next time interval. When receiving a service 289 instance name, receivers first check whether the nonce corresponds to 290 the current, the last or the next time interval, and if so, check 291 whether the instance name is in the corresponding hash table. For 292 (approximately) meeting our design goal of 5 min validity, the last 293 time interval may only be considered if the current one is less than 294 half way over and the next time interval may only be considered if 295 the current time interval is more than half way over. 297 Publishers will need to compute O(M) hashes at most once per time 298 stamp interval. If records can be created "on the fly", publishers 299 will only need to perform that computation upon receipt of the first 300 query during a given interval, and cache the computed results for the 301 remainder of the interval. There are however scenarios in which 302 records have to be produced in advance, for example when records are 303 published within a scope defined by a domain name and managed by a 304 "classic" DNS server. In such scenarios, publishers will need to 305 perform the computations and publication exactly once per time stamp 306 interval. 308 2.2.3. Using a Short Proof 310 Devices will have to publish as many instance names as they have 311 peers. The instance names will have to be represented via a text 312 string, which means that the binary concatenation of nonce and proof 313 will have to be encoded using a binary-to-text conversion such as 314 BASE64 ([RFC2045] section 6.8) or BASE32 ([RFC4648] section 6). 316 Using long proofs, such as the full output of SHA256 [RFC4055], would 317 generate fairly long instance names: 48 characters using BASE64, or 318 56 using BASE32. These long names would inflate the network traffic 319 required when discovering the privacy service. They would also limit 320 the number of DNS-SD PTR records that could be packed in a single 321 1500 octet sized packet, to 23 or fewer with BASE64, or 20 or fewer 322 with BASE32. 324 Shorter proofs lead to shorter messages, which is more efficient as 325 long as we do not encounter too many collisions. A collision will 326 happen if the proof computed by the publisher using one key matches a 327 proof computed by a receiver using another key. If a receiver 328 mistakenly believes that a proof fits one of its peers, it will 329 attempt to connect to the service as explained in section Section 3.5 330 but in the absence of the proper pairwise shared key, the connection 331 will fail. This will not create an actual error, but the probability 332 of such events should be kept low. 334 The following table provides the probability that a discovery agent 335 maintaining 100 pairings will observe a collision after receiving 336 100000 advertisement records. It also provides the number of 337 characters required for the encoding of the corresponding instance 338 name in BASE64 or BASE32, assuming 24 bit nonces. 340 +-------+------------+--------+--------+ 341 | Proof | Collisions | BASE64 | BASE32 | 342 +-------+------------+--------+--------+ 343 | 24 | 5.96046% | 8 | 16 | 344 | 32 | 0.02328% | 11 | 16 | 345 | 40 | 0.00009% | 12 | 16 | 346 | 48 | 3.6E-09 | 12 | 16 | 347 | 56 | 1.4E-11 | 15 | 16 | 348 +-------+------------+--------+--------+ 350 Table 1 352 The table shows that for a proof, 24 bits would be too short. 32 bits 353 might be long enough, but the BASE64 encoding requires padding if the 354 input is not an even multiple of 24 bits, and BASE32 requires padding 355 if the input is not a multiple of 40 bits. Given that, the desirable 356 proof lengths are thus 48 bits if using BASE64, or 56 bits if using 357 BASE32. The resulting instance name will be either 12 characters 358 long with BASE64, allowing 54 advertisements in an 1500 byte mDNS 359 message, or 16 characters long with BASE32, allowing 47 360 advertisements per message. 362 In the specification section, we will assume BASE64, and 48 bit 363 proofs composed of the first 6 bytes of a SHA256 hash. 365 2.2.4. Direct Queries 367 The preceding sections assume that the discovery is performed using 368 the classic DNS-SD process, in which a query for all available 369 "instance names" of a service provides a list of PTR records. The 370 discoverer will then select the instance names that correspond to its 371 peers, and request the SRV and TXT records corresponding to the 372 service instance, and then obtain the relevant A or AAAA records. 373 This is generally required in DNS-SD because the instance names are 374 not known in advance, but for the Private Discovery Service the 375 instance names can be predicted, and a more efficient Direct Query 376 method can be used. 378 At a given time, the node engaged in discovery can predict the nonce 379 that its peer will use, since that nonce is composed by rounding the 380 current time. The node can also compute the proofs that its peers 381 might use, since it knows the nonce and the keys. The node can thus 382 build a list of instance names, and directly query the SRV records 383 corresponding to these names. If peers are present, they will answer 384 directly. 386 This "direct query" process will result in fewer network messages 387 than the regular DNS-SD query process in some circumstances, 388 depending on the number of peers per node and the number of nodes 389 publishing the presence discovery service in the desired scope. 391 When using mDNS, it is possible to pack multiple queries in a single 392 broadcast message. Using name compression and 12 characters per 393 instance name, it is possible to pack 70 queries in a 1500 octet mDNS 394 multicast message. It is also possible to request unicast replies to 395 the queries, resulting in significant efficiency gains in wireless 396 networks. 398 2.3. Private Discovery Service 400 The Private Discovery Service discovery allows discovering a list of 401 available paired devices, and verifying that either party knows the 402 corresponding shared secret. At that point, the querier can engage 403 in a series of directed discoveries. 405 We have considered defining an ad-hoc protocol for the private 406 discovery service, but found that just using TLS would be much 407 simpler. The directed Private Discovery Service is just a regular 408 DNS-SD service, accessed over TLS, using the encapsulation of DNS 409 over TLS defined in [RFC7858]. The main difference with plain DNS 410 over TLS is the need for an authentication based on pre-shared keys. 412 We assume that the pairing process has provided each pair of 413 authorized client and server with a shared secret. We can use that 414 shared secret to provide mutual authentication of clients and servers 415 using "Pre-Shared Key" authentication, as defined in [RFC4279] and 416 incorporated in the latest version of TLS [I-D.ietf-tls-tls13]. 418 One difficulty is the reliance on a key identifier in the protocol. 419 For example, in TLS 1.3 the PSK extension is defined as: 421 opaque psk_identity<0..2^16-1>; 423 struct { 424 select (Role) { 425 case client: 426 psk_identity identities<2..2^16-1>; 428 case server: 429 uint16 selected_identity; 430 } 431 } PreSharedKeyExtension 433 According to the protocol, the PSK identity is passed in clear text 434 at the beginning of the key exchange. This is logical, since server 435 and clients need to identify the secret that will be used to protect 436 the connection. But if we used a static identifier for the key, 437 adversaries could use that identifier to track server and clients. 438 The solution is to use a time-varying identifier, constructed exactly 439 like the "proof" described in Section 2.2, by concatenating a nonce 440 and the hash of the nonce with the shared secret. 442 2.3.1. A Note on Private DNS Services 444 Our solution uses a variant of the DNS over TLS protocol [RFC7858] 445 defined by the DNS Private Exchange working group (DPRIVE). DPRIVE 446 further published an UDP variant, DNS over DTLS [RFC8094], which 447 would also be a candidate. 449 DPRIVE and Private Discovery, however, solve two somewhat different 450 problems. While DPRIVE is concerned with the confidentiality of DNS 451 transactions addressing the problems outlined in [RFC7626], DPRIVE 452 does not address the confidentiality or privacy issues with 453 publication of services, and is not a direct solution to DNS-SD 454 privacy: 456 o Discovery queries are scoped by the domain name within which 457 services are published. As nodes move and visit arbitrary 458 networks, there is no guarantee that the domain services for these 459 networks will be accessible using DNS over TLS or DNS over DTLS. 461 o Information placed in the DNS is considered public. Even if the 462 server does support DNS over TLS, third parties will still be able 463 to discover the content of PTR, SRV and TXT records. 465 o Neither DNS over TLS nor DNS over DTLS applies to mDNS. 467 In contrast, we propose using mutual authentication of the client and 468 server as part of the TLS solution, to ensure that only authorized 469 parties learn the presence of a service. 471 2.4. Randomized Host Names 473 Instead of publishing their actual host names in the SRV records, 474 nodes could publish randomized host names. That is the solution 475 argued for in [RFC8117]. 477 Randomized host names will prevent some of the tracking. Host names 478 are typically not visible by the users, and randomizing host names 479 will probably not cause much usability issues. 481 2.5. Timing of Obfuscation and Randomization 483 It is important that the obfuscation of instance names is performed 484 at the right time, and that the obfuscated names change in synchrony 485 with other identifiers, such as MAC Addresses, IP Addresses or host 486 names. If the randomized host name changed but the instance name 487 remained constant, an adversary would have no difficulty linking the 488 old and new host names. Similarly, if IP or MAC addresses changed 489 but host names remained constant, the adversary could link the new 490 addresses to the old ones using the published name. 492 The problem is handled in [RFC8117], which recommends to pick a new 493 random host name at the time of connecting to a new network. New 494 instance names for the Private Discovery Services should be composed 495 at the same time. 497 3. Private Discovery Service Specification 499 The proposed solution uses the following components: 501 o Host name randomization to prevent tracking. 503 o Device pairing yielding pairwise shared secrets. 505 o A Private Discovery Server (PDS) running on each host. 507 o Discovery of the PDS instances using DNS-SD. 509 These components are detailed in the following subsections. 511 3.1. Host Name Randomization 513 Nodes publishing services with DNS-SD and concerned about their 514 privacy MUST use a randomized host name. The randomized name MUST be 515 changed when network connectivity changes, to avoid the correlation 516 issues described in Section 2.5. The randomized host name MUST be 517 used in the SRV records describing the service instance, and the 518 corresponding A or AAAA records MUST be made available through DNS or 519 mDNS, within the same scope as the PTR, SRV and TXT records used by 520 DNS-SD. 522 If the link-layer address of the network connection is properly 523 obfuscated (e.g. using MAC Address Randomization), the Randomized 524 Host Name MAY be computed using the algorithm described in section 525 3.7 of [RFC7844]. If this is not possible, the randomized host name 526 SHOULD be constructed by simply picking a 48 bit random number 527 meeting the Randomness Requirements for Security expressed in 528 [RFC4075], and then use the hexadecimal representation of this number 529 as the obfuscated host name. 531 3.2. Device Pairing 533 Nodes that want to leverage the Private Directory Service for private 534 service discovery among peers MUST share a secret with each of these 535 peers. Each shared secret MUST be a 256 bit randomly chosen number. 536 We RECOMMEND using the pairing mechanism proposed in 537 [I-D.ietf-dnssd-pairing] to establish these secrets. 539 3.3. Private Discovery Server 541 A Private Discovery Server (PDS) is a minimal DNS server running on 542 each host. Its task is to offer resource records corresponding to 543 private services only to authorized peers. These peers MUST share a 544 secret with the host (see Section 3.2). To ensure privacy of the 545 requests, the service is only available over TLS [RFC5246], and the 546 shared secrets are used to mutually authenticate peers and servers. 548 The Private Name Server SHOULD support DNS push notifications 549 [I-D.ietf-dnssd-push], e.g. to facilitate an up-to-date contact list 550 in a chat application without polling. 552 3.3.1. Establishing TLS Connections 554 The PDS MUST only answer queries via DNS over TLS [RFC7858] and MUST 555 use a PSK authenticated TLS handshake [RFC4279]. The client and 556 server SHOULD negotiate a forward secure cipher suite such as DHE-PSK 557 or ECDHE-PSK when available. The shared secret exchanged during 558 pairing MUST be used as PSK. To guarantee interoperability, 559 implementations of the Private Name Server MUST support 560 TLS_PSK_WITH_AES_256_GCM_SHA384. 562 When using the PSK based authentication, the "psk_identity" parameter 563 identifying the pre-shared key MUST be identical to the "Instance 564 Identifier" defined in Section 3.4, i.e. 24 bit nonce and 48 bit 565 proof encoded in BASE64 as 12 character string. The server will use 566 the pairing key associated with this instance identifier. 568 3.4. Publishing Private Discovery Service Instances 570 Nodes that provide the Private Discovery Service SHOULD advertise 571 their availability by publishing instances of the service through 572 DNS-SD. 574 The DNS-SD service type for the Private Discovery Service is 575 "_pds._tcp". 577 Each published instance describes one server and one pairing. In the 578 case where a node manages more than one pairing, it should publish as 579 many instances as necessary to advertise the PDS to all paired peers. 581 Each instance name is composed as follows: 583 pick a 24 bit nonce, set to the 20 most significant bits of the 584 32 bit Unix GMT time padded with 4 zeroes. 586 For example, on August 22, 2017 at 20h 4 min and 54 seconds 587 international time, the Unix 32 bit time had the 588 hexadecimal value 0x599C8E68. The corresponding nonce 589 would be set to the 24 bits: 0x599C80. 591 compute a 48 bit proof: 592 proof = first 48 bits of HASH(|) 594 set the 72 bit binary identifier as the concatenation 595 of nonce and proof 597 set instance_name = BASE64(binary identifier) 599 In this formula, HASH SHOULD be the function SHA256 defined in 600 [RFC4055], and BASE64 is defined in section 6.8 of [RFC2045]. The 601 concatenation of a 24 bit nonce and 48 bit proof result in a 72 bit 602 string. The BASE64 conversion is 12 characters long per [RFC6763]. 604 3.5. Discovering Private Discovery Service Instances 606 Nodes that wish to discover Private Discovery Service Instances 607 SHOULD issue a DNS-SD discovery request for the service type 608 "_pds._tcp". They MAY, as an alternative, use the Direct Discovery 609 procedure defined in Section 3.6. When using the Direct Discovery 610 procedure over mDNS, nodes SHOULD always set the QU-bit (unicast 611 response requested, see [RFC6762] Section 5.4) because responses 612 related to a "_pds._tcp" instance are only relevant for the querying 613 node itself. 615 When nodes send a DNS-SD discovery request, they will receive in 616 response a series of PTR records, each providing the name of one of 617 the instances present in the scope. 619 For each time interval, the querier SHOULD pre-calculate a hash table 620 mapping instance names to pairings according to the following 621 conceptual algorithm: 623 nonce = 20 bit rounded time stamp of the \ 624 respective next time interval padded to \ 625 24 bits with four zeroes 626 for each available pairing 627 retrieve the key Xj of pairing number j 628 compute F = first 48 bits of hash(nonce, Xj) 629 construct the binary instance_name as described \ 630 in the previous section 631 instance_names[nonce][instance_name] = Xj; 633 The querier SHOULD store the hash tables for the previous, the 634 current, and the next time interval. 636 The querier SHOULD examine each instance to see whether it 637 corresponds to one of its available pairings, according to the 638 following conceptual algorithm: 640 for each received instance_name: 641 convert the instance name to binary using BASE64 642 if the conversion fails, 643 discard the instance. 644 if the binary instance length is not 72 bits, 645 discard the instance. 647 nonce = first 24 bits of binary. 649 Check that the 4 least significant bits of the nonce 650 have the value 0, and that the 20 most significant 651 bits of the nonce match the first 20 bits of 652 the current time, or the previous interval (20 bit number 653 minus 1) if the current interval is less than half over, 654 or the next interval (20 bit number plus 1) if the 655 current interval is more than half over. If the 656 nonce does not match an acceptable value, discard 657 the instance. 659 if ((Xj = instance_names[nonce][instance_name]) != null) 660 mark the pairing number j as available 662 The check of the current time is meant to mitigate replay attacks, 663 while not mandating a time synchronization precision better than 15 664 minutes. 666 Once a pairing has been marked available, the querier SHOULD try 667 connecting to the corresponding instance, using the selected key. 668 The connection is likely to succeed, but it MAY fail for a variety of 669 reasons. One of these reasons is the probabilistic nature of the 670 proof, which entails a small chance of "false positive" match. This 671 will occur if the hash of the nonce with two different keys produces 672 the same result. In that case, the TLS connection will fail with an 673 authentication error or a decryption error. 675 3.6. Direct Discovery of Private Discovery Service Instances 677 Nodes that wish to discover Private Discovery Service Instances MAY 678 use the following Direct Discovery procedure instead of the regular 679 DNS-SD Discovery explained in Section 3.5. 681 To perform Direct Discovery, nodes should compose a list of Private 682 Discovery Service Instances Names. There will be one name for each 683 pairing available to the node. The Instance name for each name will 684 be composed of a nonce and a proof, using the algorithm specified in 685 Section 3.4. 687 The querier will issue SRV record queries for each of these names. 688 The queries will only succeed if the corresponding instance is 689 present, in which case a pairing is discovered. After that, the 690 querier SHOULD try connecting to the corresponding instance, as 691 explained in Section 3.4. 693 3.7. Using the Private Discovery Service 695 Once instances of the Private Discovery Service have been discovered, 696 peers can establish TLS connections and send DNS requests over these 697 connections, as specified in DNS-SD. 699 4. Security Considerations 701 This document specifies a method for protecting the privacy of nodes 702 that offer and query for services. This is especially useful when 703 operating in a public space. Hiding the identity of the publishing 704 nodes prevents some forms of "targeting" of high value nodes. 705 However, adversaries can attempt various attacks to break the 706 anonymity of the service, or to deny it. A list of these attacks and 707 their mitigations are described in the following sections. 709 4.1. Attacks Against the Pairing System 711 There are a variety of attacks against pairing systems, which may 712 result in compromised pairing secrets. If an adversary manages to 713 acquire a compromised key, the adversary will be able to perform 714 private service discovery according to Section 3.5. This will allow 715 tracking of the service. The adversary will also be able to discover 716 which private services are available for the compromised pairing. 718 Attacks on pairing systems are detailed in [I-D.ietf-dnssd-pairing]. 720 4.2. Denial of Discovery of the Private Discovery Service 722 The algorithm described in Section 3.5 scales as O(M*N), where M is 723 the number of pairings per node and N is the number of nodes in the 724 local scope. Adversaries can attack this service by publishing 725 "fake" instances, effectively increasing the number N in that scaling 726 equation. 728 Similar attacks can be mounted against DNS-SD: creating fake 729 instances will generally increase the noise in the system and make 730 discovery less usable. Private Discovery Service discovery SHOULD 731 use the same mitigations as DNS-SD. 733 The attack could be amplified if the clients needed to compute proofs 734 for all the nonces presented in Private Discovery Service Instance 735 names. This is mitigated by the specification of nonces as rounded 736 time stamps in Section 3.5. If we assume that timestamps must not be 737 too old, there will be a finite number of valid rounded timestamps at 738 any time. Even if there are many instances present, they would all 739 pick their nonces from this small number of rounded timestamps, and a 740 smart client will make sure that proofs are only computed once per 741 valid time stamp. 743 4.3. Replay Attacks Against Discovery of the Private Discovery Service 745 Adversaries can record the service instance names published by 746 Private Discovery Service instances, and replay them later in 747 different contexts. Peers engaging in discovery can be misled into 748 believing that a paired server is present. They will attempt to 749 connect to the absent peer, and in doing so will disclose their 750 presence in a monitored scope. 752 The binary instance identifiers defined in Section 3.4 start with 24 753 bits encoding the most significant bits of the "UNIX" time. In order 754 to protect against replay attacks, clients SHOULD verify that this 755 time is reasonably recent, as specified in Section 3.5. 757 4.4. Denial of Private Discovery Service 759 The Private Discovery Service is only available through a mutually 760 authenticated TLS connection, which provides state-of-the-art 761 protection mechanisms. However, adversaries can mount a denial of 762 service attack against the service. In the absence of shared 763 secrets, the connections will fail, but the servers will expend some 764 CPU cycles defending against them. 766 To mitigate such attacks, nodes SHOULD restrict the range of network 767 addresses from which they accept connections, matching the expected 768 scope of the service. 770 This mitigation will not prevent denial of service attacks performed 771 by locally connected adversaries; but protecting against local denial 772 of service attacks is generally very difficult. For example, local 773 attackers can also attack mDNS and DNS-SD by generating a large 774 number of multicast requests. 776 4.5. Replay Attacks against the Private Discovery Service 778 Adversaries may record the PSK Key Identifiers used in successful 779 connections to a private discovery service. They could attempt to 780 replay them later against nodes advertising the private service at 781 other times or at other locations. If the PSK identifier is still 782 valid, the server will accept the TLS connection, and in doing so 783 will reveal being the same server observed at a previous time or 784 location. 786 The PSK identifiers defined in Section 3.3.1 start with the 24 most 787 significant bits of the "UNIX" time. In order to mitigate replay 788 attacks, servers SHOULD verify that this time is reasonably recent, 789 and fail the connection if it is too old, or if it occurs too far in 790 the future. 792 The processing of timestamps is however affected by the accuracy of 793 computer clocks. If the check is too strict, reasonable connections 794 could fail. To further mitigate replay attacks, servers MAY record 795 the list of valid PSK identifiers received in a recent past, and fail 796 connections if one of these identifiers is replayed. 798 4.6. Replay attacks and clock synchronization 800 The mitigation of replay attacks relies on verification of the time 801 encoded in the nonce. This verification assumes that the hosts 802 engaged in discovery have a reasonably accurate sense of the current 803 time. 805 4.7. Fingerprinting the number of published instances 807 Adversaries could monitor the number of instances published by a 808 particular device, which in the absence of mitigations will reflect 809 the number of pairings established by that device. This number will 810 probably vary between 1 and maybe 100, providing the adversary with 811 maybe 6 or 7 bits of input in a fingerprinting algorithm. 813 Devices MAY protect against this fingerprinting by publishing a 814 number of "fake" instances in addition to the real ones. The fake 815 instance identifiers will contain the same nonce as the genuine 816 instance identifiers, and random bits instead of the proof. Peers 817 should be able to quickly discard these fake instances, as the proof 818 will not match any of the values that they expect. One plausible 819 padding strategy is to ensure that the total number of published 820 instances, either fake or genuine, matches one of a few values such 821 as 16, 32, 64, or higher powers of 2. 823 5. IANA Considerations 825 This draft does not require any IANA action. 827 6. Acknowledgments 829 This draft results from initial discussions with Dave Thaler, and 830 encouragements from the DNS-SD working group members. We would like 831 to thank Stephane Bortzmeyer and Ted Lemon for their detailed reviews 832 of the working draft. 834 7. References 836 7.1. Normative References 838 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 839 Extensions (MIME) Part One: Format of Internet Message 840 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 841 . 843 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 844 Requirement Levels", BCP 14, RFC 2119, 845 DOI 10.17487/RFC2119, March 1997, 846 . 848 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 849 Algorithms and Identifiers for RSA Cryptography for use in 850 the Internet X.509 Public Key Infrastructure Certificate 851 and Certificate Revocation List (CRL) Profile", RFC 4055, 852 DOI 10.17487/RFC4055, June 2005, 853 . 855 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 856 Configuration Option for DHCPv6", RFC 4075, 857 DOI 10.17487/RFC4075, May 2005, 858 . 860 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 861 Ciphersuites for Transport Layer Security (TLS)", 862 RFC 4279, DOI 10.17487/RFC4279, December 2005, 863 . 865 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 866 (TLS) Protocol Version 1.2", RFC 5246, 867 DOI 10.17487/RFC5246, August 2008, 868 . 870 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 871 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 872 . 874 7.2. Informative References 876 [I-D.ietf-dnssd-pairing] 877 Huitema, C. and D. Kaiser, "Device Pairing Using Short 878 Authentication Strings", draft-ietf-dnssd-pairing-04 (work 879 in progress), April 2018. 881 [I-D.ietf-dnssd-prireq] 882 Huitema, C., "DNS-SD Privacy and Security Requirements", 883 draft-ietf-dnssd-prireq-00 (work in progress), September 884 2018. 886 [I-D.ietf-dnssd-privacyscaling] 887 Huitema, C., "DNS-SD Privacy Scaling Tradeoffs", draft- 888 ietf-dnssd-privacyscaling-00 (work in progress), September 889 2018. 891 [I-D.ietf-dnssd-push] 892 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 893 draft-ietf-dnssd-push-15 (work in progress), September 894 2018. 896 [I-D.ietf-tls-tls13] 897 Rescorla, E., "The Transport Layer Security (TLS) Protocol 898 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 899 March 2018. 901 [K17] Kaiser, D., "Efficient Privacy-Preserving 902 Configurationless Service Discovery Supporting Multi-Link 903 Networks", 2017, 904 . 906 [KW14a] Kaiser, D. and M. Waldvogel, "Adding Privacy to Multicast 907 DNS Service Discovery", DOI 10.1109/TrustCom.2014.107, 908 2014, . 911 [KW14b] Kaiser, D. and M. Waldvogel, "Efficient Privacy Preserving 912 Multicast DNS Service Discovery", 913 DOI 10.1109/HPCC.2014.141, 2014, 914 . 917 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 918 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 919 . 921 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 922 DOI 10.17487/RFC6762, February 2013, 923 . 925 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 926 DOI 10.17487/RFC7626, August 2015, 927 . 929 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 930 Profiles for DHCP Clients", RFC 7844, 931 DOI 10.17487/RFC7844, May 2016, 932 . 934 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 935 and P. Hoffman, "Specification for DNS over Transport 936 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 937 2016, . 939 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 940 Transport Layer Security (DTLS)", RFC 8094, 941 DOI 10.17487/RFC8094, February 2017, 942 . 944 [RFC8117] Huitema, C., Thaler, D., and R. Winter, "Current Hostname 945 Practice Considered Harmful", RFC 8117, 946 DOI 10.17487/RFC8117, March 2017, 947 . 949 Authors' Addresses 951 Christian Huitema 952 Private Octopus Inc. 953 Friday Harbor, WA 98250 954 U.S.A. 956 Email: huitema@huitema.net 957 URI: http://privateoctopus.com/ 959 Daniel Kaiser 960 University of Konstanz 961 Konstanz 78457 962 Germany 964 Email: daniel.kaiser@uni-konstanz.de