idnits 2.17.1 draft-huitema-dnssd-privacyscaling-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 (February 10, 2018) is 2267 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-dnssd-privacy-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: Informational February 10, 2018 5 Expires: August 14, 2018 7 Privacy Extensions for DNS-SD 8 draft-huitema-dnssd-privacyscaling-00 10 Abstract 12 DNS-SD (DNS Service Discovery) normally discloses information about 13 both the devices offering services and the devices requesting 14 services. This information includes host names, network parameters, 15 and possibly a further description of the corresponding service 16 instance. Especially when mobile devices engage in DNS Service 17 Discovery over Multicast DNS at a public hotspot, a serious privacy 18 problem arises. 20 The draft currently progressing in the DNSSD Working Group assumes 21 peer-to-peer pairing between the service to be discovered and each of 22 its client. This has good security properties, but create scaling 23 issues. Each server needs to publish as many announcements as it has 24 paired clients. Each client needs to process all announcements from 25 all servers present in the network. This leads to large number of 26 operations when each server is paired with many clients. 28 Different designs are possible. For example, if there was only one 29 server "discovery key" known by each authorized client, each server 30 would only have to announce a single record, and clients would only 31 have to process one response for each server that is present on the 32 network. Yet, these designs will present different privacy profiles, 33 and pose different management challenges. This draft analyses the 34 tradeoffs between privacy and scaling in a set of different designs, 35 using either shared secrets or public keys. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on August 14, 2018. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Privacy and Secrets . . . . . . . . . . . . . . . . . . . . . 3 73 2.1. Pairing secrets . . . . . . . . . . . . . . . . . . . . . 3 74 2.2. Discovery secret . . . . . . . . . . . . . . . . . . . . 4 75 2.3. Discovery public key . . . . . . . . . . . . . . . . . . 4 76 3. Scaling properties of different solutions . . . . . . . . . . 5 77 4. Comparing privacy posture of different solutions . . . . . . 6 78 4.1. Effects of compromized client . . . . . . . . . . . . . . 6 79 4.2. Remediation of compromized client . . . . . . . . . . . . 7 80 4.3. Effect of compromized server . . . . . . . . . . . . . . 8 81 5. Summary of tradeoffs . . . . . . . . . . . . . . . . . . . . 8 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 84 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 85 9. Informative References . . . . . . . . . . . . . . . . . . . 9 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 88 1. Introduction 90 DNS-SD [RFC6763] over mDNS [RFC6762] enables configurationless 91 service discovery in local networks. It is very convenient for 92 users, but it requires the public exposure of the offering and 93 requesting identities along with information about the offered and 94 requested services. Parts of the published information can seriously 95 breach the user's privacy. These privacy issues and potential 96 solutions are discussed in [KW14a] and [KW14b]. 98 A recent draft [I-D.ietf-dnssd-privacy] proposes to solve this 99 problem by relying on device pairing. Only clients that have paired 100 with a device would be able to discover that device, and the 101 discovery would not be observable by third parties. This design has 102 a number of good privacy and security properties, but it has a cost, 103 because each server must provide separate annoucements for each 104 clients. In this draft, we compare scaling and privacy properties of 105 three different designs: 107 o The individual pairing defined in [I-D.ietf-dnssd-privacy], 109 o A single server discovery secret, shared by all authorized 110 clients, 112 o A single server discovery public key, known by all authorized 113 clients. 115 After presenting briefly these three solutions, the draft presents 116 the scaling and privacy properties of each of them. 118 2. Privacy and Secrets 120 Private discovery tries to ensure that clients and servers can 121 discover eachother in a potentially hostile network context, while 122 maintaining privacy. Unauthorized third parties must not be able to 123 discover that a specific server or device is currently present on the 124 network, and they must not be able to discover that a particular 125 client is trying to discover a particular service. This cannot be 126 achieved without some kind of shared secret between client and 127 servers. We review here three particular design for sharing these 128 secrets. 130 2.1. Pairing secrets 132 The solution proposed in [I-D.ietf-dnssd-privacy] relies on pairing 133 secrets. Each client obtains a pairing secret from each server that 134 they are authorized to use. The servers publish announcements of the 135 form "nonce|proof", in which the proof is the hash of the nonce and 136 the pairing secret. The proof is of course different for each 137 client, because the secrets are different. For better scalling, the 138 nonce is common to all clients, and defined as a coarse function of 139 time, such as the current 30 minutes interval. 141 Clients discover the required server by issuing queries containing 142 the current nonce and proof. Servers respond to these queries if the 143 nonce matches the current time interval, and if the proof matches the 144 hash of the nonce with one of the pairing key of an authorized 145 client. 147 2.2. Discovery secret 149 Instead of using a different secret for each client as in 150 Section 2.1, another design is to have a single secret per server, 151 shared by all authorized clients of that server. As in the previous 152 solution, the servers publish announcements of the form 153 "nonce|proof", but this time they only need to publish a single 154 announcement per server, because each server maintains a single 155 discovery secret. Again, the nonce can be common to all clients, and 156 defined as a coarse function of time. 158 Clients discover the required server by issuing queries containing 159 the current nonce and proof. Servers respond to these queries if the 160 nonce matches the current time interval, and if the proof matches the 161 hash of the nonce with one of the discovery secret. 163 2.3. Discovery public key 165 Instead of a discovery secret used in Section 2.2, clients could 166 obtain the public keys of the servers that they are authorized to 167 use. 169 Many public key systems assume that the public key of the server is, 170 well, not secret. But if adversaries know the public key of a 171 server, they can use that public key as a unique identifier to track 172 the server. Moreover, they could use variations of the padding 173 oracle to observe discovery protocol messages and attribute them to a 174 specific public key, thus breaking server privacy. For these 175 reasons, we assume here that the discovery public key is kept secret, 176 only known to authorized clients. 178 As in the previous solution, the servers publish announcements of the 179 form "nonce|proof", but this time they only need to publish a single 180 announcement per server, because each server maintains a single 181 discovery secret. The proof is obtained by either hashing the nonce 182 with the public key, or using the public key to encrypt the nonce -- 183 the point being that both clients and server can contruct the proof. 184 Again, the nonce can be common to all clients, and defined as a 185 coarse function of time. 187 The advantage of public key based solutions is that the clients can 188 easily verify the identity of the server, for example if the service 189 is accessed over TLS. On the other hand, just using standard TLS 190 would disclose the certificate of the server to any client that 191 attempts a connection, not just to authorized clients. The server 192 should thus only accept connections from clients that demonstrate 193 knowledge of its public key. 195 3. Scaling properties of different solutions 197 To analyze scaling issues we will use the following variables: 199 N: The average number of authorized clients per server. 201 M: The average number of servers per client. 203 P: The average total number of servers present during discovery. 205 The big difference between the three proposals is the number of 206 records that need to be published by a server when using DNS-SD in 207 server mode, or the number of broadcast messages that needs to be 208 announced per server in MDNS mode: 210 Pairing secrets: O(N). One record per client. 212 Discovery secrets: O(1). One record for all clients. 214 Discovery public key: O(1). One record for all clients. 216 There are other elements of scaling, linked to the mapping of the 217 privacy discovery service to DNSSD. DNSSD identifies services by a 218 combination of a service type and an instance name. In classic 219 mapping behavior, clients send a query for a service type, and will 220 receive responses from each server instance supporting that type: 222 Pairing secrets: O(P*N). There are O(P) servers present, and each 223 publishes O(N) instances. 225 Discovery secrets: O(P). One record per server present. 227 Discovery public key: O(P). One record per server present. 229 The DNSSD Privacy draft suggests an optimization that considerably 230 reduces the considerations about scaling of responses -- see section 231 4.6 of [I-D.ietf-dnssd-privacy]. In that case, clients compose the 232 list of instance names that they are looking for, and specifically 233 query for these instance names: 235 Pairing secrets: O(M). The client will compose O(M) queries to 236 discover all the servers that it is interested in. There will be 237 at most O(M) responses. 239 Discovery secrets: O(M). Same behavior as in the pairing secret 240 case. 242 Discovery public key: O(M). Same behavior as in the pairing secret 243 case. 245 Finally, another element of scaling is cacheability. Responses to 246 DNS queries can be cached by DNS resolvers, and MDNS responses can be 247 cached by MDNS resolvers. If several clients send the same queries, 248 and if previous responses could be cached, the client can be served 249 immediately. There are of course differences between the solutions: 251 Pairing secrets: No caching possible, since there are separate 252 server instances for separate clients. 254 Discovery secrets: Caching is possible, since there is just one 255 server instance. 257 Discovery public key: Caching is possible, since there is just one 258 server instance. 260 4. Comparing privacy posture of different solutions 262 The analysis of scaling issues in Section 3 shows that the solutions 263 base on a common discovery secret or discovery public key scale much 264 better than the solutions based on pairing secret. All these 265 solutions protect against tracking of clients or servers by third 266 parties, as long as the secret on which they rely are kept secret. 267 There are however significant differences in privacy properties, 268 which become visible when one of the clients becomes compromised. 270 4.1. Effects of compromized client 272 If a client is compromised, an adversary will take possession of the 273 secrets owned by that client. The effects will be the following: 275 Pairing secrets: With a valid pairing key, the adversary can issue 276 queries or parse annoucements. It will be able to track the 277 presence of all the servers to which the compromised client was 278 paired. It may be able to track other clients of these servers if 279 it can infer that multiple independent instances are tied to the 280 same server, for example by assessing the IP address associated 281 with a specific instance. It will not be able to impersonate the 282 servers for other clients. 284 Discovery secrets: With a valid discovery secret, the adversary can 285 issue queries or parse annoucements. It will be able to track the 286 presence of all the servers that the compromised client could 287 discover. It will also be able to detect the clients that try to 288 use one of these servers. This will not reveal the identity of 289 the client, but it can provide clues for network analysis. The 290 adversary will also be able to spoof the server's announcements, 291 which could be the first step in a serve impersonation attack. 293 Discovery public key: With a valid discovery public key, the 294 adversary can issue queries or parse annoucements. It will be 295 able to track the presence of all the servers that the compromised 296 client could discover. It will also be able to detect the clients 297 that try to use one of these servers. This will not reveal the 298 identity of the client, but it can provide clues for network 299 analysis. The adversary will not be able to spoof the server's 300 announcements, or to impersonate the server. 302 4.2. Remediation of compromized client 304 Let's assume that an administrator discovers that a client has been 305 compromised. As seen in Section 4.1, compromising a client entails a 306 loss of privacy for all the servers that the client was authorized to 307 use, and also to all other users of these servers. The worse 308 situation happens in the solutions based on "discovery secrets", but 309 no solution provides a great defense. The administrator will have to 310 remedy the problem, which means different actions based on the 311 different solutions: 313 Pairing secrets: The administrator will need to revoke the pairing 314 keys used by the compromised client. This implies contacting the 315 O(M) servers to which the client was paired. 317 Discovery secrets: The administrator will need to revoke the 318 discovery secrets used by the compromised client. This implies 319 contacting the O(M) servers that the client was authorized to 320 discover, and then the O(N) clients of each of these servers. 321 This will require a total of O(N*M) management operations. 323 Discovery public key: The administrator will need to revoke the 324 discovery public keys used by the compromised client. This 325 implies contacting the O(M) servers that the client was authorized 326 to discover, and then the O(N) clients of each of these servers. 327 Just as in the case of discovery secrets, this will require O(N*M) 328 management operations. 330 The revocation of public keys might benefit from some kind of 331 centralized revocation list, and thus may actually be easier to 332 organize than simple scaling considerations would dictate. 334 4.3. Effect of compromized server 336 If a server is compromised, an adversary will take possession of the 337 secrets owned by that server. The effects are pretty much the same 338 in all configurations. With a set of valid credentials, the 339 adversary can impersonate the server. It can track all of the 340 server's clients. There are no differences between the various 341 solutions. 343 As remedy, once the compromise is discovered, the administrator will 344 have to revoke the credentials of O(N) clients connected to that 345 server. In all cases, this could be done by notifying all potential 346 clients to not trust this particular server anymore. 348 5. Summary of tradeoffs 350 In the preceeding sections, we have reviewed the scaling and privacy 351 properties of three possible secret sharing solutions for privacy 352 discovery. The comparison can be summed up as follow: 354 +----------------------+---------+------------+-------------+ 355 | Solution | Scaling | Resistance | Remediation | 356 +----------------------+---------+------------+-------------+ 357 | Pairing secret | Poor | Bad | Good | 358 | Discovery secret | Good | Really bad | Poor | 359 | Discovery public key | Good | Bad | Maybe | 360 +----------------------+---------+------------+-------------+ 362 Table 1: Comparison of secret sharing solutions 364 All three types of solutions provide reasonable privacy when the 365 secrets are not compromized. They all have poor resistance to the 366 compromise of one a client, as explained in Section 4.1, but pairing 367 secret and public key solution have the advantage of preventing 368 server impersonation. The pairing secret solution scales worse than 369 the discovery secret and discovery public key solutions. The pairing 370 secret solution can recover from a compromise with a smaller number 371 of updates, but the public key solution may benefit from a simple 372 recovery solution using some form of "revocation list". 374 6. Security Considerations 376 This document does not specify a solution, but inform future choices 377 when providing privacy for discovery protocols. 379 7. IANA Considerations 381 This draft does not require any IANA action. 383 8. Acknowledgments 385 This draft results from initial feedback in the DNS SD working group 386 on [I-D.ietf-dnssd-privacy]. 388 9. Informative References 390 [I-D.ietf-dnssd-privacy] 391 Huitema, C. and D. Kaiser, "Privacy Extensions for DNS- 392 SD", draft-ietf-dnssd-privacy-03 (work in progress), 393 September 2017. 395 [KW14a] Kaiser, D. and M. Waldvogel, "Adding Privacy to Multicast 396 DNS Service Discovery", DOI 10.1109/TrustCom.2014.107, 397 2014, . 400 [KW14b] Kaiser, D. and M. Waldvogel, "Efficient Privacy Preserving 401 Multicast DNS Service Discovery", 402 DOI 10.1109/HPCC.2014.141, 2014, 403 . 406 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 407 DOI 10.17487/RFC6762, February 2013, 408 . 410 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 411 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 412 . 414 Author's Address 416 Christian Huitema 417 Private Octopus Inc. 418 Friday Harbor, WA 98250 419 U.S.A. 421 Email: huitema@huitema.net