idnits 2.17.1 draft-am-dprive-eval-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There is 1 instance of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2015) is 3111 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Entities' is mentioned on line 513, but not defined == Missing Reference: 'Links' is mentioned on line 513, but not defined == Missing Reference: 'S' is mentioned on line 815, but not defined == Missing Reference: 'P' is mentioned on line 815, but not defined == Missing Reference: 'R' is mentioned on line 815, but not defined == Missing Reference: 'A' is mentioned on line 815, but not defined == Missing Reference: 'S-P' is mentioned on line 771, but not defined == Missing Reference: 'P-R' is mentioned on line 771, but not defined == Missing Reference: 'R-A' is mentioned on line 815, but not defined == Missing Reference: 'RA' is mentioned on line 771, but not defined -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Mohaisen 3 Internet-Draft SUNY Buffalo 4 Intended status: Informational A. Mankin 5 Expires: April 20, 2016 Verisign Labs 6 October 18, 2015 8 Evaluation of Privacy for DNS Private Exchange 9 draft-am-dprive-eval-02 11 Abstract 13 The set of DNS requests that an individual makes can provide a 14 monitor with a large amount of information about that individual. 15 DNS Private Exchange (DPRIVE) aims to deprive this actor of this 16 information. This document describes methods for measuring the 17 performance of DNS privacy mechanisms, particularly it provides 18 methods for measuring effectiveness in the face of pervasive 19 monitoring as defined in RFC7258. The document includes example 20 evaluations for common use cases. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 20, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Privacy Evaluation Definitions . . . . . . . . . . . . . . . 4 58 2.1. Entities . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Data and Analysis . . . . . . . . . . . . . . . . . . . . 5 60 2.3. Identifiability . . . . . . . . . . . . . . . . . . . . . 5 61 2.4. Other Central Definitions and Formalizations . . . . . . 6 62 3. Assumptions about Quantification of Privacy . . . . . . . . . 8 63 4. System Model . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4.1. DNS Resolvers (System Model) . . . . . . . . . . . . . . 9 65 4.2. System Setup - Putting It Together . . . . . . . . . . . 9 66 5. Risk Model . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 5.1. Risk Type-1 - Passive Pervasive Monitor . . . . . . . . . 11 68 5.2. Risk Type-2 - Active Monitor . . . . . . . . . . . . . . 11 69 5.3. Risks in the System Setup . . . . . . . . . . . . . . . . 11 70 6. Privacy Mechanisms . . . . . . . . . . . . . . . . . . . . . 12 71 7. Privacy Evaluation . . . . . . . . . . . . . . . . . . . . . 13 72 8. Other evaluation . . . . . . . . . . . . . . . . . . . . . . 20 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 74 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 75 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 76 12. Informative References . . . . . . . . . . . . . . . . . . . 20 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 79 1. Motivation 81 One of the IETF's core views is that protocols should be designed to 82 enable security and privacy while online [RFC3552]. In light of the 83 recent reported pervasive monitoring efforts, another goal is to 84 design protocols and mechanisms to make such monitoring expensive or 85 infeasible to conduct. As detailed in the DPRIVE problem statement 86 [RFC7626], DNS resolution is an important arena for pervasive 87 monitoring, and in some cases may be used for breaching the privacy 88 of individuals. The set of DNS requests that an individual makes can 89 provide a large amount of information about that individual. In some 90 specific use cases, the sets of DNS requests from a DNS recursive 91 resolver or other entity may also provide revealing information. 92 This document describes methods for measuring the performance of DNS 93 privacy mechanisms; in particular, it provides methods for measuring 94 effectiveness in the face of pervasive monitoring as defined in 95 [RFC7258]. The document includes example evaluations for common use 96 cases. 98 The privacy threats associated with DNS monitoring are not new, 99 however they were made more obvious by the issue described in 100 [RFC7258]. The DPRIVE working group was formed to respond and at 101 this time has several DNS private exchange mechanisms in 102 consideration, including [dns-over-tls], [confidential-dns], 103 [phb-dnse], and [privatedns]. There is also related work in other 104 working groups, including DNSOP: [qname-minimisation] and 105 (potentially) DANE [ipseca]. The recently published RFC on 106 opportunistic security [RFC7435] also has relevance to DNS private 107 exchange. 109 Each effort related to DNS privacy mechanisms asserts some privacy 110 assurances and operational relevance. Metrics for these privacy 111 assurances are needed and are in reach based on existing techniques 112 from the general field of privacy engineering. Systematic evaluation 113 of DNS privacy mechanisms will enhance the likely operational 114 effectiveness of DNS private exchange. 116 Evaluating an individual mechanism for DNS privacy could be 117 accomplished on a one-off basis, presumably as Privacy Considerations 118 within each specification, but this will not address as much 119 variation of operational contexts nor will it cover using multiple 120 mechanisms together (in composition). Section 2 of [RFC6973] 121 discussed both benefits and risks of using multiple mechanisms. 123 Definitions required for evaluating the privacy of stand-alone and 124 composed design are not limited to privacy notions, but also need to 125 include the risk model and some information about relationships among 126 the entities in a given system. A mechanism for providing privacy to 127 withstand the power and capabilities of a passive pervasive monitor 128 may not withstand a more powerful actor using active monitoring by 129 plugging itself into the path of individuals' DNS requests as a 130 forwarder . Having some standard models, and understanding how 131 applicable they are to various designs is a part of evaluating the 132 privacy. 134 Sections 2 and 3 present privacy terminology and some assumptions. 135 Sections 4 and 5 cover the system model or setup and the risk models 136 of interest. In Section 6, we review a list of DNS privacy 137 mechanisms, including some which are not in scope of the DPRIVE 138 working group. Section 7 tackles how to evaluate privacy mechanisms, 139 in the form of templates and outcomes. Given a specific risk model, 140 the guarantees with respect to privacy of an individual or an item of 141 interest are quantified. 143 2. Privacy Evaluation Definitions 145 This section provides definitions to be used for privacy evaluation 146 of DNS. The verbatim source of most of those definitions is from 147 [RFC6973], which are included as an aid in reasability. In some 148 definitions, text is added to apply them to the DNS case. Also, a 149 new section of terms has been added to include several important 150 practical or conventional terms that were not included in [RFC6973] 151 such as PII. For the terms from [RFC6973], we include their 152 definitions rather than simply referencing them as an aid to 153 readability. 155 2.1. Entities 157 o Attacker: An entity that works against one or more privacy 158 protection goals. Unlike observers, attackers' behavior is 159 unauthorized, in a way similar to that of an eavesdropper. 161 o Eavesdropper: A type of attacker that passively observes an 162 initiator's communications without the initiator's knowledge or 163 authorization. DNS example may include a passive pervasive 164 monitor, defined below. 166 o Enabler: A protocol entity that facilitates communication between 167 an initiator and a recipient without being directly in the 168 communications path. DNS examples of an enabler in this sense 169 include a recursive resolver, a proxy, or a forwarder. 171 o Individual: A human being (or a group of them) 173 o Initiator: A protocol entity that initiates communications with a 174 recipient. 176 o Intermediary: A protocol entity that sits between the initiator 177 (DNS example of stub resolver) and the recipient (DNS example of 178 recursive resolver or authority resolver) and is necessary for the 179 initiator and recipient to communicate. Unlike an eavesdropper, 180 an intermediary is an entity that is part of the communication 181 architecture and therefore at least tacitly authorized. 183 o Observer: An entity that is able to observe and collect 184 information from communications, potentially posing privacy risks, 185 depending on the context. As defined in this document, 186 initiators, recipients, intermediaries, and enablers can all be 187 observers. Observers are distinguished from eavesdroppers by 188 being at least tacitly authorized. 190 o We note that while the definition of an observer may include an 191 initiator in the risk model, an initiator of a request is excluded 192 in the context of this document, because it corresponds to the 193 subject of interest being studied. Similar to the definition in 194 [RFC7258], we note that an attacker is broader than an observer. 195 While [RFC7258] claim that an attack does not consider the motive 196 of the actor, the given context of DNS implies a motive if the 197 term attacker is used to characterize the risk. 199 2.2. Data and Analysis 201 We assume the following definitions related to data and analysis from 202 [RFC4949]: attacker, correlation, fingerprint, fingerprinting, item 203 of interest (IOI), personal data, interaction, traffic analysis, 204 undetectability, and unlinkability. We augment some of those 205 definitions later in this document. 207 from [RFC4949], we relax the definition of IOI to exclude "the fact 208 that a communication interaction has taken place" as this does not 209 suite the evaluated context of DNS. 211 2.3. Identifiability 213 We assume the following definitions related to identifiability from 214 [RFC4949]: anonymity, anonymity set, anonymous, attribute, identity 215 provider, personal name, and relying party. 217 The following definitions are modified for the context of this 218 document from those defined in [RFC4949] 220 o Identifiability: The extent to which an individual is 221 identifiable. [RFC6973] includes the rest of the variations on 222 this (Identifiable, Identification, Identified, Identifier, 223 Identity, Identity Confidentiality) 225 o Personal Name: A natural name for an individual. Personal names 226 are often not unique and often comprise given names in combination 227 with a family name. An individual may have multiple personal 228 names at any time and over a lifetime, including official names. 229 From a technological perspective, it cannot always be determined 230 whether a given reference to an individual is, or is based upon, 231 the individual's personal name(s) (see Pseudonym). NOTE: The 232 reason to import this definition is that some query names that 233 cause privacy leakage do so by embedding personal names as 234 identifiers of host or other equipment, e.g. 235 AllisonMankinMac.example.com. 237 o Pseudonymity: See the formal definition in section 2.4 in lieu of 238 [RFC6973]. 240 NOTE: Identifiability Definitions in [RFC6973] also include some 241 material not included here because the distinctions are not major for 242 DNS Private Exchange, such as real and official names, and variant 243 forms of Pseudonymity in its informal definition. 245 2.4. Other Central Definitions and Formalizations 247 Central to the presentation of this document is the definition of 248 personally identifiable information (PII), as well as other 249 definitions that supplement the definitions listed earlier or modify 250 them for the context of this document. In this section, we outline 251 such definitions we further notes on their indications. 253 o Personally Identifiable Information (PII): Information 254 (attributes) that can be used as is, or along with other side 255 information, to identify, locate, and/or contact a single 256 individual or subject (c.f. item of interest). 258 NOTE: the definition above indicates that PII can be used on its own 259 or in context. In DNS privacy, the items without additional context 260 include IP(v4 or v6) addresses, qname, qtype, timings of queries, 261 etc. The additional context includes organization-level attributes, 262 such as a network prefix that can be associated with an organization. 263 The definition of PII is complementary to the definition of items of 264 interest. 266 o Subject: This term is useful as a parallel term to Individual. 267 When the privacy of a group or an organization is of interest, we 268 can reference the group or organization as Subject rather than 269 Individual. 271 Often it is desirable to reference alternative identifiers known as 272 pseudonyms. A pseudonym is a name assumed by an individual in some 273 context, unrelated to the names or identifiers known by others in 274 that context. 276 o Pseudonymity/Pseudonym: a relaxation of the definition of 277 anonymity for usability. In particular, pseudonymity is an 278 anonymity feature obtained by using a pseudonym, an identifier 279 that is used for establishing a long relationship between two 280 entities. 282 As an example, in the DNS context, a randomly generated pseudonym 283 might identify a set of query data with a shared context, such as 284 geographic origin. Such pseudonymity enables another entity 285 interested in breaching the privacy to link multiple queries on a 286 long-term basis. Pseudonyms are assumed long-lived and their 287 uniqueness may be a goal. There are many findings that indicate that 288 pseudonymity is weaker than anonymity. 290 o Unlinkability: Formally, two items of interest are said to be 291 unlinkable if the certainty of an actor concerning those items of 292 interest is not affected by observing the system. This is, 293 unlinkability implies that the a-posteriori probability computed a 294 monitor that two items of interest are related is close enough to 295 the a-priori probability computed by a monitor based on their 296 knowledge. 298 Two items of interest are said to be unlinkable if there is a small 299 chance (beta, close to 0 probability) that the monitor identifies 300 them as associated, and they are linkable if there is a sufficiently 301 large probability (referred to as alpha). 303 Informally, given two items of interest (user attributes, DNS 304 queries, users, etc.), unlinkability is defined as the inability of 305 the monitor to sufficiently determine whether those items are related 306 to one another. In the context of DNS, this refers typically but not 307 only to a monitor relating queries to the same individual. 309 o Undetectability: a stronger definition of privacy, where an item 310 of interest is said to be undetectable if the monitor is not 311 sufficiently able to know or tell whether the item exists or not. 313 Note that undetectability implies unlinkability. As explained below, 314 a way of ensuring undetectability is to use encryption that is secure 315 under known ciphertext attacks, or randomized encryption. 317 o Unobservability: a stronger definition of privacy that requires 318 satisfying both undetectability and anonymity. Unobservability 319 means that an item of interest is undetectable by any not involved 320 individual, monitor or not. 322 In theory, there are many ways of ensuring unobservability by 323 fulfilling both requirements. For example, undetectability requires 324 that no party that is not invovled in the resolution of a DNS query 325 shall know that query has existed or not. A mechanism to ensure this 326 function is encryption secure under known ciphertext attacks, or 327 randomized encryption for all other than stub resolvers, and 328 pseudonyms for the stub resolver. An alternative mechanism to 329 provide the anonymity property would be the use of mix networks for 330 routing DNS queries. 332 3. Assumptions about Quantification of Privacy 334 The quantification of privacy is connected with the privacy goals. 335 Is the desired privacy property unlinkability only, or is it 336 undetectability? Is pseudonymity a sufficient property? Parameters 337 and entire privacy mechanism choices are affected by the choice of 338 privacy goals. 340 While a binary measure of privacy is sometimes possible, that is, 341 being able to say that the transaction is anonymous, in this 342 document, we assume that the binary is not frequently obtainable, and 343 therefore we focus on methods for continuous quantification. Both 344 are relevant to DNS Private Exchange. Another way to state this is 345 that the quantification could be exactly the probabilities 1 and 0, 346 corresponding to the binary, but the methods prefer to provide 347 continuous values instead. 349 Here is an example of continuous quantification, related to 350 identifiability of an individual or item of interest based on 351 observing queries. 353 o For an individual A, and a set of observations by a monitor Y, 354 where Y = [y1, y2, ... yn], we define the privacy of A as the 355 uncertainty of the monitor knowing that A is itself among many 356 others under the observations Y; that is, we define Privacy = 1 - 357 P[A | Y] 359 o For an item of interest r associated with a user A, we similarly 360 define the privacy of r as Privacy = 1 - P[r | Y]. 362 4. System Model 364 A DNS client (a DNS stub resolver) may resolve a domain name or 365 address into the corresponding DNS record by contacting the 366 authoritative name server responsible for that domain name (or 367 address) directly. However, to improve the operation of DNS 368 resolution, and reduce the round trip time required for resolving an 369 address, both caching and recursive resolution are implemented. 370 Caching is implemented at an intermediary between the stub and the 371 authoritative name server. In practice, many caching servers also 372 implement the recursive logic of DNS resolution for finding the name 373 server authoritative for a domain, and are thus called DNS recursive 374 resolvers. Another type of entity, DNS forwarders (or proxies), acts 375 as intermediaries between stub resolvers and recursive resolvers, and 376 recursive resolvers and authoritative resolvers. The system model 377 for DNS privacy evaluation includes the four entities quickly 378 sketched here: stub resolvers, recursive resolvers, authoritative 379 name servers, and forwarders. 381 4.1. DNS Resolvers (System Model) 383 o Stub resolver (S): a minimal resolver that does not support 384 referral, and delegates recursive resolution to a recursive 385 resolver. A stub resolver is a consumer of recursive resolutions. 386 Per the terminology of [RFC6973], a stub resolver is an Initiator. 388 o Recursive resolver (R): a resolver that implements the recursive 389 function of DNS resolution on behalf of a stub resolver. Per the 390 terminology of [RFC6973], a recursive resolver is an Enabler. 392 o Authoritative resolver (A): is a server that is the origin of a 393 DNS record. A recursive resolver queries the authoritative 394 resolver to resolve a domain name or address. Per the terminology 395 of [RFC6973], the authoritative name server is also an Enabler. 397 o Forwarder/proxy (P): between the stub resolver and the 398 authoritative resolver there may be one or more DNS-involved 399 entity. These are systems located between S and R (stub resolver 400 and recursive), or between R and A (recursive and authoritative), 401 which do not play a primary role in the DNS protocol. Per the 402 terminology of [RFC6973], forwarders are Intermediaries. 404 4.2. System Setup - Putting It Together 406 Evaluating various privacy protection mechanisms in relation to 407 monitors such as the pervasive monitors defined next requires 408 understanding links in the system setup. We define the following 409 links. In relation to [RFC7258] these are the attack surface where a 410 monitor (eavesdropper) can collect sets of query information. 412 o Stub -> Recursive (S-R): a link between the stub resolver and a 413 recursive resolver. At the time of writing, the scope of DPRIVE 414 Working Group privacy mechanisms is supposed to be limited to S-R. 416 o Stub -> Proxy (S-P): a link between the stub resolver and a 417 forwarder/ proxy. The intended function of this link may be 418 difficult to analyze. 420 o Proxy -> Recursive (P-R): a link between a proxy and a recursive 421 server. 423 o Recursive -> Authoritative (R-A): a link between a recursive and 424 an authoritative name server. Although at the time of writing, 425 R-A is not in the DPRIVE scope, we discuss it in the evaluation. 427 Rather than notating in system setup that an entity is compromised, 428 this is covered in the monitor model in Section 6, which has system 429 elements as parameters. 431 In the system setup, there is a possibility that S and R exist on a 432 single machine. The concept of the Unlucky Few relates S and R in 433 this case. A monitor can monitor R-A and find the query traffic of 434 the initiator individual. The same concept applies in the case where 435 a recursive is serving a relatively small number of individuals. The 436 query traffic of a subject group or organization (c.f. Subject in 437 the definitions) is obtained by the monitor who monitors this 438 system's R-A. 440 Because R-A is not in the DPRIVE scope, it is for future work to 441 examine the Unlucky Few circumstance fully. The general system setup 442 is that PII, the individual's private identifying information, is not 443 sent on R-A and is not seen by authoritative name server. 445 There could be one or more proxies between the stub resolver and a 446 recursive. From a functionality point of view they can all be 447 consolidated into a single proxy without affecting the system view. 448 However, the behavior of such proxies may affect the size and shape 449 of the attack surface. However, we believe that an additional 450 treatment is needed for this case and it is not included in the 451 discussion. 453 We also do not include in discussion proxies that exist along R-A, 454 between a recursive and an authoritative name server. We do so in 455 respect for the DPRIVE charter's scope at this time. According to 456 recent work at [openresolverproject.org], there may be multiple 457 intermediaries with poorly defined behavior. 459 The system setup here leaves out other realistic considerations for 460 simplicity, such as the impact of shared caches in DNS entities. 462 5. Risk Model 464 The Definitions section defines observer, attack and monitor, but not 465 a Risk Model, which is needed to actually evaluate privacy. 467 For consistency, we note that the only difference between an attacker 468 and an obeserver is that an attacker is an unauthorized observer with 469 all the capabilities it may have. We also stress that for the 470 context of DNS privacy, the term attacker may implicitly assume an 471 intent. To that end, active and passive observers are collectively 472 referred to as actors. 474 o Risk Model: a well-defined set of capabilities indicating how much 475 information an observer (or eavesdropper) has, and in what 476 context, in order to reach a goal of breaching the privacy of an 477 individual or subject with respect to a given privacy metric. 479 In this document we focus on two risk models, namely a pervasive 480 monitor and a malicious monitor. 482 5.1. Risk Type-1 - Passive Pervasive Monitor 484 This risk corresponds to the passive pervasive monitoring model 485 described in [RFC7258]. This model relies on monitoring capabilities 486 to breach the privacy of individuals from the DNS traffic at scale 487 without decimation. An actor causing this risk is capable of 488 eavesdropping or observing traffic between two end points, including 489 traffic between any of the pairs of entities described in section 490 2.1. Per [RFC7258], this type of actor has the ability to eavesdrop 491 pervasively on many links at once, which is a powerful form of 492 attack. Type-1 monitors are passive. They do not modify traffic or 493 insert traffic. 495 5.2. Risk Type-2 - Active Monitor 497 This risk corresponds to an actor with the same types of capabilities 498 of monitoring links. Additionally, this model can select links in 499 order to target specific individuals. A Type-2 monitor for instance 500 might put into place intermediaries in order to obtain traffic on 501 specific links. 503 Note that we exclude malicious monitoring from this document since, 504 by definition, a malicious actor has an intent associated with his 505 actions. 507 5.3. Risks in the System Setup 509 To evaluate the privacy provided by a given mechanism or mechanisms 510 in a particular system model, we characterize the risk using a 511 template where parameters from the system model in which the risk 512 actor (eavesdropper or observer as monitors) is located are used. 513 The general template is: Risk(Type, [Entities], [Links]). For 514 example, the template Risk(Type-2, R, S-R) passed as a parameter in 515 the evaluation of a privacy mechanism indicates a Type-2 monitor that 516 controls a recursive resolver and has the capability of eavesdropping 517 on the link between the stub and recursive resolvers (S-R). Other 518 risk templates include the appropriate parameterizations based on the 519 above description of those monitors, including monitors that have the 520 capabilities of monitoring multiple links and controlling multiple 521 pieces of infrastructure. 523 6. Privacy Mechanisms 525 Various mechanisms for enhancing privacy in networks are applicable 526 to DNS private exchange. Some mechanisms common to privacy research 527 include mix networks, dummy traffic, and private information 528 retrieval techniques. Applicable protocol mechanisms include 529 encryption-based techniques - encrypting the channel carrying the 530 queries using IPSEC [ipseca], TLS [dns-over-tls] or special-purpose 531 encryption [confidential-dns]. [privatedns] includes special-purpose 532 encryption but also depends on a trusted service broker. 534 o Mix Networks: in this type of mechanism, the initiator uses a mix 535 network such as Tor to route the DNS queries to the intended DNS 536 server entity. A monitor observing part of the system finds it 537 difficult to determine which individual sends which queries, and 538 will not be able to tell which individual has sent them (ideally, 539 though it is known that attacks exist that allow correlation and 540 privacy breaches against mix networks). The privacy property is 541 unlinkability of the queries; the probability that two queries 542 coming from one exit node in the mix network belong to the same 543 individual is uniform among all the individuals using the network. 545 o Dummy Traffic: a simple mechanism in which the initiator of a DNS 546 request will also generate k dummy queries and send the intended 547 query along with those queries. As such, the adversary will not 548 be able to tell which query is of interest to the initiator. For 549 a given k, the probability that the adversary will be able to 550 detect which query is of interest to the initiator is equal to 551 1-1/(k+1). In that sense, and for the proper parameterization of 552 the protocol, the monitor is bounded to the undetectability of the 553 queries. 555 o Private Information Retrieval: a mechanism that allows a user s to 556 retrieve a record r from a database DB on a server without 557 allowing the server to learn the recordr. A trivial solution to 558 the problem requires that s downloads the entire database DB and 559 then perform the queries locally. While this provides privacy to 560 the queries of the user, the solution is communication inefficient 561 at the scale of the DNS. More sophisticated cryptographic 562 solutions are multi-round, and thus reduce the communication 563 overhead, but are still inefficient for the DNS. 565 o Query Minimization: a mechanism that allows the resolver to 566 minimize the amount of information it sends on behalf of a stub 567 resolver. A method of query minimization is specified in 568 [qname-minimisation]. Qname minimization deprives a Type-1 risk 569 on R-A of information from correlating queries, unless the 570 individuals have an Unfortunate Few problem. 572 o NOTE: queries on R-A generally do not include an identifier of the 573 individual making the query, because the source address is that of 574 R. With respect R or A themselves, they may have well established 575 policies for respecting the sensitivity of queries they process, 576 while still using summary analysis of those queries to improve 577 security, stability of their business operation. 579 o Encrypted Channel Mechanisms: Using these mechanisms, an initiator 580 has an encrypted channel with a corresponding enabler, so that the 581 queries are not available to eavesdropping Pervasive Monitor risk. 582 Examples include [dns-over-tls], [ipseca], and [confidential-dns]. 583 Depending on the characteristics of the channel, various privacy 584 properties are ensured. For instance, undetectability of queries 585 is ensured for encryption-based mechanisms once the encrypted 586 channel is established. Unlinkability of the queries may depend 587 on the type of crypto-suite; it is provided as long as randomized 588 encryption is used. 590 o Composed (Multiple) Mechanisms: the use of multiple mechanisms is 591 a likely scenario and results in varied privacy guarantees. 592 Consider a hypothetical system in which mix networks (for 593 unlinkability) and randomized encryption (for undetectability) can 594 both be applied, thus providing for unobservability, a stronger 595 property than either of the two along. On the other hand, 596 consider another hypothetical system in which mix networks are 597 used to reach a third party broker requiring sign-in and 598 authorization. Depending on the risk type, this could mean that 599 the mix network unlinkability was cancelled out by the linkability 600 due to entrusting the third party with identifying information in 601 order to be authorized. 603 7. Privacy Evaluation 605 Now we turn our attention to the evaluation of privacy mechanisms in 606 a standard form, given the risk models and system definitions, for 607 some of the example mechanisms. 609 An evaluation takes multiple parameters as input. The output of the 610 evaluation template is based on the analysis of the individual 611 algorithms, settings, and parameters passed to this evaluation 612 mechanism. 614 Here is the top level interface of the evaluation template: 616 Eval(Privacy_Mechanism(params), 617 System_Setting(params), 618 Risk_Model(params) 619 ) 621 The output of the function is a privacy guarantee for the given 622 settings, expressed through defined properties such as unlinkability 623 and unobservability, for the specified system and risk model. 625 7.1 Dummy Traffic Example 627 Eval(Dummy_Traffic (k=10, distribution=uniform), 628 System_Setting([S, P, R, A], [S-P, P-R, R-A]), 629 Risk_Model(Type-1A, S-R)) 631 The dummy traffic mechanism is not presented as a practical 632 mechanism, though there's no way to know if there are deployments of 633 this type of mechanism. This example evaluation uses k=10 to 634 indicate that for every one query initiated by an individual, ten 635 queries that disguise the query of interest are selected randomly 636 from a pool of queries. In the parameters passed in the evaluation 637 function, we indicate that the privacy assurances of interest concern 638 the S-R link, with a Passive Pervasive Monitor (Type-1A) risk. 640 Here is a template format for the example: 642 Eval(Dummy_Traffic (k=10, distribution=uniform), 643 System_Setting([S, P, R, A], [S-P, P-R, R-A]), 644 Risk_Model(Type-1A, S-R)) { 645 Privacy_Mechanism{ 646 Mechanism_name = Dummy_Traffic 647 Parameters{ 648 Queries = 10 649 Query_distribution = uniform 650 } 651 System_settings{ 652 Entities = S, P, R and A; 653 Links = S-P, P-R, R-A 654 } 655 Risk_Model{ 656 Type = Type-1A 657 Links = S-R 658 } 659 Privacy_guarantee = undetectability 660 Privacy_measure = 1-(1/(queries+1)). 662 Return Privacy_guarantee, Privacy_measure 664 } 666 Undetectability is provided with 0.91 probability (though we know 667 there are other weaknesses for dummy traffic) If the threat model is 668 replaced with Type-2, so that responses to arbitrary requests can be 669 injected, and tracked, the undetectability probability is decreased. 671 7.2 Mix Network Example 673 Here is an input for a mix network privacy mechanism: 675 Eval(Mix (u=10, distribution=uniform), System_Setting(link=S-R), 676 threat_Model(Type-1A)) 678 This indicates that the monitor resides between the stub and 679 resolver. While queries are not undetectable, two queries are not 680 linkable to the same individual; the provided guarantee is 681 unlinkability. For a given number of individuals in the mix network, 682 indicated by the parameter u, assuming that at any time, traffic from 683 these individuals is uniformly random, the probability that one query 684 is comes from a given individual is (1/10 = 0.1). The probability 685 that two queries are issued by the same initiator is 0.1^2 = 0.01, 686 which represents the linkability probability. The unlinkability 687 probability is given as 1-0.01 = 0.99. Thus, 689 (unlinkability, 0.99) < Eval(Mix (u=10, distribution=uniform), 690 System_Setting(link=S-R), Risk_Model(type-1)). 692 We note that even if there is a Type-2 Risk in recursive resolver R, 693 the same results hold. 695 To sum up, the above example is represented in the following 696 template: 698 Eval(Mix (u=10, distribution=uniform), 699 System_Setting([S, P, R, A], [S-P, P-R, R-A]), 700 Risk_Model(Type-1A, S-R)) { 701 Privacy_Mechanism{ 702 Mechanism_name = mix //mix network 703 Parameters{ 704 Users = 10 705 Query_distribution = uniform 706 } 707 System_settings{ 708 Entities = S, P, R and A; 709 Links = S-P, P-R, R-A 710 } 711 Risk_Model{ 712 Type = Type-1A 713 Links = P-R 714 } 716 Privacy_guarantee = unlinkability 717 Privacy_measure = 1-(1/users)^2. 719 Return privacy_guarantee, privacy_measure 720 } 722 7.3 Encrypted Channel (DNS-over-TLS) Example 724 For one of the encryption-based mechanisms, DNS-over-TLS 725 [dns-over-tls], we have the following template (TLS parameters are 726 from [RFC5246]): 728 Eval(TLS_enc (SHA256, ECDSA, port 53, uniform), 729 System_Setting([S, P, R, A], [S-P, P-R, RA]), 730 Risk_Model(Type-1B, S-R)) { 731 Privacy_Mechanism{ 732 Mechanism_name = TLS-upgrade-based 733 Parameters{ 734 Query_distribution = uniform 735 Hash_algorithm = SHA256 736 Sig_Algorithm = ECDSA 737 Port 53 738 } 739 System_settings{ 740 Entities = S, P, R and A; 741 Links = S-P, P-R, R-A 742 } 743 Risk_Model{ 744 Type = Type-1B 745 Links = S-R 746 } 747 Privacy_guarantee = unlinkability, undetectability 748 Privacy_measure (unlinkability) = 1 749 Privacy_measure (undetectability) = 0 // port 53 indicates DNS used 751 Return privacy_guarantee, privacy_measure 752 } 754 This template features an Active Monitor risk model (Type-2) in order 755 to show how that the monitor might apply extra resources to an 756 encrypted channel. Undetectability is an issue whether using 757 upgrade-based TLS on port 53, or a port-based TLS on a dedicated port 758 - both ports indicate the use of DNS. The source address of the 759 individual is exposed in all cases. If this were a suitably 760 parameterized use of [ipseca], the monitor would not be certain that 761 all the traffic from S-R was DNS, and undetectability would be 762 higher. 764 7.4 Encrypted Channel (IPSec) Example 766 In the following, we use the same template above to characterize the 767 encryption capabilities provided by IPSec, as a potential mechanisms 768 for enabling privacy in DNS exchanges. 770 Eval(IPSEc_enc([...]), 771 System_Setting([S, P, R, A], [S-P, P-R, RA]), 772 Risk_Model(Type-1B, S-R)) { 773 Privacy_Mechanism{ 774 Mechanism_name = IPSec 775 Parameters{ 776 Query_distribution = uniform 777 } 778 System_settings{ 779 Entities = S, P, R and A; 780 Links = S-P, P-R, R-A 781 } 782 Risk_Model{ 783 Type = 2 784 Links = S-R 785 } 786 Privacy_guarantee = unlinkability, undetectability 787 Privacy_measure (unlinkability) = 1 788 Privacy_measure (undetectability) = 1 790 Return privacy_guarantee, privacy_measure 791 } 793 We note that IPSec can provide better guarantees with respect to 794 studied privacy notions. However, whether the technique itself is 795 widely deployable or not is worth further investigation. 797 7.5 QName Minimization Example (R-A) Example 799 Analyzing the privacy assurances of QName minimization is a non- 800 trivial problem, given that the notions introduced in this document 801 are techniques that do not alter items of interest. This is, the 802 notions of privacy as outlined above are concerned with a certain IOI 803 that is modified by this technique. To this end, we modify the 804 aforementioned notions in ordered to be able to analyze the 805 technique. For example, we define linkability as the ability of an 806 adversary to link two labels of (minimized) queries to each other, 807 and relate them to original source of query. Assuming a reasonable 808 use of a recursive resolver that minimizes queries on behalf of 809 users, this task is non-trivial, although quantifying the probability 810 would depend on the number of labels in queries, the number of 811 queries issued, and the number of users using the studied recursive 812 resolvers. The following template captures QName minimization as a 813 template 814 Eval(Qname_minimisation ([...], 815 System_Settings([S, P, R, A], [R-A]), 816 Risk_Model(Type=2){ 817 Privacy_Mechanism{ 818 Mechanism_name = Qname_minimisation 819 Parameters{ 820 Qtype_used = NS 821 } 822 System_settings{ 823 Entities = S, P, R and A; 824 Links = R-A 825 } 826 Risk_model{ 827 Type = 2 828 Links = R-A 829 } 830 Privacy_guarantee = unlinkability 831 Privacy_measure = analytical 833 Return privacy_guarantee, privacy_measure 834 } 836 Note that QName minimization does not solve the problem of the 837 privacy for a monitoring risk between the stub and recursive. 838 Encrypting the channel between the recursive and the stub, utilizing 839 other techniques such as TDNS or IPSec, can marginalize such risk. 840 Furthermore, note that the risk on the link between the recursive and 841 authority name servers is always mitigated by the fact that recursive 842 name servers act as a mixer of queries, even when they are sent in 843 full to the authority name servers. 845 7.7 Private-DNS (S-R) Example 847 The template for [privatedns] takes note of deployments in which in 848 addition to S, R and A, there is another entity in the system, the 849 function that authenticates the individual using S prior to 850 permitting an encrypted channel to be formed to R or A. If the 851 Private-DNS connection is with R, then identifiability of S as an 852 individual may be similar to the identifiability of S from source 853 address, or it may be stronger, depending on the nature of the 854 account information required. If the Private-DNS connection is with 855 A, source address PII is provided to A, and linkability of the 856 queries from S has probability 1. 858 8. Other evaluation 860 This document does not address a lot of the evaluation aspects not 861 associated with privacy. For example, some of the mechanisms 862 discussed in the working group are built of well-understood and 863 standardized technologies, whereas others use other non-standard and 864 less widely deployed techniques. A comprehensive evaluation of such 865 mechanisms should take into account such facts. 867 9. Security Considerations 869 The purpose of this document is to provide methods for those 870 deploying or using DNS private exchange to assess the effectiveness 871 of privacy mechanisms in depriving monitors of access to private 872 information. Protecting privacy is one of the dimensions of an 873 overall security strategy. 875 It is possible for privacy-enhancing mechanisms to be deployed in 876 ways that are vulnerable to security risks, with the result of not 877 achieving security gains. For the purposes of privacy evaluation, it 878 is important for the person making an evaluation to also ensure close 879 attention to the content of the Security Considerations section of 880 each mechanism being evaluated, for instance, to ensure if TLS is 881 used for encryption of a link against surveillance, that TLS best 882 security practices [RFC7525] are in use. 884 10. IANA Considerations 886 No requests are made to IANA. 888 11. Acknowledgements 890 We wish to thank Scott Hollenbeck, Burt Kaliski, Minsuk Kang, Paul 891 Livesay and Eric Osterweil for reviewing early versions. We wish to 892 thank Stephane Bortzmeyer and Tim Wicinski for their detailed review 893 and feedback on the previous versions of this document. We also wish 894 to thank those who commented on presentations of this work ahead of 895 publication, including Simson Garfinkel, Cathy Meadows, Paul 896 Syverson, and Christine Task. 898 12. Informative References 900 [confidential-dns] 901 Wijngaards, W. and G. Wiley, "Confidential DNS", draft- 902 wijngaards-dnsop-confidentialdns-03 (work in progress), 903 March 2015. 905 [dns-over-tls] 906 Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A., 907 and P. Hoffman, "TLS for DNS: Initiation and Performance 908 Considerations", draft-ietf-dprive-dns-over-tls-01.txt 909 (work in progress), February 2015. 911 [ipseca] Osterweil, E., Wiley, G., Okubo, T., Lavu, R., and A. 912 Mohaisen, "Opportunistic Encryption with DANE Semantics 913 and IPsec: IPSECA", draft-osterweil-dane-ipsec-03 (work in 914 progress), March 2015. 916 [openresolverproject.org] 917 Mauch, J., "The Open Resolver Project", April 2015. 919 [phb-dnse] 920 Hallam-Baker, P., "DNS Privacy and Censorship: Use Cases 921 and Requirements", draft-hallambaker-dnse-02 (work in 922 progress), November 2014. 924 [privatedns] 925 Hallam-Baker, P., "Private-DNS", draft-hallambaker- 926 privatedns-01 (work in progress), November 2014. 928 [qname-minimisation] 929 Bortzmeyer, S., "DNS query name minimisation to improve 930 privacy", draft-ietf-dnsop-qname-minimisation-07 (work in 931 progress), March 2015. 933 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 934 Text on Security Considerations", BCP 72, RFC 3552, DOI 935 10.17487/RFC3552, July 2003, 936 . 938 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 939 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 940 . 942 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 943 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 944 RFC5246, August 2008, 945 . 947 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 948 Morris, J., Hansen, M., and R. Smith, "Privacy 949 Considerations for Internet Protocols", RFC 6973, DOI 950 10.17487/RFC6973, July 2013, 951 . 953 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 954 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 955 2014, . 957 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 958 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 959 December 2014, . 961 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 962 "Recommendations for Secure Use of Transport Layer 963 Security (TLS) and Datagram Transport Layer Security 964 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 965 2015, . 967 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 968 DOI 10.17487/RFC7626, August 2015, 969 . 971 Authors' Addresses 973 Aziz Mohaisen 974 SUNY Buffalo 975 323 Davis Hall 976 Buffalo, NY 14260 977 US 979 Phone: +1 716 645-1592 980 Email: mohaisen@buffalo.edu 982 Allison Mankin 983 Verisign Labs 984 12061 Bluemont Way 985 Reston, VA 20190 986 US 988 Phone: +1 703 948-3200 989 Email: amankin@verisign.com