idnits 2.17.1 draft-arkko-abcd-distributed-resolver-selection-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2020) is 1506 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 579 -- Looks like a reference, but probably isn't: '2' on line 581 -- Looks like a reference, but probably isn't: '3' on line 584 == Unused Reference: 'MSCVUS' is defined on line 573, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-levine-dbound-dns-03 == Outdated reference: A later version (-02) exists of draft-schinazi-httpbis-doh-preference-hints-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Informational M. Thomson 5 Expires: September 11, 2020 Mozilla 6 T. Hardie 7 Google 8 March 10, 2020 10 Selecting Resolvers from a Set of Distributed DNS Resolvers 11 draft-arkko-abcd-distributed-resolver-selection-01 13 Abstract 15 This memo discusses the use of a set of different DNS resolvers to 16 reduce privacy problems related to resolvers learning the Internet 17 usage patterns of their clients. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 11, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Operational Context . . . . . . . . . . . . . . . . . . . . . 4 55 3. Goals and Constraints . . . . . . . . . . . . . . . . . . . . 4 56 4. Query distribution strategies . . . . . . . . . . . . . . . . 6 57 4.1. Client-based . . . . . . . . . . . . . . . . . . . . . . 6 58 4.1.1. Analysis of client-based selection . . . . . . . . . 6 59 4.1.2. Enhancements to client-based selection . . . . . . . 7 60 4.2. Name-based . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.2.1. Name reduction . . . . . . . . . . . . . . . . . . . 8 62 5. Early conclusions . . . . . . . . . . . . . . . . . . . . . . 9 63 5.1. Analysis conclusions . . . . . . . . . . . . . . . . . . 9 64 5.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 9 65 5.3. Poor distribution strategies . . . . . . . . . . . . . . 9 66 6. Effects of query distribution . . . . . . . . . . . . . . . . 10 67 6.1. Caching considerations . . . . . . . . . . . . . . . . . 10 68 6.2. Consistency considerations . . . . . . . . . . . . . . . 10 69 6.3. Resolver load distribution and failover . . . . . . . . . 11 70 6.4. Query performance . . . . . . . . . . . . . . . . . . . . 11 71 6.5. Debugging . . . . . . . . . . . . . . . . . . . . . . . . 11 72 7. Further work . . . . . . . . . . . . . . . . . . . . . . . . 11 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 75 8.2. Informative References . . . . . . . . . . . . . . . . . 12 76 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 The DNS [DNS] is a complex system with many different security 83 issues, challenges, deployment models and usage patterns. This 84 document focuses on one narrow aspect within DNS and its security. 86 Traditionally, systems are configured with a single DNS recursive 87 resolver, or a set of primary and alternate recursive resolvers. 88 Recursive resolver services are offered by organisations such as 89 enterprises, ISPs, and global providers. Even when clients use 90 alternate recursive resolvers, they are typically all provided by the 91 same organisation. 93 The resolvers will learn the Internet usage patterns of their 94 clients. A client might decide to trust a particular recursive 95 resolver with information about DNS queries. However, it is 96 difficult or impossible to provide any guarantees about data handling 97 practices in the general case. And even if a service can be trusted 98 to respect privacy with respect to handling of query data, legal and 99 commercial pressures or surveillance activity could result in misuse 100 of data. Similarly, outside attacks may occur towards any DNS 101 services. For a service with many clients, these risks are 102 particularly undesirable. 104 This memo discusses whether DNS clients can improve their privacy 105 through the potential use of a set of multiple recursive resolver 106 services. The goal is indeed an improvement only. There is no 107 expectation that it would be possible to have no part of the DNS 108 infrastructure aware of what queries are being made, but perhaps 109 there are mitigations that would make possible information collection 110 from the DNS infrastructure harder. 112 It should be understood that this is a narrow aspect within a bigger 113 set of topics even within privacy issues around DNS, let alone other 114 security issues, deployment models, or the many protocol questions 115 within DNS. Some of these other topics include detecting the 116 tampering DNS query responses [DNSSEC], encrypting DNS queries [DOT] 117 [DOH], application-specific DNS resolution mechanisms, or centralised 118 deployment models. Those other topics are not covered in this memo 119 and need to be dealt with elsewhere. 121 Specifically, the scope of this memo is not limited to DNS-over-TLS 122 (DOT) or DNS-over-HTTPS (DOH) deployments nor does it take a stand on 123 operating system vs. application or local vs. centralized DNS 124 deployment models. This memo is intended to provide useful 125 information for those that wish to consider trustworthiness of their 126 recursive resolvers as a part of their privacy analysis. 128 Naturally, there are some interactions between different topics. For 129 instance, privacy is affected both by what happens to data in transit 130 and at the endpoints, so where privacy is a concern, one would expect 131 to consider both aspects, and lack of consideration on one probably 132 leads to issues that dwarf the problems that this memo can address. 133 Both issues are also important aspects when considering defense again 134 pervasive monitoring efforts [PMON]. 136 The rest of this memo is organized as follows. Section 2 discusses 137 the operational context that we imagine the multiple recursive 138 resolver arrangement might be applied in. Section 3 specifies 139 security goals for a system that employs multiple recursive 140 resolvers. 142 One key aspect of a system using multiple resolvers would be how to 143 select which particular recursive resolver to use in a particular 144 situation. This is discussed in Section 4. This section covers a 145 number of possible strategies and further considerations for this 146 selection, along with an analysis of the implications of choosing a 147 particular strategy. There are technical issues in the use of 148 multiple recursive resolvers, and there are both technical and non- 149 technical questions in deciding on what recursive resolvers should 150 even be in the set. 152 Some early recommendations are provided in Section 5. Section 6 153 discusses operational and other implications of the distributed 154 approach. Finally, Section 7 discusses potential further work in 155 this area. 157 2. Operational Context 159 Our perspective is that of a client, choosing to either distribute or 160 not distribute its queries to a set of different resolvers. And if 161 the client decides to use distribution, it can choose exactly how it 162 does that. 164 There are obviously additional operational aspect of this - such as 165 central configuration mechanisms, resolver selection application 166 choices, and so on. But these are not covered in this memo. 168 It should also be observed that the practices suggested in this memo 169 are currently not widely used. Operational and other issues may be 170 discovered, such as those outlined in Section 6. 172 Many of these issues need further work, but this memo aims to discuss 173 the concept and analyse its impacts before dwelling into the 174 technical arrangements for configuring and using this particular 175 approach. 177 3. Goals and Constraints 179 This document aims to reduce the concentration of information about 180 client activity by distributing DNS queries across different resolver 181 services, for all DNS queries in the aggregate and for DNS queries 182 made by individual clients. By distributing queries in this way, the 183 goal is to reduce the amount of information that any given DNS 184 resolver service can acquire about client activity. As such, creates 185 a benefit for the client, but also makes these resolvers less 186 valuable targets for attacks relating to that client's activity. 188 Any method for distributing queries from a single client needs to 189 consider these benefits with regards to the following constraints: 191 o A careful selection of the set of trusted resolvers must be the 192 first priority. It does not make sense to add less trustworthy 193 resolvers merely for the sake of distribution. For instance, 194 there is no reason to mix resolvers with good reliability or high 195 degree of privacy regulation with other resolvers: just include 196 the best resolvers in the set. 198 o As the goal is to reduce the amount of information given to any 199 given resolver, a strategy that tells the same information to all 200 resolvers is a poor one. A design that results in replicating the 201 same query toward multiple services would thus be a net privacy 202 loss. This happens quite easily over a long period of time, 203 unless the distribution method is carefully designed. 205 More subtle leaks arise as a result of distributing queries for 206 sub-domains and even domains that are superficially unrelated, 207 because these could share a commonality that might be exploited to 208 link them. For instance, some web sites use names that are appear 209 unrelated to their primary name for hosting some kinds of content, 210 like static images or videos. If queries for these unrelated 211 names were sent to different services, that effectively allows 212 multiple resolvers to learn that the client accessed the web site. 214 A distribution scheme also needs to consider stability of query 215 routing over time. A resolver can observe the absence of queries and 216 infer things about the state of a client cache, which can reveal that 217 queries were made to other resolvers. In general, different queries 218 for the same resolution context, such as sub-resources for a web page 219 load, which have some probability of being related or linked, should 220 be sent to the same resolver. Failure to do so reveals information 221 to more than one resolver. 223 In effect, there are two goals in tension: 225 o split queries between as many different resolvers as possible; and 227 o reduce the spread of linkable queries across multiple resolvers. 229 The need to limit replication of private information about queries 230 eliminates naive distribution schemes, such as those discussed in 231 Section 5.3. The designs described in Section 4 all attempt to 232 balance these different goals using different properties from the 233 context of a query (Section 4.1) or the query name itself 234 (Section 4.2). 236 4. Query distribution strategies 238 This section introduces and analyzes several potential strategies for 239 distributing queries to different resolvers. Each strategy is 240 formulated as an algorithm for choosing a resolver Ri from a set of n 241 resolvers {R1, R2, ..., Rn}. 243 The designs presented in Section 4 assume that the stub resolver 244 performing distribution of queries has varying degrees of contextual 245 information. In general, more contextual information allows for 246 finer-grained distribution of information between resolvers. 248 4.1. Client-based 250 The simplest strategy is to distribute each different client to a 251 different resolver. This reduces the number of users any particular 252 service will know about. However, this does little to protect an 253 individual user from the aggregation of information about queries at 254 the selected resolver. 256 In this design clients select and consistently use the same resolver. 257 This might be achieved by randomly selecting and remembering a 258 resolver. Alternatively, a resolver might be selected using 259 consistent hashing that takes some conception of client identity as 260 input: 262 i = h(client identity) % n 264 For the purposes of this determination, a client might be an entire 265 device, with the selection being made at the operating system level, 266 or it could be a selection made by individual applications. In the 267 extreme, an individual application might be able to partition its 268 activities in a way that allows it to direct queries to multiple 269 resolvers. 271 4.1.1. Analysis of client-based selection 273 This is a simple and effective strategy, but while it provides 274 distribution of DNS queries in the aggregate, it does little to 275 divide information about a particular client between resolvers. It 276 effectively only reduces the number of clients that each resolver can 277 acquire information about. This provides systemic benefit, but does 278 not provide individual clients with any significant advantage as 279 there is still some resolver service that has a complete view of the 280 user's DNS usage patterns. 282 In addition, there are specific issues where this selection method is 283 used in particular deployment modes. Where different applications 284 make independent resolver selections, activities that involve 285 multiple applications can result in information about those 286 activities being exposed to multiple resolvers. For instance, an 287 application could open another application for the purposes of 288 handling a specific file type or to load a URL. This could expose 289 queries related to the activity as a whole to multiple resolvers. 291 Making different selections at the level of a device resolves this 292 issue. But of course it is still possible that an individual who 293 uses multiple devices might perform similar activities on those 294 devices, but have DNS queries distributed to different resolvers, 295 resulting in replicating that individual's information to multiple 296 resolvers. The individual may or may not be identifiable through 297 fingerprinting of the specific set of queries being made from the 298 devices. 300 4.1.2. Enhancements to client-based selection 302 Clients can break continuity of records by occasionally resetting 303 state so that a different resolver is selected. A client might 304 choose to do this when it moves to a new network location, and may 305 otherwise appear as a new client its current resolver. But it is 306 unclear if there's a sufficient advantage to breaking continuity, as 307 the potential benefits are offset by the client's information being 308 disclosed to several resolvers as part of performing a series of 309 resets. And it is possible that a particular individual's usage 310 patterns can be identified across network locations and periods of 311 using other resolvers. 313 Breaking continuity is less effective if any state, in particular 314 cached results, is retained across the change. If activities that 315 depend on DNS querying are continued across the change then it might 316 be possible for the old resolver to make inferences about the 317 activity on the new resolver, or the new resolver to make similar 318 guesses about past activity. As many modern applications provide 319 session continuity features across shutdowns and crashes, this can 320 mean that finding an appropriate point in time to perform a switch 321 can be difficult. 323 4.2. Name-based 325 Clients might also additionally attempt to distribute queries based 326 on the name being queried. This results in different names going to 327 different resolvers. 329 A naive algorithm for name distribution uses the target name as input 330 to a fixed hash: 332 i = h(queried name) % n 334 However, this simplistic approach fails to prevent related queries 335 from being distributed to different resolvers in several ways. For 336 instance, queries that are executed after receiving a CNAME record in 337 a response will leak the same information as the original query that 338 resulted in the CNAME record. Services that use related domain names 339 - such as where "example.com" uses "static.example.com" or 340 "cdn.example.net" - might reveal the use of the combined service to a 341 resolver that receives a query for any associated name. In both 342 cases, sensitive information is effectively replicated across 343 multiple resolvers. 345 4.2.1. Name reduction 347 In order to reduce the effect of distributing similar names to 348 different servers, a grouping mechanism might be used. Leading 349 labels in names might be erased before being input to the hashing 350 algorithm. This requires that the part of the suffix that is shared 351 between different services can be identified. For the purposes of 352 ensuring that queries are consistently routed to the same resolver, a 353 weak signal is likely sufficient. 355 Several options for grouping domain names into equivalence sets might 356 be used: 358 o The public suffix list [1] provides a manually curated list of 359 shared domain suffixes. Names can be reduced to include one label 360 more than the list allows, referred to as effective top-level 361 domain plus one (eTLD+1). This reduces the number of cases where 362 queries for domains under the same administrative control are sent 363 to different resolvers. 365 o Services often relies on multiple domain names across different 366 eTLD+1 domains. Developing equivalence sets might be needed to 367 avoid broadcasting queries to servers. Mozilla maintains a 368 manually curated equivalence list [2] for web sites that aims to 369 maps the complete set of unrelated names used by services to a 370 single service name. 372 o Other technologies, such as the proposed first party sets [3] or 373 the abandoned DBOUND [DBOUND] provide domain owners a means to 374 declare some form of equivalence for different names. 376 Each of these techniques are imperfect in different ways. They may 377 also skew the distribution of queries in ways that might concentrate 378 information on particular resolvers. Moreover, resolver choice based 379 solely on the name to be resolved rather than per-client information 380 reduces the anonymity set of queries sent to each resolver. In 381 contrast to a client-based strategy, attackers can predict the target 382 resolver for a given name using a name-based strategy. This may have 383 implications for on-path attacker attempts to identify otherwise 384 encrypted queries. Of course, even a name-based mechanism might use 385 some non-public information as well for its choice, which might 386 reduce these issues. 388 5. Early conclusions 390 5.1. Analysis conclusions 392 Both the client-based and more advanced name-based strategies may 393 provide benefits. The former may provide primarily a systemic 394 benefit, while the latter may provide also some privacy benefits to 395 each individual client. However, neither strategy is perfect, and 396 can leak the same information to multiple resolvers in some cases. 398 5.2. Recommendations 400 Both strategies are, however, likely generally beneficial in the 401 common cases, and can improve the overall privacy situation. And 402 they are certainly a considerable privacy improvement over a 403 situation where a large number of clients use a single resolver. 405 Their use may also reduce any pressures against specific resolvers, 406 as information available in these specific resolvers does not 407 constitute all information about all clients. As such, the use of 408 one of these distribution strategies is tentatively recommended, 409 subject to further testing, discussion, and resolving any remaining 410 operational issues. 412 The naive name-based strategy is, however, not recommended, and 413 neither are other, even simpler strategies listed in Section 5.3. It 414 should be noted that no technique presented in this memo can defend 415 against a situation where an actor such as a surveillance agency has 416 access to information from all resolvers. 418 5.3. Poor distribution strategies 420 Random allocation to a resolver might be implemented: 422 i = rand() % n 424 Similar drawbacks can be seen where clients iterate over available 425 resolvers: 427 i = counter++ % n 428 Whether this choice is made on a per-query basis, these two methods 429 eventually provide information about all queries to all resolvers 430 over time. Domain names are often queried many times over long 431 periods, so queries for the same domain name will eventually be 432 distributed to all resolvers. Only one-off queries will avoid being 433 distributed. 435 Implementing either method at a much slower cadence might be 436 effective, subject to the constraints in Section 4.1.2. This only 437 slows the distribution of information about repeated queries to all 438 resolvers. 440 6. Effects of query distribution 442 Choosing to use more than one DNS resolver has broader implications 443 than just the effect on privacy. Using multiple resolvers is a 444 significant change from the assumed model where stub resolvers send 445 all queries to a single resolver. 447 6.1. Caching considerations 449 Using a common cache for multiple resolvers introduces the 450 possibility that a resolver could learn about queries that were 451 originally directed to another resolvers by observing the absence of 452 queries. Though this can reduce caching performance, clients can 453 address this by having a per-resolver cache and only using the cache 454 for the selected resolver. 456 6.2. Consistency considerations 458 Making the same query to multiple resolvers can result in different 459 answers. For instance, DNS-based load balancing can lead to 460 different answers being produced over time or for different query 461 origins. Or, different resolvers might have different policies with 462 respect to blocking or filtering of queries that lead to clients 463 receiving inconsistent answers. 465 In the extreme, an application might encounter errors as a result of 466 receiving incompatible answers, particularly if a server operator 467 (incorrectly) assumes that different DNS queries for the same client 468 always originate from the same source address. This is most likely 469 to occur if name-based selection is used, as queries could be related 470 based on information that the client does not consider. 472 6.3. Resolver load distribution and failover 474 Any selection of resolvers that is based on random inputs will need 475 to account for available capacity on resolvers. Otherwise, resolvers 476 with less available query-processing capacity will receive too high a 477 proportion of all queries. Clients only need to be informed of 478 relative available capacity in order to make an appropriate 479 selection. How relative capacities of resolvers are determined is 480 not in scope for this document. 482 The choice of different resolvers would also need to work well with 483 whatever mechanisms exist for failover to alternate resolvers when 484 one is not responsive. The same is true of IPv4/IPv6 connectivity, 485 the availability of communications to specific ports, etc. And the 486 dynamic situation should obviously not lead to extensive leakage to 487 different resolvers, either. 489 6.4. Query performance 491 Distribution of queries between resolvers also means that clients are 492 exposed to greater variations in performance [HBSHF19]. In contrast, 493 using a single resolver, as would result from the client-based method 494 in Section 4.1, promotes use of a persistent connection. 496 6.5. Debugging 498 The use of multiple resolvers may complicate debugging. 500 7. Further work 502 Should there be interest in the deployment of ideas laid out in this 503 memo, further work is needed. There would have to be ways to 504 configure systems to use multiple resolvers, including for instance: 506 o Central configuration mechanisms to enable the use of multiple 507 resolvers, perhaps through usual network configuration mechanisms 508 or choices made by applications using resolver services directly. 509 It may also be necessary to employ discovery mechanisms, such as, 510 e.g., [I-D.schinazi-httpbis-doh-preference-hints] or 511 [I-D.pauly-dprive-adaptive-dns-privacy] (but see Section 3) 513 o Mechanisms to allow both failover to working resolvers when a 514 resolver is unreachable, 516 o Additional testing for potential operational issues discussed in 517 Section 2 would be beneficial. 519 Finally, more work is needed to determine factors other than privacy 520 that could motivate having queries routed to the same resolver. The 521 choice between different approaches is often a combination of several 522 factors, and privacy is only one of those factors. 524 8. References 526 8.1. Normative References 528 [DNS] Mockapetris, P., "Domain names - implementation and 529 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 530 November 1987, . 532 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 533 Rose, "DNS Security Introduction and Requirements", 534 RFC 4033, DOI 10.17487/RFC4033, March 2005, 535 . 537 [DOH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 538 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 539 . 541 [DOT] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 542 and P. Hoffman, "Specification for DNS over Transport 543 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 544 2016, . 546 [PMON] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 547 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 548 2014, . 550 8.2. Informative References 552 [DBOUND] Levine, J., "Publishing Organization Boundaries in the 553 DNS", draft-levine-dbound-dns-03 (work in progress), April 554 2019. 556 [HBSHF19] Austin Hounsel, ., Kevin Borgolte, ., Paul Schmidt, ., 557 Jordan Holland, ., and . Nick Feamster, "Analyzing the 558 Costs (and Benefits) of DNS, DoT, andDoH for the Modern 559 Web", ANRW '19, July 22, 2019, Montreal, QC, Canada , 560 n.d., . 562 [I-D.pauly-dprive-adaptive-dns-privacy] 563 Kinnear, E., Pauly, T., Wood, C., and P. McManus, 564 "Adaptive DNS: Improving Privacy of Name Resolution", 565 draft-pauly-dprive-adaptive-dns-privacy-01 (work in 566 progress), November 2019. 568 [I-D.schinazi-httpbis-doh-preference-hints] 569 Schinazi, D., Sullivan, N., and J. Kipp, "DoH Preference 570 Hints for HTTP", draft-schinazi-httpbis-doh-preference- 571 hints-01 (work in progress), January 2020. 573 [MSCVUS] Wikipedia, ., "Microsoft Corp. v. United States", 574 https://en.wikipedia.org/wiki/ 575 Microsoft_Corp._v._United_States , n.d.. 577 8.3. URIs 579 [1] https://publicsuffix.org/ 581 [2] https://github.com/mozilla-services/shavar-prod- 582 lists/blob/master/disconnect-entitylist.json 584 [3] https://github.com/krgovind/first-party-sets 586 Appendix A. Acknowledgements 588 The authors would like to thank Christian Huitema, Ari Keraenen, Mark 589 Nottingham, Stephen Farrell, Gonzalo Camarillo, Mirja Kuehlewind, 590 David Allan, Daniel Migault, Goran AP Eriksson, Christopher Wood, and 591 many others for interesting discussions in this problem space. 593 Authors' Addresses 595 Jari Arkko 596 Ericsson 598 Email: jari.arkko@piuha.net 600 Martin Thomson 601 Mozilla 603 Email: martin.thomson@gmail.com 605 Ted Hardie 606 Google 608 Email: ted.ietf@gmail.com