idnits 2.17.1 draft-ietf-dnssd-privacy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2016) is 2739 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '4' on line 577 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-25) exists of draft-ietf-dnssd-push-08 == Outdated reference: A later version (-15) exists of draft-ietf-dprive-dnsodtls-12 == Outdated reference: A later version (-05) exists of draft-ietf-intarea-hostname-practice-03 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-18 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Huitema 3 Internet-Draft 4 Intended status: Standards Track D. Kaiser 5 Expires: April 29, 2017 University of Konstanz 6 October 26, 2016 8 Privacy Extensions for DNS-SD 9 draft-ietf-dnssd-privacy-00.txt 11 Abstract 13 DNS-SD (DNS Service Discovery) normally discloses information about 14 both the devices offering services and the devices requesting 15 services. This information includes host names, network parameters, 16 and possibly a further description of the corresponding service 17 instance. Especially when mobile devices engage in DNS Service 18 Discovery over Multicast DNS at a public hotspot, a serious privacy 19 problem arises. 21 We propose to solve this problem by a two-stage approach. In the 22 first stage, hosts discover Private Discovery Service Instances via 23 DNS-SD using special formats to protect their privacy. These service 24 instances correspond to Private Discovery Servers running on peers. 25 In the second stage, hosts directly query these Private Discovery 26 Servers via DNS-SD over TLS. A pairwise shared secret necessary to 27 establish these connections is only known to hosts authorized by a 28 pairing system. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 29, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Privacy Implications of DNS-SD . . . . . . . . . . . . . . . 3 67 2.1. Privacy Implication of Publishing Service Instance Names 4 68 2.2. Privacy Implication of Publishing Node Names . . . . . . 5 69 2.3. Privacy Implication of Publishing Service Attributes . . 5 70 2.4. Device Fingerprinting . . . . . . . . . . . . . . . . . . 6 71 2.5. Privacy Implication of Discovering Services . . . . . . . 6 72 3. Design of the Private DNS-SD Discovery Service . . . . . . . 7 73 3.1. Device Pairing . . . . . . . . . . . . . . . . . . . . . 7 74 3.2. Discovery of the Private Discovery Service . . . . . . . 8 75 3.3. Private Discovery Service . . . . . . . . . . . . . . . . 9 76 3.3.1. A Note on Private DNS Services . . . . . . . . . . . 10 77 3.4. Randomized Host Names . . . . . . . . . . . . . . . . . . 11 78 3.5. Timing of Obfuscation and Randomization . . . . . . . . . 11 79 4. Private Discovery Service Specification . . . . . . . . . . . 11 80 4.1. Host Name Randomization . . . . . . . . . . . . . . . . . 12 81 4.2. Device Pairing . . . . . . . . . . . . . . . . . . . . . 12 82 4.3. Private Discovery Server . . . . . . . . . . . . . . . . 12 83 4.3.1. Establishing TLS Connections . . . . . . . . . . . . 13 84 4.4. Publishing Private Discovery Service Instances . . . . . 14 85 4.5. Discovering Private Discovery Service Instances . . . . . 14 86 4.6. Using the Private Discovery Service . . . . . . . . . . . 15 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 88 5.1. Attacks Against the Pairing System . . . . . . . . . . . 15 89 5.2. Denial of Discovery of the Private Discovery Service . . 16 90 5.3. Replay Attacks Against Discovery of the Private Discovery 91 Service . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 5.4. Denial of Private Discovery Service . . . . . . . . . . . 16 93 5.5. Replay Attacks against the Private Discovery Service . . 17 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 95 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 97 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 98 8.2. Informative References . . . . . . . . . . . . . . . . . 18 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 101 1. Introduction 103 DNS-SD [RFC6763] enables distribution and discovery in local networks 104 without configuration. It is very convenient for users, but it 105 requires the public exposure of the offering and requesting 106 identities along with information about the offered and requested 107 services. Some of the information published by the announcements can 108 be very revealing. These privacy issues and potential solutions are 109 discussed in [KW14a] and [KW14b]. 111 There are cases when nodes connected to a network want to provide or 112 consume services without exposing their identity to the other parties 113 connected to the same network. Consider for example a traveler 114 wanting to upload pictures from a phone to a laptop when connected to 115 the Wi-Fi network of an Internet cafe, or two travelers who want to 116 share files between their laptops when waiting for their plane in an 117 airport lounge. 119 We expect that these exchanges will start with a discovery procedure 120 using DNS-SD [RFC6763]. One of the devices will publish the 121 availability of a service, such as a picture library or a file store 122 in our examples. The user of the other device will discover this 123 service, and then connect to it. 125 When analyzing these scenarios in Section 2, we find that the DNS-SD 126 messages leak identifying information such as the instance name, the 127 host name or service properties. We review the design constraint of 128 a solution in Section 3, and describe the proposed solution in 129 Section 4. 131 1.1. Requirements 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 2. Privacy Implications of DNS-SD 139 DNS-Based Service Discovery (DNS-SD) is defined in [RFC6763]. It 140 allows nodes to publish the availability of an instance of a service 141 by inserting specific records in the DNS ([RFC1033], [RFC1034], 142 [RFC1035]) or by publishing these records locally using multicast DNS 143 (mDNS) [RFC6762]. Available services are described using three types 144 of records: 146 PTR Record: Associates a service type in the domain with an 147 "instance" name of this service type. 149 SRV Record: Provides the node name, port number, priority and weight 150 associated with the service instance, in conformance with 151 [RFC2782]. 153 TXT Record: Provides a set of attribute-value pairs describing 154 specific properties of the service instance. 156 In the remaining subsections, we will review the privacy issues 157 related to publishing instance names, node names, service attributes 158 and other data, as well as review the implications of using the 159 discovery service as a client. 161 2.1. Privacy Implication of Publishing Service Instance Names 163 In the first phase of discovery, the client obtains all the PTR 164 records associated with a service type in a given naming domain. 165 Each PTR record contains a Service Instance Name defined in Section 4 166 of [RFC6763]: 168 Service Instance Name = . . 170 The portion of the Service Instance Name is meant to 171 convey enough information for users of discovery clients to easily 172 select the desired service instance. Nodes that use DNS-SD over mDNS 173 [RFC6762] in a mobile environment will rely on the specificity of the 174 instance name to identify the desired service instance. In our 175 example of users wanting to upload pictures to a laptop in an 176 Internet Cafe, the list of available service instances may look like: 178 Alice's Images . _imageStore._tcp . local 179 Alice's Mobile Phone . _presence._tcp . local 180 Alice's Notebook . _presence._tcp . local 181 Bob's Notebook . _presence._tcp . local 182 Carol's Notebook . _presence._tcp . local 184 Alice will see the list on her phone and understand intuitively that 185 she should pick the first item. The discovery will "just work". 187 However, DNS-SD/mDNS will reveal to anybody that Alice is currently 188 visiting the Internet Cafe. It further discloses the fact that she 189 uses two devices, shares an image store, and uses a chat application 190 supporting the _presence protocol on both of her devices. She might 191 currently chat with Bob or Carol, as they are also using a _presence 192 supporting chat application. This information is not just available 193 to devices actively browsing for and offering services, but to 194 anybody passively listing to the network traffic. 196 2.2. Privacy Implication of Publishing Node Names 198 The SRV records contain the DNS name of the node publishing the 199 service. Typical implementations construct this DNS name by 200 concatenating the "host name" of the node with the name of the local 201 domain. The privacy implications of this practice are reviewed in 202 [I-D.ietf-intarea-hostname-practice]. Depending on naming practices, 203 the host name is either a strong identifier of the device, or at a 204 minimum a partial identifier. It enables tracking of the device, and 205 by extension of the device's owner. 207 2.3. Privacy Implication of Publishing Service Attributes 209 The TXT record's attribute and value pairs contain information on the 210 characteristics of the corresponding service instance. This in turn 211 reveals information about the devices that publish services. The 212 amount of information varies widely with the particular service and 213 its implementation: 215 o Some attributes like the paper size available in a printer, are 216 the same on many devices, and thus only provide limited 217 information to a tracker. 219 o Attributes that have freeform values, such as the name of a 220 directory, may reveal much more information. 222 Combinations of attributes have more information power than specific 223 attributes, and can potentially be used for "fingerprinting" a 224 specific device. 226 Information contained in TXT records does not only breach privacy by 227 making devices trackable, but might directly contain private 228 information about the user. For instance the _presence service 229 reveals the "chat status" to everyone in the same network. Users 230 might not be aware of that. 232 Further, TXT records often contain version information about services 233 allowing potential attackers to identify devices running exploit- 234 prone versions of a certain service. 236 2.4. Device Fingerprinting 238 The combination of information published in DNS-SD has the potential 239 to provide a "fingerprint" of a specific device. Such information 240 includes: 242 o The list of services published by the device, which can be 243 retrieved because the SRV records will point to the same host 244 name. 246 o The specific attributes describing these services. 248 o The port numbers used by the services. 250 o The values of the priority and weight attributes in the SRV 251 records. 253 This combination of services and attributes will often be sufficient 254 to identify the version of the software running on a device. If a 255 device publishes many services with rich sets of attributes, the 256 combination may be sufficient to identify the specific device. 258 There is however an argument that devices providing services can be 259 discovered by observing the local traffic, and that trying to hide 260 the presence of the service is futile. The same argument can be 261 extended to say that the pattern of services offered by a device 262 allows for fingerprinting the device. This may or may not be true, 263 since we can expect that services will be designed or updated to 264 avoid leaking fingerprints. In any case, the design of the discovery 265 service should avoid making a bad situation worse, and should as much 266 as possible avoid providing new fingerprinting information. 268 2.5. Privacy Implication of Discovering Services 270 The consumers of services engage in discovery, and in doing so reveal 271 some information such as the list of services they are interested in 272 and the domains in which they are looking for the services. When the 273 clients select specific instances of services, they reveal their 274 preference for these instances. This can be benign if the service 275 type is very common, but it could be more problematic for sensitive 276 services, such as for example some private messaging services. 278 One way to protect clients would be to somehow encrypt the requested 279 service types. Of course, just as we noted in Section 2.4, traffic 280 analysis can often reveal the service. 282 3. Design of the Private DNS-SD Discovery Service 284 In this section, we present the design of a two-stage solution that 285 enables private use of DNS-SD, without affecting existing users. The 286 solution is largely based on the architecture proposed in [KW14b], 287 which separates the general private discovery problem in three 288 components. The first component is an offline pairing mechanism, 289 which is performed only once per pair of users. It establishes a 290 shared secret over an authenticated channel, allowing devices to 291 authenticate using this secret without user interaction at any later 292 point in time. We use the pairing system proposed in 293 [I-D.kaiser-dnssd-pairing]. 295 The further two components are online (in contrast to pairing they 296 are performed anew each time joining a network) and compose the two 297 service discovery stages, namely 299 o Discovery of the Private Discovery Service -- the first stage -- 300 in which hosts discover the Private Discovery Service (PDS), a 301 special service offered by every host supporting our extension. 302 After the discovery, hosts connect to the PSD offered by paired 303 peers. 305 o Actual Service Discovery -- the second stage -- is performed 306 through the Private Discovery Service, which only accepts 307 encrypted messages associated with an authenticated session; thus 308 not compromising privacy. 310 In other words, the hosts first discover paired peers and then 311 directly engage in privacy preserving service discovery. 313 The stages are independent with respect to means used for 314 transmitting the necessary data. While in our extension the messages 315 for the first stage are transmitted using IP multicast, the messages 316 for the second stage are transmitted via unicast. One could also 317 imagine using a Distributed Hash Table for the first stage, being 318 completely independent of multicast. 320 3.1. Device Pairing 322 Any private discovery solution needs to differentiate between 323 authorized devices, which are allowed to get information about 324 discoverable entities, and other devices, which should not be aware 325 of the availability of private entities. The commonly used solution 326 to this problem is establishing a "device pairing". 328 Device pairing has to be performed only once per pair of users. This 329 is important for user-friendliness, as it is the only step that 330 demands user-interaction. After this single pairing, privacy 331 preserving service discovery works fully automatically. In this 332 document, we leverage [I-D.kaiser-dnssd-pairing] as pairing 333 mechanism. 335 The pairing yields a mutually authenticated shared secret, and 336 optionally mutually authenticated public keys or certificates added 337 to a local web of trust. Public key technology has many advantages, 338 but shared secrets are typically easier to handle on small devices. 340 3.2. Discovery of the Private Discovery Service 342 The first stage of service discovery is to check whether instances of 343 compatible Private Discovery Services are available in the local 344 scope. The goal of that stage is to identify devices that share a 345 pairing with the querier, and are available locally. The service 346 instances can be discovered using regular DNS-SD procedures, but the 347 list of discovered services will have to be filtered so only paired 348 devices are retained. 350 The discovery relies on the advertisement of "proofs" by the 351 publishers of the service. Each proof is the hash of a nonce with 352 the key shared between the publisher and one of the paired devices. 353 In order to reduce the overall number of messages, we use a special 354 encoding of the instance name. Suppose that the publisher manages N 355 pairings with the associated keys K1, K2, ... Kn. The instance name 356 will be set to an encoding of N "proofs" of the N keys, where each 357 proof is computed as function of the key and a nonce: 359 instance name = .. 361 Fi = hash (nonce, Ki), where hash is a cryptographic hash 362 function. 364 The querier can test the instance name by computing the same "proof" 365 for each of its own keys. Suppose that the receiver manages P 366 pairings, with the corresponding keys X1, X2, .. Xp. The receiver 367 verification procedure will be: 369 for each received instance name: 370 retrieve nonce from instance name 371 for (j = 1 to P) 372 retrieve the key Xj of pairing number j 373 compute F = hash(nonce, Xj) 374 for (i=1 to N) 375 retrieve the proof Fi 376 if F is equal to Fi 377 mark the pairing number j as available 379 The procedure presented here requires on average O(M*N) iterations of 380 the hash function. It also requires O(M*N^2) comparison operations, 381 but these are less onerous than cryptographic operations. Further, 382 when setting the nonce to a timestamp, the Fi have to be calculated 383 only once per time interval. 385 The number of pairing proofs that can be encoded in a single record 386 is limited by the maximum size of a DNS label, which is 63 bytes. 387 Since this are characters and not pure binary values, nonce and 388 proofs will have to be encoded using BASE64 ([RFC2045] section 6.8), 389 resulting in at most 378 bits. The nonce should not be repeated, and 390 the simplest way to achieve that is to set the nonce to a 32 bit 391 timestamp value. The remaining 346 bits could encode up to 10 proofs 392 of 32 bits each, which would be sufficient for many practical 393 scenarios. 395 In practice, a 32 bit proof should be sufficient to distinguish 396 between available devices. However, there is clearly a risk of 397 collision. The Private Discovery Service as described here will find 398 the available pairings, but it might also find a spurious number of 399 "false positives". The chances of that happening are however quite 400 small: less than 0.02% for a device managing 10 pairings and 401 processing 10000 responses. 403 3.3. Private Discovery Service 405 The Private Discovery Service discovery allows discovering a list of 406 available paired devices, and verifying that either party knows the 407 corresponding shared secret. At that point, the querier can engage 408 in a series of directed discoveries. 410 We have considered defining an ad-hoc protocol for the private 411 discovery service, but found that just using TLS would be much 412 simpler. The Directed Private Discovery service is just a regular 413 DNS-SD service, accessed over TLS, using the encapsulation of DNS 414 over TLS defined in [RFC7858]. The main difference with simple DNS 415 over TLS is the need for authentication. 417 We assume that the pairing process has provided each pair of 418 authorized client and server with a shared secret. We can use that 419 shared secret to provide mutual authentication of clients and servers 420 using "Pre Shared Key" authentication, as defined in [RFC4279] and 421 incorporated in the latest version of TLS [I-D.ietf-tls-tls13]. 423 One difficulty is the reliance on a key identifier in the protocol. 424 For example, in TLS 1.3 the PSK extension is defined as: 426 opaque psk_identity<0..2^16-1>; 428 struct { 429 select (Role) { 430 case client: 431 psk_identity identities<2..2^16-1>; 433 case server: 434 uint16 selected_identity; 435 } 436 } PreSharedKeyExtension 438 According to the protocol, the PSK identity is passed in clear text 439 at the beginning of the key exchange. This is logical, since server 440 and clients need to identify the secret that will be used to protect 441 the connection. But if we used a static identifier for the key, 442 adversaries could use that identifier to track server and clients. 443 The solution is to use a time-varying identifier, constructed exactly 444 like the "hint" described in Section 3.2, by concatenating a nonce 445 and the hash of the nonce with the shared secret. 447 3.3.1. A Note on Private DNS Services 449 Our solution uses a variant of the DNS over TLS protocol [RFC7858] 450 defined by the DNS Private Exchange working group (DPRIVE). DPRIVE 451 is also working on an UDP variant, DNS over DTLS 452 [I-D.ietf-dprive-dnsodtls], which would also be a candidate. 454 DPRIVE and Private Discovery solve however two somewhat different 455 problems. DPRIVE is concerned with the confidentiality of DNS 456 transactions, addressing the problems outlined in [RFC7626]. 457 However, DPRIVE does not address the confidentiality or privacy 458 issues with publication of services, and is not a direct solution to 459 DNS-SD privacy: 461 o Discovery queries are scoped by the domain name within which 462 services are published. As nodes move and visit arbitrary 463 networks, there is no guarantee that the domain services for these 464 networks will be accessible using DNS over TLS or DNS over DTLS. 466 o Information placed in the DNS is considered public. Even if the 467 server does support DNS over TLS, third parties will still be able 468 to discover the content of PTR, SRV and TXT records. 470 o Neither DNS over TLS nor DNS over DTLS applies to MDNS. 472 In contrast, we propose using mutual authentication of the client and 473 server as part of the TLS solution, to ensure that only authorized 474 parties learn the presence of a service. 476 3.4. Randomized Host Names 478 Instead of publishing their actual name in the SRV records, nodes 479 could publish a randomized name. That is the solution argued for in 480 [I-D.ietf-intarea-hostname-practice]. 482 Randomized host names will prevent some of the tracking. Host names 483 are typically not visible by the users, and randomizing host names 484 will probably not cause much usability issues. 486 3.5. Timing of Obfuscation and Randomization 488 It is important that the obfuscation of instance names is performed 489 at the right time, and that the obfuscated names change in synchrony 490 with other identifiers, such as MAC Addresses, IP Addresses or host 491 names. If the randomized host name changed but the instance name 492 remained constant, an adversary would have no difficulty linking the 493 old and new host names. Similarly, if IP or MAC addresses changed 494 but host names remained constant, the adversary could link the new 495 addresses to the old ones using the published name. 497 The problem is handled in [I-D.ietf-intarea-hostname-practice], which 498 recommends to pick a new random host name at the time of connecting 499 to a new network. New instance names for the Private Discovery 500 Services should be composed at the same time. 502 4. Private Discovery Service Specification 504 The proposed solution uses the following components: 506 o Host name randomization to prevent tracking. 508 o Device pairing yielding pairwise shared secrets. 510 o A Private Discovery Server (PDS) running on each host. 512 o Discovery of the PDS instances using DNS-SD. 514 These components are detailed in the following subsections. 516 4.1. Host Name Randomization 518 Nodes publishing services with DNS-SD and concerned about their 519 privacy MUST use a randomized host name. The randomized name MUST be 520 changed when network connectivity changes, to avoid the correlation 521 issues described in Section 3.5. The randomized host name MUST be 522 used in the SRV records describing the service instance, and the 523 corresponding A or AAAA records MUST be made available through DNS or 524 MDNS, within the same scope as the PTR, SRV and TXT records used by 525 DNS-SD. 527 If the link-layer address of the network connection is properly 528 obfuscated (e.g. using MAC Address Randomization), the Randomized 529 Host Name MAY be computed using the algorithm described in section 530 3.7 of [RFC7844]. If this is not possible, the randomized host name 531 SHOULD be constructed by simply picking a 48 bit random number 532 meeting the Randomness Requirements for Security expressed in 533 [RFC4075], and then use the hexadecimal representation of this number 534 as the obfuscated host name. 536 4.2. Device Pairing 538 Nodes that want to leverage the Private Directory Service for private 539 service discovery among peers MUST share a secret with each of these 540 peers. Each shared secret MUST be a 256 bit randomly chosen number. 541 We RECOMMEND using the pairing mechanism proposed in 542 [I-D.kaiser-dnssd-pairing] to establish these secrets. 544 [[TODO: Should we support mutually authenticated certificates? They 545 can also be used to initiate TLS and have several advantages, i.e. 546 allow setting an expiry date.]] 548 4.3. Private Discovery Server 550 A Private Discovery Server (PDS) is a minimal DNS server running on 551 each host. Its task is to offer resource records corresponding to 552 private services only to authorized peers. These peers MUST share a 553 secret with the host (see Section 4.2). To ensure privacy of the 554 requests, the service is only available over TLS [RFC5246], and the 555 shared secrets are used to mutually authenticate peers and servers. 557 The Private Name Server SHOULD support DNS push notifications 558 [I-D.ietf-dnssd-push], e.g. to facilitate an up-to-date contact list 559 in a chat application without polling. 561 4.3.1. Establishing TLS Connections 563 The PDS MUST only answer queries via DNS over TLS [RFC7858] and MUST 564 use a PSK authenticated TLS handshake [RFC4279]. The client and 565 server should negotiate a forward secure cipher suite such as DHE-PSK 566 or ECDHE-PSK when available. The shared secret exchanged during 567 pairing MUST be used as PSK. 569 When using the PSK based authentication, the "psk_identity" parameter 570 identifying the pre-shared key MUST be composed as follows, using the 571 conventions of TLS [RFC7858]: 573 struct { 575 uint32 gmt_unix_time; 577 opaque random_bytes[4]; 579 } nonce; 581 long_proof = HASH(nonce | pairing_key ) 582 proof = first 12 bytes of long_proof 583 psk_identity = BASE64(nonce) "." BASE64(proof) 585 In this formula, HASH SHOULD be the function SHA256 defined in 586 [RFC4055]. Implementers MAY eventually replace SHA256 with a 587 stronger algorithm, in which cases both clients and servers will have 588 to agree on that algorithm during the pairing process. The first 32 589 bits of the nonce are set to the current time and date in standard 590 UNIX 32-bit format (seconds since the midnight starting Jan 1, 1970, 591 UTC, ignoring leap seconds) according to the client's internal clock. 592 The next 32 bits of the nonce are set to a value generated by a 593 secure random number generator. 595 In this formula, the identity is finally set to a character string, 596 using BASE64 ([RFC2045] section 6.8). This transformation is meant 597 to comply with the PSK identity encoding rules specified in section 598 5.1 of [RFC4279]. 600 The server will check the received key identity, trying the key 601 against the valid keys established through pairing. If one of the 602 keys matches, the TLS connection is accepted, otherwise it is 603 declined. 605 4.4. Publishing Private Discovery Service Instances 607 Nodes that provide the Private Discovery Service SHOULD advertise 608 their availability by publishing instances of the service through 609 DNS-SD. 611 The DNS-SD service type for the Private Discovery Service is 612 "_pds._tls". 614 Each published instance describes one server and up to 10 pairings. 615 In the case where a node manages more than 10 pairings, it should 616 publish as many instances as necessary to advertise all available 617 pairings. 619 Each instance name is composed as follows: 621 pick a 32 bit nonce, e.g. using the Unix GMT time. 622 set the binary identifier to the nonce. 624 for each of up to 10 pairings 625 hint = first 32 bits of HASH(|) 626 concatenate the hint to the binary identifier 628 set instance-ID = BASE64(binary identifier) 630 In this formula, HASH SHOULD be the function SHA256 defined in 631 [RFC4055], and BASE64 is defined in section 6.8 of [RFC2045]. The 632 concatenation of a 32 bit nonce and up to 10 pairing hints result a 633 bit string at most 352 bit long. The BASE64 conversion will produce 634 a string that is up to 59 characters long, which fits within the 63 635 characters limit defined in [RFC6763]. 637 4.5. Discovering Private Discovery Service Instances 639 Nodes that wish to discover Private Discovery Service Instances will 640 issue a DNS-SD discovery request for the service type. These request 641 will return a series of PTR records, providing the names of the 642 instances present in the scope. 644 The querier SHOULD examine each instance to see whether it hints at 645 one of its available pairings, according to the following conceptual 646 algorithm: 648 for each received instance name: 649 convert the instance name to binary using BASE64 650 if the conversion fails, 651 discard the instance. 652 if the binary instance length is a not multiple of 32 bits, 653 discard the instance. 655 nonce = first 32 bits of binary. 656 for each 32 bit hint after the nonce 657 for each available pairing 658 retrieve the key Xj of pairing number j 659 compute F = hash(nonce, Xj) 660 if F is equal to the 32 bit hint 661 mark the pairing number j as available 663 Once a pairing has been marked available, the querier SHOULD try 664 connecting to the corresponding instance, using the selected key. 665 The connection is likely to succeed, but it MAY fail for a variety of 666 reasons. One of these reasons is the probabilistic nature of the 667 hint, which entails a small chance of "false positive" match. This 668 will occur if the hash of the nonce with two different keys produces 669 the same result. In that case, the TLS connection will fail with an 670 authentication error or a decryption error. 672 4.6. Using the Private Discovery Service 674 Once instances of the Private Discovery Service have been discovered, 675 peers can establish TLS connections and send DNS requests over these 676 connections, as specified in DNS-SD. 678 5. Security Considerations 680 This document specifies a method to protect the privacy of service 681 publishing nodes. This is especially useful when operating in a 682 public space. Hiding the identity of the publishing nodes prevents 683 some forms of "targeting" of high value nodes. However, adversaries 684 can attempt various attacks to break the anonymity of the service, or 685 to deny it. A list of these attacks and their mitigations are 686 described in the following sections. 688 5.1. Attacks Against the Pairing System 690 There are a variety of attacks against pairing systems, which may 691 result in compromised pairing secrets. If an adversary manages to 692 acquire a compromised key, the adversary will be able to perform 693 private service discovery according to Section 4.5. This will allow 694 tracking of the service. The adversary will also be able to discover 695 which private services are available for the compromised pairing. 697 Attacks on pairing systems are detailed in 698 [I-D.kaiser-dnssd-pairing]. 700 5.2. Denial of Discovery of the Private Discovery Service 702 The algorithm described in Section 4.5 scales as O(M*N), where M is 703 the number of pairings per node and N is the number of nodes in the 704 local scope. Adversaries can attack this service by publishing 705 "fake" instances, effectively increasing the number N in that scaling 706 equation. 708 Similar attacks can be mounted against DNS-SD: creating fake 709 instances will generally increase the noise in the system and make 710 discovery less usable. Private Discovery Service discovery SHOULD 711 use the same mitigations as DNS-SD. 713 The attack is amplified because the clients need to compute proofs 714 for all the nonces presented in Private Discovery Service Instance 715 names. One possible mitigation would be to require that such nonces 716 correspond to rounded timestamps. If we assume that timestamps must 717 not be too old, there will be a finite number of valid rounded 718 timestamps at any time. Even if there are many instances present, 719 they would all pick their nonces from this small number of rounded 720 timestamps, and a smart client could make sure that proofs are only 721 computed once per valid time stamp. 723 5.3. Replay Attacks Against Discovery of the Private Discovery Service 725 Adversaries can record the service instance names published by 726 Private Discovery Service instances, and replay them later in 727 different contexts. Peers engaging in discovery can be misled into 728 believing that a paired server is present. They will attempt to 729 connect to the absent peer, and in doing so will disclose their 730 presence in a monitored scope. 732 The binary instance identifiers defined in Section 4.4 start with 32 733 bits encoding the "UNIX" time. In order to protect against replay 734 attacks, clients MAY verify that this time is reasonably recent. 736 [[TODO: Should we somehow encode the scope in the identifier? Having 737 both scope and time would really mitigate that attack.]] 739 5.4. Denial of Private Discovery Service 741 The Private Discovery Service is only available through a mutually 742 authenticated TLS connection, which provides state-of-the-art 743 protection mechanisms. However, adversaries can mount a denial of 744 service attack against the service. In the absence of shared 745 secrets, the connections will fail, but the servers will expend some 746 CPU cycles defending against them. 748 To mitigate such attacks, nodes SHOULD restrict the range of network 749 addresses from which they accept connections, matching the expected 750 scope of the service. 752 This mitigation will not prevent denial of service attacks performed 753 by locally connected adversaries; but protecting against local denial 754 of service attacks is generally very difficult. For example, local 755 attackers can also attack mDNS and DNS-SD by generating a large 756 number of multicast requests. 758 5.5. Replay Attacks against the Private Discovery Service 760 Adversaries may record the PSK Key Identifiers used in successful 761 connections to a private discovery service. They could attempt to 762 replay them later against nodes advertising the private service at 763 other times or at other locations. If the PSK Identifier is still 764 valid, the server will accept the TLS connection, and in doing so 765 will reveal being the same server observed at a previous time or 766 location. 768 The PSK identifiers defined in Section 4.3.1 start with 32 bits 769 encoding the "UNIX" time. In order to mitigate replay attacks, 770 servers SHOULD verify that this time is reasonably recent, and fail 771 the connection if it is too old, or if it occurs too far in the 772 future. 774 The processing of timestamps is however affected by the accuracy of 775 computer clocks. If the check is too strict, reasonable connections 776 could fail. To further mitigate replay attacks, servers MAY record 777 the list of valid PSK identifiers received in a recent past, and fail 778 connections if one of these identifiers is replayed. 780 6. IANA Considerations 782 This draft does not require any IANA action. (Or does it? What 783 about the _pds tag?) 785 7. Acknowledgments 787 This draft results from initial discussions with Dave Thaler, and 788 encouragements from the DNS-SD working group members. 790 8. References 792 8.1. Normative References 794 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 795 Extensions (MIME) Part One: Format of Internet Message 796 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 797 . 799 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 800 Requirement Levels", BCP 14, RFC 2119, 801 DOI 10.17487/RFC2119, March 1997, 802 . 804 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 805 Algorithms and Identifiers for RSA Cryptography for use in 806 the Internet X.509 Public Key Infrastructure Certificate 807 and Certificate Revocation List (CRL) Profile", RFC 4055, 808 DOI 10.17487/RFC4055, June 2005, 809 . 811 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 812 Configuration Option for DHCPv6", RFC 4075, 813 DOI 10.17487/RFC4075, May 2005, 814 . 816 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 817 Ciphersuites for Transport Layer Security (TLS)", 818 RFC 4279, DOI 10.17487/RFC4279, December 2005, 819 . 821 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 822 (TLS) Protocol Version 1.2", RFC 5246, 823 DOI 10.17487/RFC5246, August 2008, 824 . 826 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 827 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 828 . 830 8.2. Informative References 832 [I-D.ietf-dnssd-push] 833 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 834 draft-ietf-dnssd-push-08 (work in progress), July 2016. 836 [I-D.ietf-dprive-dnsodtls] 837 Reddy, T., Wing, D., and P. Patil, "Specification for DNS 838 over Datagram Transport Layer Security (DTLS)", draft- 839 ietf-dprive-dnsodtls-12 (work in progress), September 840 2016. 842 [I-D.ietf-intarea-hostname-practice] 843 Huitema, C., Thaler, D., and R. Winter, "Current Hostname 844 Practice Considered Harmful", draft-ietf-intarea-hostname- 845 practice-03 (work in progress), July 2016. 847 [I-D.ietf-tls-tls13] 848 Rescorla, E., "The Transport Layer Security (TLS) Protocol 849 Version 1.3", draft-ietf-tls-tls13-18 (work in progress), 850 October 2016. 852 [I-D.kaiser-dnssd-pairing] 853 Huitema, C. and D. Kaiser, "Device Pairing Using Short 854 Authentication Strings", draft-kaiser-dnssd-pairing-00 855 (work in progress), September 2016. 857 [KW14a] Kaiser, D. and M. Waldvogel, "Adding Privacy to Multicast 858 DNS Service Discovery", DOI 10.1109/TrustCom.2014.107, 859 2014, . 862 [KW14b] Kaiser, D. and M. Waldvogel, "Efficient Privacy Preserving 863 Multicast DNS Service Discovery", 864 DOI 10.1109/HPCC.2014.141, 2014, 865 . 868 [RFC1033] Lottor, M., "Domain Administrators Operations Guide", 869 RFC 1033, DOI 10.17487/RFC1033, November 1987, 870 . 872 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 873 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 874 . 876 [RFC1035] Mockapetris, P., "Domain names - implementation and 877 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 878 November 1987, . 880 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 881 specifying the location of services (DNS SRV)", RFC 2782, 882 DOI 10.17487/RFC2782, February 2000, 883 . 885 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 886 DOI 10.17487/RFC6762, February 2013, 887 . 889 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 890 DOI 10.17487/RFC7626, August 2015, 891 . 893 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 894 Profiles for DHCP Clients", RFC 7844, 895 DOI 10.17487/RFC7844, May 2016, 896 . 898 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 899 and P. Hoffman, "Specification for DNS over Transport 900 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 901 2016, . 903 Authors' Addresses 905 Christian Huitema 906 Friday Harbor, WA 98250 907 U.S.A. 909 Email: huitema@huitema.net 911 Daniel Kaiser 912 University of Konstanz 913 Konstanz 78457 914 Germany 916 Email: daniel.kaiser@uni-konstanz.de