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