idnits 2.17.1 draft-huitema-dnssd-privacyscaling-01.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 (June 29, 2018) is 2126 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-dnssd-pairing-04 == Outdated reference: A later version (-05) exists of draft-ietf-dnssd-privacy-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Huitema 3 Internet-Draft Private Octopus Inc. 4 Intended status: Informational June 29, 2018 5 Expires: December 31, 2018 7 DNS-SD Privacy Scaling Tradeoffs 8 draft-huitema-dnssd-privacyscaling-01 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 DNS-SD Working Group assumes 21 peer-to-peer pairing between the service to be discovered and each of 22 its clients. This has good security properties, but creates scaling 23 issues, because each server needs to publish as many announcements as 24 it has paired clients. This leads to large number of operations when 25 servers are paired with many clients. 27 Different designs are possible. For example, if there was only one 28 server "discovery key" known by each authorized client, each server 29 would only have to announce a single record, and clients would only 30 have to process one response for each server that is present on the 31 network. Yet, these designs will present different privacy profiles, 32 and pose different management challenges. This draft analyses the 33 tradeoffs between privacy and scaling in a set of different designs, 34 using either shared secrets or public keys. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on December 31, 2018. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Privacy and Secrets . . . . . . . . . . . . . . . . . . . . . 3 72 2.1. Pairing secrets . . . . . . . . . . . . . . . . . . . . . 3 73 2.2. Group public keys . . . . . . . . . . . . . . . . . . . . 4 74 2.3. Shared symmetric secret . . . . . . . . . . . . . . . . . 4 75 2.4. Shared public key . . . . . . . . . . . . . . . . . . . . 4 76 3. Scaling properties of different solutions . . . . . . . . . . 5 77 4. Comparing privacy posture of different solutions . . . . . . 7 78 4.1. Effects of compromized client . . . . . . . . . . . . . . 7 79 4.2. Revocation . . . . . . . . . . . . . . . . . . . . . . . 8 80 4.3. Effect of compromized server . . . . . . . . . . . . . . 9 81 5. Summary of tradeoffs . . . . . . . . . . . . . . . . . . . . 9 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 85 9. Informative References . . . . . . . . . . . . . . . . . . . 10 86 Appendix A. Survey of Implementations . . . . . . . . . . . . . 11 87 A.1. DNS-SD Privacy Extensions . . . . . . . . . . . . . . . . 11 88 A.2. Private IoT . . . . . . . . . . . . . . . . . . . . . . . 12 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 DNS-SD [RFC6763] over mDNS [RFC6762] enables configurationless 94 service discovery in local networks. It is very convenient for 95 users, but it requires the public exposure of the offering and 96 requesting identities along with information about the offered and 97 requested services. Parts of the published information can seriously 98 breach the users' privacy. These privacy issues and potential 99 solutions are discussed in [KW14a] and [KW14b]. 101 A recent draft [I-D.ietf-dnssd-privacy] proposes to solve this 102 problem by relying on device pairing. Only clients that have paired 103 with a device would be able to discover that device, and the 104 discovery would not be observable by third parties. This design has 105 a number of good privacy and security properties, but it has a cost, 106 because each server must provide separate annoucements for each 107 client. In this draft, we compare scaling and privacy properties of 108 three different designs: 110 o The individual pairing defined in [I-D.ietf-dnssd-privacy], 112 o A single server discovery secret, shared by all authorized 113 clients, 115 o A single server discovery public key, known by all authorized 116 clients. 118 After presenting briefly these three solutions, the draft presents 119 the scaling and privacy properties of each of them. 121 2. Privacy and Secrets 123 Private discovery tries to ensure that clients and servers can 124 discover each other in a potentially hostile network context, while 125 maintaining privacy. Unauthorized third parties must not be able to 126 discover that a specific server or device is currently present on the 127 network, and they must not be able to discover that a particular 128 client is trying to discover a particular service. This cannot be 129 achieved without some kind of shared secret between client and 130 servers. We review here three particular designs for sharing these 131 secrets. 133 2.1. Pairing secrets 135 The solution proposed in [I-D.ietf-dnssd-privacy] relies on pairing 136 secrets. Each client obtains a pairing secret from each server that 137 they are authorized to use. The servers publish announcements of the 138 form "nonce|proof", in which the proof is the hash of the nonce and 139 the pairing secret. The proof is of course different for each 140 client, because the secrets are different. For better scaling, the 141 nonce is common to all clients, and defined as a coarse function of 142 time, such as the current 30 minutes interval. 144 Clients discover the required server by issuing queries containing 145 the current nonce and proof. Servers respond to these queries if the 146 nonce matches the current time interval, and if the proof matches the 147 hash of the nonce with one of the pairing key of an authorized 148 client. 150 2.2. Group public keys 152 In contrast to pair-wise shared secrets, applications may associate 153 public and private key pairs with groups of equally authorized 154 clients. This is identical to the pairwise sharing case if each 155 client is given a unique key pair. However, this option permits 156 multiple users to belong to the same group associated with a public 157 key, depending on the type of public key and cryptographic scheme 158 used. For example, broadcast encryption is a scheme where many 159 users, each with their own private key, can access content encrypted 160 under a single broadcast key. The scaling properties of this variant 161 depend not only on how private keys are managed, but also on the 162 associated cryptographic algorithm(s) by which those keys are used. 164 2.3. Shared symmetric secret 166 Instead of using a different secret for each client as in 167 Section 2.1, another design is to have a single secret per server, 168 shared by all authorized clients of that server. As in the previous 169 solution, the servers publish announcements of the form 170 "nonce|proof", but this time they only need to publish a single 171 announcement per server, because each server maintains a single 172 discovery secret. Again, the nonce can be common to all clients, and 173 defined as a coarse function of time. 175 Clients discover the required server by issuing queries containing 176 the current nonce and proof. Servers respond to these queries if the 177 nonce matches the current time interval, and if the proof matches the 178 hash of the nonce with one of the discovery secrets. 180 2.4. Shared public key 182 Instead of a discovery secret used in Section 2.3, clients could 183 obtain the public keys of the servers that they are authorized to 184 use. 186 Many public key systems assume that the public key of the server is, 187 well, not secret. But if adversaries know the public key of a 188 server, they can use that public key as a unique identifier to track 189 the server. Moreover, they could use variations of the padding 190 oracle to observe discovery protocol messages and attribute them to a 191 specific public key, thus breaking server privacy. For these 192 reasons, we assume here that the discovery public key is kept secret, 193 only known to authorized clients. 195 As in the previous solution, the servers publish announcements of the 196 form "nonce|proof", but this time they only need to publish a single 197 announcement per server, because each server maintains a single 198 discovery secret. The proof is obtained by either hashing the nonce 199 with the public key, or using the public key to encrypt the nonce -- 200 the point being that both clients and server can construct the proof. 201 Again, the nonce can be common to all clients, and defined as a 202 coarse function of time. 204 The advantage of public key based solutions is that the clients can 205 easily verify the identity of the server, for example if the service 206 is accessed over TLS. On the other hand, just using standard TLS 207 would disclose the certificate of the server to any client that 208 attempts a connection, not just to authorized clients. The server 209 should thus only accept connections from clients that demonstrate 210 knowledge of its public key. 212 3. Scaling properties of different solutions 214 To analyze scaling issues we will use the following variables: 216 N: The average number of authorized clients per server. 218 G: The average number of authorized groups per server. 220 M: The average number of servers per client. 222 P: The average total number of servers present during discovery. 224 The big difference between the three proposals is the number of 225 records that need to be published by a server when using DNS-SD in 226 server mode, or the number of broadcast messages that needs to be 227 announced per server in mDNS mode: 229 Pairing secrets: O(N): One record per client. 231 Group public keys: O(G): One record per group. 233 Shared symmetric secret: O(1): One record for all (shared) clients. 235 Shared public key: O(1): One record for all (shared) clients. 237 There are other elements of scaling, linked to the mapping of the 238 privacy discovery service to DNS-SD. DNS-SD identifies services by a 239 combination of a service type and an instance name. In classic 240 mapping behavior, clients send a query for a service type, and will 241 receive responses from each server instance supporting that type: 243 Pairing secrets: O(P*N): There are O(P) servers present, and each 244 publishes O(N) instances. 246 Group public keys: O(P*G): There are O(P) servers present, and each 247 publishes O(G) instances. 249 Shared symmetric secret: O(P): One record per server present. 251 Shared public secret: O(P): One record per server present. 253 The DNS-SD Privacy draft suggests an optimization that considerably 254 reduces the considerations about scaling of responses -- see section 255 4.6 of [I-D.ietf-dnssd-privacy]. In that case, clients compose the 256 list of instance names that they are looking for, and specifically 257 query for these instance names: 259 Pairing secrets: O(M): The client will compose O(M) queries to 260 discover all the servers that it is interested in. There will be 261 at most O(M) responses. 263 Group public keys: O(M): The client will compose O(M) queries to 264 discover all the servers that it is interested in. There will be 265 at most O(M) responses. 267 Shared symmetric secret: O(M): Same behavior as in the pairing 268 secret case. 270 Shared public secret: O(M): Same behavior as in the pairing secret 271 case. 273 Finally, another element of scaling is cacheability. Responses to 274 DNS queries can be cached by DNS resolvers, and mDNS responses can be 275 cached by mDNS resolvers. If several clients send the same queries, 276 and if previous responses could be cached, the client can be served 277 immediately. There are of course differences between the solutions: 279 Pairing secrets: No caching possible, since there are separate 280 server instances for separate clients. 282 Group public keys: Caching is possible for among members of a group. 284 Shared symmetric secret: Caching is possible, since there is just 285 one server instance. 287 Shared public secret: Caching is possible, since there is just one 288 server instance. 290 4. Comparing privacy posture of different solutions 292 The analysis of scaling issues in Section 3 shows that the solutions 293 base on a common discovery secret or discovery public key scale much 294 better than the solutions based on pairing secret. All these 295 solutions protect against tracking of clients or servers by third 296 parties, as long as the secret on which they rely are kept secret. 297 There are however significant differences in privacy properties, 298 which become visible when one of the clients becomes compromised. 300 4.1. Effects of compromized client 302 If a client is compromised, an adversary will take possession of the 303 secrets owned by that client. The effects will be the following: 305 Pairing secrets: With a valid pairing key, the adversary can issue 306 queries and parse announcements. It will be able to track the 307 presence of all the servers to which the compromised client was 308 paired. It may be able to track other clients of these servers if 309 it can infer that multiple independent instances are tied to the 310 same server, for example by assessing the IP address associated 311 with a specific instance. It will not be able to impersonate the 312 servers for other clients. 314 Group public keys: With a valid group private key, the adversary can 315 issue queries and parse announcements. It will be able to track 316 the presence of all the servers with which the compromised group 317 was authenticated. It may be able to track other clients of these 318 servers if it can infer that multiple independent instances are 319 tied to the same server, for example by assessing the IP address 320 associated with a specific instance. It will not be able to 321 impersonate the servers for other clients or groups. 323 Shared symmetric secret: With a valid discovery secret, the 324 adversary can issue queries and parse announcements. It will be 325 able to track the presence of all the servers that the compromised 326 client could discover. It will also be able to detect the clients 327 that try to use one of these servers. This will not reveal the 328 identity of the client, but it can provide clues for network 329 analysis. The adversary will also be able to spoof the server's 330 announcements, which could be the first step in a server 331 impersonation attack. 333 Shared public secret: With a valid discovery public key, the 334 adversary can issue queries and parse announcements. It will be 335 able to track the presence of all the servers that the compromised 336 client could discover. It will also be able to detect the clients 337 that try to use one of these servers. This will not reveal the 338 identity of the client, but it can provide clues for network 339 analysis. The adversary will not be able to spoof the server's 340 announcements, or to impersonate the server. 342 4.2. Revocation 344 Assume an administrator discovers that a client has been compromised. 345 As seen in Section 4.1, compromising a client entails a loss of 346 privacy for all the servers that the client was authorized to use, 347 and also to all other users of these servers. The worse situation 348 happens in the solutions based on "discovery secrets", but no 349 solution provides a great defense. The administrator will have to 350 remedy the problem, which means different actions based on the 351 different solutions: 353 Pairing secrets: The administrator will need to revoke the pairing 354 keys used by the compromised client. This implies contacting the 355 O(M) servers to which the client was paired. 357 Group public key: The administrator must revoke the private key 358 associated with the compromised group members and, depending on 359 the cryptographic scheme in use, generate new private keys for 360 each existing, non-compromised group member. The latter is 361 necessary for public key encryption schemes wherein group access 362 is permitted based on ownership (or not) to an included private 363 key. Some public key encryption schemes permit revocation without 364 rotating any non-compromised group member private keys. 366 Shared symmetric secret: The administrator will need to revoke the 367 discovery secrets used by the compromised client. This implies 368 contacting the O(M) servers that the client was authorized to 369 discover, and then the O(N) clients of each of these servers. 370 This will require a total of O(N*M) management operations. 372 Shared public secret: The administrator will need to revoke the 373 discovery public keys used by the compromised client. This 374 implies contacting the O(M) servers that the client was authorized 375 to discover, and then the O(N) clients of each of these servers. 376 Just as in the case of discovery secrets, this will require O(N*M) 377 management operations. 379 The revocation of public keys might benefit from some kind of 380 centralized revocation list, and thus may actually be easier to 381 organize than simple scaling considerations would dictate. 383 4.3. Effect of compromized server 385 If a server is compromised, an adversary will take possession of the 386 secrets owned by that server. The effects are pretty much the same 387 in all configurations. With a set of valid credentials, the 388 adversary can impersonate the server. It can track all of the 389 server's clients. There are no differences between the various 390 solutions. 392 As remedy, once the compromise is discovered, the administrator will 393 have to revoke the credentials of O(N) clients, or O(G) groups, 394 connected to that server. In all cases, this could be done by 395 notifying all potential clients to not trust this particular server 396 anymore. 398 5. Summary of tradeoffs 400 In the preceding sections, we have reviewed the scaling and privacy 401 properties of three possible secret sharing solutions for privacy 402 discovery. The comparison can be summed up as follow: 404 +-------------------------+---------+------------+-------------+ 405 | Solution | Scaling | Resistance | Remediation | 406 +-------------------------+---------+------------+-------------+ 407 | Pairing secret | Poor | Bad | Good | 408 | Group public key | Medium | Bad | Maybe | 409 | Shared symmetric secret | Good | Really bad | Poor | 410 | Shared public secret | Good | Bad | Maybe | 411 +-------------------------+---------+------------+-------------+ 413 Table 1: Comparison of secret sharing solutions 415 All four types of solutions provide reasonable privacy when the 416 secrets are not compromised. They all have poor resistance to the 417 compromise of a client, as explained in Section 4.1, but sharing a 418 symmetric secret is much worse because it does not prevent server 419 impersonation. The pairing secret solution scales worse than the 420 discovery secret and discovery public key solutions. The group 421 public key scales as the number of groups for the total set of 422 clients; this depends on group assignment and will be intermediate 423 between the pairing secret and shared secret solutions. The pairing 424 secret solution can recover from a compromise with a smaller number 425 of updates, but the public key solutions may benefit from a simple 426 recovery solution using some form of "revocation list". 428 6. Security Considerations 430 This document does not specify a solution, but discusses future 431 choices when providing privacy for discovery protocols. 433 7. IANA Considerations 435 This draft does not require any IANA action. 437 8. Acknowledgments 439 This draft results from initial feedback in the DNS SD working group 440 on [I-D.ietf-dnssd-privacy]. The text on Group public keys is based 441 on Chris Wood's contributions. 443 9. Informative References 445 [I-D.ietf-dnssd-pairing] 446 Huitema, C. and D. Kaiser, "Device Pairing Using Short 447 Authentication Strings", draft-ietf-dnssd-pairing-04 (work 448 in progress), April 2018. 450 [I-D.ietf-dnssd-privacy] 451 Huitema, C. and D. Kaiser, "Privacy Extensions for DNS- 452 SD", draft-ietf-dnssd-privacy-04 (work in progress), April 453 2018. 455 [KW14a] Kaiser, D. and M. Waldvogel, "Adding Privacy to Multicast 456 DNS Service Discovery", DOI 10.1109/TrustCom.2014.107, 457 2014, . 460 [KW14b] Kaiser, D. and M. Waldvogel, "Efficient Privacy Preserving 461 Multicast DNS Service Discovery", 462 DOI 10.1109/HPCC.2014.141, 2014, 463 . 466 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 467 DOI 10.17487/RFC6762, February 2013, 468 . 470 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 471 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 472 . 474 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 475 and P. Hoffman, "Specification for DNS over Transport 476 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 477 2016, . 479 [SIGMA] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc'approach to 480 authenticated Diffie-Hellman and its use in the IKE 481 protocols", 2003, . 484 [Wu16] Wu, D., Taly, A., Shankar, A., and D. Boneh, "Privacy, 485 discovery, and authentication for the internet of things", 486 2016, . 488 Appendix A. Survey of Implementations 490 This section surveys several private service discovery designs in the 491 context of the threat model detailed above. 493 A.1. DNS-SD Privacy Extensions 495 Huitema and Kaiser [I-D.ietf-dnssd-privacy] decompose private service 496 discovery into two stages: (1) identify specific peers offering 497 private services, and (2) issue unicast DNS-SD queries to those hosts 498 after connecting over TLS using a previously agreed upon pre-shared 499 key (PSK), or pairing key. Any out-of-band pairing mechanism will 500 suffice for PSK establishment, though the authors specifically 501 mention [I-D.ietf-dnssd-pairing] as the pairing mechanism. Step (1) 502 is done by broadcasting "private instance names" to local peers, 503 using service-specific pairing keys. A private instance name N' for 504 some service with name N is composed of a unique nonce r and 505 commitment to r using N_k. Commitments are constructed by hashing 506 N_k with the nonce. Only owners of N_k may verify its correctness 507 and, upon doing so, answer as needed. The draft recommends 508 randomizing hostnames in SRV responses along with other identifiers, 509 such as MAC addresses, to minimize likability to specific hosts. 510 Note that this alone does not prevent fingerprinting and tracking 511 using that hostname. However, when done in conjunction with steps 512 (1) and (2) above, this mitigates fingerprinting and tracking since 513 different hostnames are used across venues and real discovered 514 services remain hidden behind private instance names. 516 After discovering its peers, a node will directly connect to each 517 device using TLS, authenticated with a PSK derived from each 518 associated pairing key, and issue DNS-SD queries per usual. DNS 519 messages are formulated as per [RFC7858]. 521 As an optimization, the authors recommend that each nonce be 522 deterministically derived based on time so that commitment proofs may 523 be precomputed asynchronously. This avoids O(N*M) computation, where 524 N is the number of nodes in a local network and M is the number of 525 per-node pairings. 527 This system has the following properties: 529 1. Symmetric work load: clients and servers can pre-compute private 530 instance names as a function of their pairing secret and 531 predictable nonce. 533 2. Mutual identity privacy: Both client and server identities are 534 hidden from active and passive attackers that do not subvert the 535 pairing process. 537 3. No client set size hiding: The number of private instance names 538 reveals the number of unique pairings a server has with its 539 clients. (Servers may pad the list of records with random 540 instance names, though this introduces more work for clients.) 542 4. Unlinkability: Private service names are unlinkable to post- 543 discovery TLS connections. (Note that if deterministic nonces 544 repeat, servers risk linkability across private service names.) 546 5. No fingerprinting: Assuming servers use fresh nonces per private 547 instance name, advertisements change regularly. 549 A.2. Private IoT 551 Boneh et al. [Wu16] developed an approach for private service 552 discovery that reduces to private mutual authentication. Moreover, 553 it should be infeasible for any adversary to forge advertisements or 554 impersonate anyone else on the network. Specifically, service 555 discoverers only wish to reveal their identity to services they 556 trust, and vice versa. Existing protocols such as TLS, IKE, and 557 SIGMA [SIGMA] require that one side reveal its identity first. Their 558 approach first allocates, via some policy manager, key pairs 559 associated with human-readable policy names. For example, user Alice 560 might have a key pair associated with the names /Alice, /Alice/ 561 Family, and /Alice/Device. Her key is bound to each of these names. 562 Authentication policies (and trust models) are then expressed as 563 policy prefix patterns, e.g., /Alice/*. Broadcast messages are 564 encrypted to policies. For example, Alice might encrypt a message m 565 to the policy /Bob/*. Only Bob, who owns a private key bound to, 566 e.g., /Bob/Devices, can decrypt m. (This procedure uses a form of 567 identity-based encryption called prefix-based encryption. Readers 568 are referred to [Wu16] for a thorough description.) 569 Using prefix- and policy-based encryption, service discovery is 570 decomposed into two steps: (1) service announcement and (2) key 571 exchange, similar to [I-D.ietf-dnssd-privacy]. Announcements carry 572 service identities, ephemeral key shares, and a signature, all 573 encrypted under the service's desired policy prefix, e.g., /Alice/ 574 Family/*. Upon receipt of an announcement, clients with matching 575 policy private keys can decrypt the announcement and use the 576 ephemeral key share to perform an Authenticated Diffie Hellman key 577 exchange with the service. Upon completion, the derived shared 578 secret may be used for any further communication, e.g., DNS-SD 579 queries, if needed. 581 This system has the following properties: 583 1. Asymmetric work load: computation for clients is on the order of 584 advertisements. 586 2. Mutual identity privacy: Both client and server identities are 587 hidden from active and passive attackers. 589 3. Client set size hiding: Policy-based encryption advertisements 590 hides the number of clients with matching policy keys. 592 4. Unlinkability: Client initiated connections are unlinkable to 593 service advertisements (modulo network-layer connection 594 information, such as advertisement origin and connection 595 destination). 597 Author's Address 599 Christian Huitema 600 Private Octopus Inc. 601 Friday Harbor, WA 98250 602 U.S.A. 604 Email: huitema@huitema.net