< draft-am-dprive-eval-01.txt   draft-am-dprive-eval-02.txt >
Network Working Group A. Mohaisen Network Working Group A. Mohaisen
Internet-Draft A. Mankin Internet-Draft SUNY Buffalo
Intended status: Informational Verisign Labs Intended status: Informational A. Mankin
Expires: January 7, 2016 July 6, 2015 Expires: April 20, 2016 Verisign Labs
October 18, 2015
Evaluation of Privacy for DNS Private Exchange Evaluation of Privacy for DNS Private Exchange
draft-am-dprive-eval-01 draft-am-dprive-eval-02
Abstract Abstract
The set of DNS requests that an individual makes can provide a The set of DNS requests that an individual makes can provide a
monitor with a large amount of information about that individual. monitor with a large amount of information about that individual.
DNS Private Exchange (DPRIVE) aims to deprive this actor of this DNS Private Exchange (DPRIVE) aims to deprive this actor of this
information. This document describes methods for measuring the information. This document describes methods for measuring the
performance of DNS privacy mechanisms, particularly it provides performance of DNS privacy mechanisms, particularly it provides
methods for measuring effectiveness in the face of pervasive methods for measuring effectiveness in the face of pervasive
monitoring as defined in RFC7258. The document includes example monitoring as defined in RFC7258. The document includes example
skipping to change at page 1, line 37 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2016. This Internet-Draft will expire on April 20, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 40 skipping to change at page 2, line 41
12. Informative References . . . . . . . . . . . . . . . . . . . 20 12. Informative References . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Motivation 1. Motivation
One of the IETF's core views is that protocols should be designed to One of the IETF's core views is that protocols should be designed to
enable security and privacy while online [RFC3552]. In light of the enable security and privacy while online [RFC3552]. In light of the
recent reported pervasive monitoring efforts, another goal is to recent reported pervasive monitoring efforts, another goal is to
design protocols and mechanisms to make such monitoring expensive or design protocols and mechanisms to make such monitoring expensive or
infeasible to conduct. As detailed in the DPRIVE problem statement infeasible to conduct. As detailed in the DPRIVE problem statement
[dprive-problem], DNS resolution is an important arena for pervasive [RFC7626], DNS resolution is an important arena for pervasive
monitoring, and in some cases may be used for breaching the privacy monitoring, and in some cases may be used for breaching the privacy
of individuals. The set of DNS requests that an individual makes can of individuals. The set of DNS requests that an individual makes can
provide a large amount of information about that individual. Not provide a large amount of information about that individual. In some
only individual requesters reveal information with their sets of DNS specific use cases, the sets of DNS requests from a DNS recursive
queries. In some specific use cases, the sets of DNS requests from a resolver or other entity may also provide revealing information.
DNS recursive resolver or other entity may also provide revealing This document describes methods for measuring the performance of DNS
information. This document describes methods for measuring the privacy mechanisms; in particular, it provides methods for measuring
performance of DNS privacy mechanisms; in particular, it provides effectiveness in the face of pervasive monitoring as defined in
methods for measuring effectiveness in the face of pervasive [RFC7258]. The document includes example evaluations for common use
monitoring as defined in [RFC7258]. The document includes example cases.
evaluations for common use cases.
The privacy risks associated with DNS monitoring are not new, however The privacy threats associated with DNS monitoring are not new,
they were brought into a greater visibility by the issue described in however they were made more obvious by the issue described in
[RFC7258]. The DPRIVE working group was formed to respond and at [RFC7258]. The DPRIVE working group was formed to respond and at
this time has several DNS private exchange mechanisms in this time has several DNS private exchange mechanisms in
consideration, including [dns-over-tls], [confidential-dns], consideration, including [dns-over-tls], [confidential-dns],
[phb-dnse], and [privatedns]. There is also related work in other [phb-dnse], and [privatedns]. There is also related work in other
working groups, including DNSOP: [qname-minimisation] and working groups, including DNSOP: [qname-minimisation] and
(potentially) DANE [ipseca]. The recently published [RFC7435] also (potentially) DANE [ipseca]. The recently published RFC on
has relevance to DNS private exchange. opportunistic security [RFC7435] also has relevance to DNS private
exchange.
Each effort related to DNS privacy mechanisms asserts some privacy Each effort related to DNS privacy mechanisms asserts some privacy
assurances and operational relevance. Metrics for these privacy assurances and operational relevance. Metrics for these privacy
assurances are needed and are in reach based on existing techniques assurances are needed and are in reach based on existing techniques
from the general field of privacy engineering. Systematic evaluation from the general field of privacy engineering. Systematic evaluation
of DNS privacy mechanisms will enhance the likely operational of DNS privacy mechanisms will enhance the likely operational
effectiveness of DNS private exchange. effectiveness of DNS private exchange.
Evaluating an individual mechanism for DNS privacy could be Evaluating an individual mechanism for DNS privacy could be
accomplished on a one-off basis, presumably as Privacy Considerations accomplished on a one-off basis, presumably as Privacy Considerations
skipping to change at page 4, line 8 skipping to change at page 4, line 8
of interest. In Section 6, we review a list of DNS privacy of interest. In Section 6, we review a list of DNS privacy
mechanisms, including some which are not in scope of the DPRIVE mechanisms, including some which are not in scope of the DPRIVE
working group. Section 7 tackles how to evaluate privacy mechanisms, working group. Section 7 tackles how to evaluate privacy mechanisms,
in the form of templates and outcomes. Given a specific risk model, in the form of templates and outcomes. Given a specific risk model,
the guarantees with respect to privacy of an individual or an item of the guarantees with respect to privacy of an individual or an item of
interest are quantified. interest are quantified.
2. Privacy Evaluation Definitions 2. Privacy Evaluation Definitions
This section provides definitions to be used for privacy evaluation This section provides definitions to be used for privacy evaluation
of DNS. [RFC6973] is the verbatim source of most of the definitions. of DNS. The verbatim source of most of those definitions is from
Text is added to apply them to the DNS case. We follow the [RFC6973] [RFC6973], which are included as an aid in reasability. In some
in classifying the terms. We have added a new section of terms to definitions, text is added to apply them to the DNS case. Also, a
include several important practical or conventional terms that were new section of terms has been added to include several important
not included in [RFC6973] such as PII. For the terms from [RFC6973], practical or conventional terms that were not included in [RFC6973]
we include their definitions rather than simply referencing them as such as PII. For the terms from [RFC6973], we include their
an aid to readability. definitions rather than simply referencing them as an aid to
readability.
2.1. Entities 2.1. Entities
o Attacker: An entity that works against one or more privacy o Attacker: An entity that works against one or more privacy
protection goals. Unlike observers, attackers' behavior is protection goals. Unlike observers, attackers' behavior is
unauthorized, in a way similar to that of an eavesdropper. unauthorized, in a way similar to that of an eavesdropper.
o Eavesdropper: A type of attacker that passively observes an o Eavesdropper: A type of attacker that passively observes an
initiator's communications without the initiator's knowledge or initiator's communications without the initiator's knowledge or
authorization. This may include a passive pervasive monitor, authorization. DNS example may include a passive pervasive
defined below. monitor, defined below.
o Enabler: A protocol entity that facilitates communication between o Enabler: A protocol entity that facilitates communication between
an initiator and a recipient without being directly in the an initiator and a recipient without being directly in the
communications path. DNS examples of an enabler in this sense communications path. DNS examples of an enabler in this sense
include a recursive resolver, a proxy, or a forwarder. include a recursive resolver, a proxy, or a forwarder.
o Individual: A human being (or a group of them) o Individual: A human being (or a group of them)
o Initiator: A protocol entity that initiates communications with a o Initiator: A protocol entity that initiates communications with a
recipient. recipient.
o Intermediary: A protocol entity that sits between the initiator o Intermediary: A protocol entity that sits between the initiator
(stub resolver) and the recipient (recursive resolver or authority (DNS example of stub resolver) and the recipient (DNS example of
resolver) and is necessary for the initiator and recipient to recursive resolver or authority resolver) and is necessary for the
communicate. Unlike an eavesdropper, an intermediary is an entity initiator and recipient to communicate. Unlike an eavesdropper,
that is part of the communication architecture and therefore at an intermediary is an entity that is part of the communication
least tacitly authorized. architecture and therefore at least tacitly authorized.
o Observer: An entity that is able to observe and collect o Observer: An entity that is able to observe and collect
information from communications, potentially posing privacy risks, information from communications, potentially posing privacy risks,
depending on the context. As defined in this document, depending on the context. As defined in this document,
initiators, recipients, intermediaries, and enablers can all be initiators, recipients, intermediaries, and enablers can all be
observers. Observers are distinguished from eavesdroppers by observers. Observers are distinguished from eavesdroppers by
being at least tacitly authorized. being at least tacitly authorized.
o We note that while the definition of an observer may include an o We note that while the definition of an observer may include an
initiator in the risk model, an initiator of a request is excluded initiator in the risk model, an initiator of a request is excluded
skipping to change at page 5, line 33 skipping to change at page 5, line 36
2.3. Identifiability 2.3. Identifiability
We assume the following definitions related to identifiability from We assume the following definitions related to identifiability from
[RFC4949]: anonymity, anonymity set, anonymous, attribute, identity [RFC4949]: anonymity, anonymity set, anonymous, attribute, identity
provider, personal name, and relying party. provider, personal name, and relying party.
The following definitions are modified for the context of this The following definitions are modified for the context of this
document from those defined in [RFC4949] document from those defined in [RFC4949]
o Identifiability: The extent to which an individual is o Identifiability: The extent to which an individual is
identifiable. [RFC6973] has the rest of the variations on this identifiable. [RFC6973] includes the rest of the variations on
(Identifiable, Identification, Identified, Identifier, Identity, this (Identifiable, Identification, Identified, Identifier,
Identity Confidentiality) Identity, Identity Confidentiality)
o Personal Name: A natural name for an individual. Personal names o Personal Name: A natural name for an individual. Personal names
are often not unique and often comprise given names in combination are often not unique and often comprise given names in combination
with a family name. An individual may have multiple personal with a family name. An individual may have multiple personal
names at any time and over a lifetime, including official names. names at any time and over a lifetime, including official names.
From a technological perspective, it cannot always be determined From a technological perspective, it cannot always be determined
whether a given reference to an individual is, or is based upon, whether a given reference to an individual is, or is based upon,
the individual's personal name(s) (see Pseudonym). NOTE: The the individual's personal name(s) (see Pseudonym). NOTE: The
reason to import this definition is that some query names that reason to import this definition is that some query names that
cause privacy leakage do so by embedding personal names as cause privacy leakage do so by embedding personal names as
identifiers of host or other equipment, e.g. identifiers of host or other equipment, e.g.
AllisonMankinMac.example.com. AllisonMankinMac.example.com.
o Pseudonymity: See the formal definition in the next section in o Pseudonymity: See the formal definition in section 2.4 in lieu of
lieu of [RFC6973]. [RFC6973].
NOTE: Identifiability Definitions in [RFC6973] also include some NOTE: Identifiability Definitions in [RFC6973] also include some
material not included here because the distinctions are not major for material not included here because the distinctions are not major for
DNS Private Exchange, such as real and official names, and variant DNS Private Exchange, such as real and official names, and variant
forms of Pseudonymity in its informal definition. forms of Pseudonymity in its informal definition.
2.4. Other Central Definitions and Formalizations 2.4. Other Central Definitions and Formalizations
Central to the presentation of this document is the definition of Central to the presentation of this document is the definition of
personally identifiable information (PII), as well as other personally identifiable information (PII), as well as other
skipping to change at page 6, line 25 skipping to change at page 6, line 28
them for the context of this document. In this section, we outline them for the context of this document. In this section, we outline
such definitions we further notes on their indications. such definitions we further notes on their indications.
o Personally Identifiable Information (PII): Information o Personally Identifiable Information (PII): Information
(attributes) that can be used as is, or along with other side (attributes) that can be used as is, or along with other side
information, to identify, locate, and/or contact a single information, to identify, locate, and/or contact a single
individual or subject (c.f. item of interest). individual or subject (c.f. item of interest).
NOTE: the definition above indicates that PII can be used on its own NOTE: the definition above indicates that PII can be used on its own
or in context. In DNS privacy, the items without additional context or in context. In DNS privacy, the items without additional context
include IP(v4 or v6) address, qname, qtype, timings of queries, etc. include IP(v4 or v6) addresses, qname, qtype, timings of queries,
The additional context includes organization-level attributes, such etc. The additional context includes organization-level attributes,
as a network prefix that can be associated with an organization. The such as a network prefix that can be associated with an organization.
definition of PII is complementary to the definition of items of The definition of PII is complementary to the definition of items of
interest. interest.
o Subject: This term is useful as a parallel term to Individual. o Subject: This term is useful as a parallel term to Individual.
When the privacy of a group or an organization is of interest, we When the privacy of a group or an organization is of interest, we
can reference the group or organization as Subject rather than can reference the group or organization as Subject rather than
Individual. Individual.
Often it is desirable to reference alternative identifiers known as Often it is desirable to reference alternative identifiers known as
pseudonyms. A pseudonym is a name assumed by an individual in some pseudonyms. A pseudonym is a name assumed by an individual in some
context, unrelated to the names or identifiers known by others in context, unrelated to the names or identifiers known by others in
skipping to change at page 7, line 12 skipping to change at page 7, line 14
interested in breaching the privacy to link multiple queries on a interested in breaching the privacy to link multiple queries on a
long-term basis. Pseudonyms are assumed long-lived and their long-term basis. Pseudonyms are assumed long-lived and their
uniqueness may be a goal. There are many findings that indicate that uniqueness may be a goal. There are many findings that indicate that
pseudonymity is weaker than anonymity. pseudonymity is weaker than anonymity.
o Unlinkability: Formally, two items of interest are said to be o Unlinkability: Formally, two items of interest are said to be
unlinkable if the certainty of an actor concerning those items of unlinkable if the certainty of an actor concerning those items of
interest is not affected by observing the system. This is, interest is not affected by observing the system. This is,
unlinkability implies that the a-posteriori probability computed a unlinkability implies that the a-posteriori probability computed a
monitor that two items of interest are related is close enough to monitor that two items of interest are related is close enough to
the a-priori probability computed by a monitor based on his the a-priori probability computed by a monitor based on their
knowledge. knowledge.
Two items of interest are said to be unlinkable if there is a small Two items of interest are said to be unlinkable if there is a small
(beta, close to 0) probability that the monitor identifies them as chance (beta, close to 0 probability) that the monitor identifies
associated, and they are linkable if there is a sufficiently large them as associated, and they are linkable if there is a sufficiently
probability (referred to as alpha). large probability (referred to as alpha).
Informally, given two items of interest (user attributes, DNS Informally, given two items of interest (user attributes, DNS
queries, users, etc.), unlinkability is defined as the inability of queries, users, etc.), unlinkability is defined as the inability of
the monitor to sufficiently determine whether those items are related the monitor to sufficiently determine whether those items are related
to one another. In the context of DNS, this refers typically but not to one another. In the context of DNS, this refers typically but not
only to a monitor relating queries to the same individual. only to a monitor relating queries to the same individual.
o Undetectability: a stronger definition of privacy, where an item o Undetectability: a stronger definition of privacy, where an item
of interest is said to be undetectable if the monitor is not of interest is said to be undetectable if the monitor is not
sufficiently able to know or tell whether the item exists or not. sufficiently able to know or tell whether the item exists or not.
Note that undetectability implies unlinkability. As explained below, Note that undetectability implies unlinkability. As explained below,
a way of ensuring undetectability is to use encryption secure under a way of ensuring undetectability is to use encryption that is secure
known ciphertext attacks, or randomized encryption. under known ciphertext attacks, or randomized encryption.
o Unobservability: a stronger definition of privacy that requires o Unobservability: a stronger definition of privacy that requires
satisfying both undetectability and anonymity. Unobservability satisfying both undetectability and anonymity. Unobservability
means that an item of interest is undetectable by any uninvolved means that an item of interest is undetectable by any not involved
individual, monitor or not. individual, monitor or not.
In theory, there are many ways of ensuring unobservability by In theory, there are many ways of ensuring unobservability by
fulfilling both requirements. For example, undetectability requires fulfilling both requirements. For example, undetectability requires
that no party uninvolved in the resolution of a DNS query shall know that no party that is not invovled in the resolution of a DNS query
that query has existed or not. A mechanism to ensure this function shall know that query has existed or not. A mechanism to ensure this
is encryption secure under known ciphertext attacks, or randomized function is encryption secure under known ciphertext attacks, or
encryption for all other than stub, and pseudonyms for the stub randomized encryption for all other than stub resolvers, and
resolver. An alternative mechanism to provide the anonymity property pseudonyms for the stub resolver. An alternative mechanism to
would be the use of mix networks for routing DNS queries. provide the anonymity property would be the use of mix networks for
routing DNS queries.
3. Assumptions about Quantification of Privacy 3. Assumptions about Quantification of Privacy
The quantification of privacy is connected with the privacy goals. The quantification of privacy is connected with the privacy goals.
Is the desired privacy property unlinkability only, or is it Is the desired privacy property unlinkability only, or is it
undetectability. Is pseudonymity a sufficient property? Parameters undetectability? Is pseudonymity a sufficient property? Parameters
and entire privacy mechanism choices are affected by the choice of and entire privacy mechanism choices are affected by the choice of
privacy goals. privacy goals.
While a binary measure of privacy is sometimes possible, that is, While a binary measure of privacy is sometimes possible, that is,
being able to say that the transaction is anonymous, in this being able to say that the transaction is anonymous, in this
document, we assume that the binary is not frequently obtainable, and document, we assume that the binary is not frequently obtainable, and
therefore we focus on methods for continuous quantification. Both therefore we focus on methods for continuous quantification. Both
are relevant to DNS Private Exchange. Another way to state this is are relevant to DNS Private Exchange. Another way to state this is
that the quantification could be exactly the probabilities 1 and 0, that the quantification could be exactly the probabilities 1 and 0,
corresponding to the binary, but the methods prefer to provide corresponding to the binary, but the methods prefer to provide
continuous values instead. continuous values instead.
Here is an example of continuous quantification, related to Here is an example of continuous quantification, related to
identifiability of an individual or item of interest based on identifiability of an individual or item of interest based on
observing queries. observing queries.
o For an individual A, and a set of observations by a monitor, Y = o For an individual A, and a set of observations by a monitor Y,
[y1, y2, ... yn], we define the privacy of A as the uncertainty of where Y = [y1, y2, ... yn], we define the privacy of A as the
the monitor of knowing that A is itself among many others under uncertainty of the monitor knowing that A is itself among many
the observations Y; that is, we define Privacy = 1 - P[A | Y] others under the observations Y; that is, we define Privacy = 1 -
P[A | Y]
o For an item of interest r associated with a user A, we similarly o For an item of interest r associated with a user A, we similarly
define the privacy of r as Privacy = 1 - P[r | Y]. define the privacy of r as Privacy = 1 - P[r | Y].
4. System Model 4. System Model
A DNS client (a DNS stub resolver) may resolve a domain name or A DNS client (a DNS stub resolver) may resolve a domain name or
address into the corresponding DNS record by contacting the address into the corresponding DNS record by contacting the
authoritative name server responsible for that domain name (or authoritative name server responsible for that domain name (or
address) directly. However, to improve the operation of DNS address) directly. However, to improve the operation of DNS
resolution, and reduce the round trip time required for resolving an resolution, and reduce the round trip time required for resolving an
address, both caching and recursive resolution are implemented. address, both caching and recursive resolution are implemented.
Caching is implemented at an intermediary between the stub and the Caching is implemented at an intermediary between the stub and the
authoritative name server. In practice, many caching servers also authoritative name server. In practice, many caching servers also
implement the recursive logic of DNS resolution for finding the name implement the recursive logic of DNS resolution for finding the name
server authoritative for a domain, and are thus named DNS recursive server authoritative for a domain, and are thus called DNS recursive
resolvers. Another type of entity, forwarders (or proxies) are resolvers. Another type of entity, DNS forwarders (or proxies), acts
intermediaries between the three named here. The system model for as intermediaries between stub resolvers and recursive resolvers, and
DNS privacy evaluation includes the four entities quickly sketched recursive resolvers and authoritative resolvers. The system model
here: stub resolvers, recursive resolvers, authoritative name for DNS privacy evaluation includes the four entities quickly
servers, and forwarders. sketched here: stub resolvers, recursive resolvers, authoritative
name servers, and forwarders.
4.1. DNS Resolvers (System Model) 4.1. DNS Resolvers (System Model)
o Stub resolver (S): a minimal resolver that does not support o Stub resolver (S): a minimal resolver that does not support
referral, and delegates recursive resolution to a recursive referral, and delegates recursive resolution to a recursive
resolver. A stub resolver is a consumer of recursive resolutions. resolver. A stub resolver is a consumer of recursive resolutions.
Per the terminology of [RFC6973], a stub resolver is an Initiator. Per the terminology of [RFC6973], a stub resolver is an Initiator.
o Recursive resolver (R): a resolver that implements the recursive o Recursive resolver (R): a resolver that implements the recursive
function of DNS resolution on behalf of a stub resolver. Per the function of DNS resolution on behalf of a stub resolver. Per the
terminology of [RFC6973], a recursive resolver is an Enabler. terminology of [RFC6973], a recursive resolver is an Enabler.
o Authoritative resolver (A): is a server that is the origin of a o Authoritative resolver (A): is a server that is the origin of a
DNS record. A recursive resolver queries the authoritative DNS record. A recursive resolver queries the authoritative
resolver to resolve a domain name or address. Per the terminology resolver to resolve a domain name or address. Per the terminology
of [RFC6973], the authoritative name server is also an Enabler. of [RFC6973], the authoritative name server is also an Enabler.
o Forwarder/proxy (P): between the stub resolver and the o Forwarder/proxy (P): between the stub resolver and the
authoritative resolver there may be more than one DNS-involved authoritative resolver there may be one or more DNS-involved
entity. These are systems located between S and R (stub resolver entity. These are systems located between S and R (stub resolver
and recursive), or between R and A (recursive and authoritative), and recursive), or between R and A (recursive and authoritative),
which do not play a primary role in the DNS protocol. Per the which do not play a primary role in the DNS protocol. Per the
terminology of [RFC6973], forwarders are Intermediaries. terminology of [RFC6973], forwarders are Intermediaries.
4.2. System Setup - Putting It Together 4.2. System Setup - Putting It Together
Evaluating various privacy protection mechanisms in relation to Evaluating various privacy protection mechanisms in relation to
monitors such as the pervasive monitors defined next requires monitors such as the pervasive monitors defined next requires
understanding links in the System setup. We define the following understanding links in the system setup. We define the following
links. In relation to [RFC7258] these are the attack surface where a links. In relation to [RFC7258] these are the attack surface where a
monitor (eavesdropper) collects sets of query information. monitor (eavesdropper) can collect sets of query information.
o Stub -> Recursive (S-R): a link between the stub resolver and a o Stub -> Recursive (S-R): a link between the stub resolver and a
recursive resolver. At the time of writing, the scope of DPRIVE recursive resolver. At the time of writing, the scope of DPRIVE
Working Group privacy mechanisms is supposed to be limited to S-R. Working Group privacy mechanisms is supposed to be limited to S-R.
o Stub -> Proxy (S-P): a link between the stub resolver and a o Stub -> Proxy (S-P): a link between the stub resolver and a
forwarder/ proxy. The intended function of this link may be forwarder/ proxy. The intended function of this link may be
difficult to analyze. difficult to analyze.
o Proxy -> Recursive (P-R): a link between a proxy and a recursive o Proxy -> Recursive (P-R): a link between a proxy and a recursive
server. server.
o Recursive -> Authoritative (R-A): a link between a recursive and o Recursive -> Authoritative (R-A): a link between a recursive and
an authoritative name server. Although at the time of writing, an authoritative name server. Although at the time of writing,
R-A is not in the DPRIVE scope, we touch on it in evaluations. R-A is not in the DPRIVE scope, we discuss it in the evaluation.
Rather than notating in system setup that an entity is compromised, Rather than notating in system setup that an entity is compromised,
this is covered in the monitor model in Section 6, which has system this is covered in the monitor model in Section 6, which has system
elements as parameters. elements as parameters.
In the System Setup, there is a possibility that S and R exist on a In the system setup, there is a possibility that S and R exist on a
single machine. The concept of the Unlucky Few relates S and R in single machine. The concept of the Unlucky Few relates S and R in
this case. A monitor can monitor R-A and find the query traffic of this case. A monitor can monitor R-A and find the query traffic of
the initiator individual. The same concept applies in the case where the initiator individual. The same concept applies in the case where
a recursive is serving a relatively small number of individuals. The a recursive is serving a relatively small number of individuals. The
query traffic of a subject group or organization (c.f. Subject in query traffic of a subject group or organization (c.f. Subject in
the definitions) is obtained by the monitor who monitors this the definitions) is obtained by the monitor who monitors this
system's R-A. system's R-A.
Because R-A is not in the DPRIVE scope, it is for future work to Because R-A is not in the DPRIVE scope, it is for future work to
examine the Unlucky Few circumstance fully. The general system setup examine the Unlucky Few circumstance fully. The general system setup
is that PII, the individual's private identifying information, is not is that PII, the individual's private identifying information, is not
sent on R-A and is not seen by authoritative name server. sent on R-A and is not seen by authoritative name server.
There could be one or more proxies between the stub resolver and a There could be one or more proxies between the stub resolver and a
recursive. From a functionality point of view they can all be recursive. From a functionality point of view they can all be
consolidated into a single proxy without affecting the system view, consolidated into a single proxy without affecting the system view.
however, the behavior of such proxies may affect the size and shape However, the behavior of such proxies may affect the size and shape
of the attack surface. However, we believe that an additional of the attack surface. However, we believe that an additional
treatment is needed for this case and it is not included in the treatment is needed for this case and it is not included in the
discussion. discussion.
We also do not include in discussion proxies that exist along R-A, We also do not include in discussion proxies that exist along R-A,
between a recursive and an authoritative name server. We do so in between a recursive and an authoritative name server. We do so in
respect for the DPRIVE charter's scope at this time. According to respect for the DPRIVE charter's scope at this time. According to
recent work at [openresolverproject.org], there may be multiple recent work at [openresolverproject.org], there may be multiple
intermediaries with poorly defined behavior. intermediaries with poorly defined behavior.
The system setup here leaves out other realistic considerations for The system setup here leaves out other realistic considerations for
simplicity, such as the impact of shared caches in DNS entities. simplicity, such as the impact of shared caches in DNS entities.
5. Risk Model 5. Risk Model
The Definitions section defines observer, attack and monitor, but not The Definitions section defines observer, attack and monitor, but not
a Risk Model, which is needed to actually evaluate privacy, so this a Risk Model, which is needed to actually evaluate privacy.
is now defined.
For consistency, we note that the only difference between an attacker For consistency, we note that the only difference between an attacker
and an obeserver is that an attacker is an unauthorized observer with and an obeserver is that an attacker is an unauthorized observer with
all the capabilities it may has. However, we also stress that for all the capabilities it may have. We also stress that for the
the context of DNS privacy, the term attacker may implicitly assume context of DNS privacy, the term attacker may implicitly assume an
an intent. To that end, active and passive observers are intent. To that end, active and passive observers are collectively
collectively referred to as actors. referred to as actors.
o Risk Model: a well-defined set of capabilities indicating how much o Risk Model: a well-defined set of capabilities indicating how much
information an observer (or eavesdropper) has, and in what information an observer (or eavesdropper) has, and in what
context, in order to reach a goal of breaching the privacy of an context, in order to reach a goal of breaching the privacy of an
individual or subject with respect to a given privacy metric. individual or subject with respect to a given privacy metric.
In this document we focus on two risk models, namely a pervasive In this document we focus on two risk models, namely a pervasive
monitor and a malicious monitor. monitor and a malicious monitor.
5.1. Risk Type-1 - Passive Pervasive Monitor 5.1. Risk Type-1 - Passive Pervasive Monitor
This risk corresponds to the passive pervasive monitoring model This risk corresponds to the passive pervasive monitoring model
described in [RFC7258]. This model relies on monitoring capabilities described in [RFC7258]. This model relies on monitoring capabilities
to breach the privacy of individuals from the DNS traffic at scale to breach the privacy of individuals from the DNS traffic at scale
without decimation. An actor causing this risk is capable of without decimation. An actor causing this risk is capable of
eavesdropping or observing traffic between two end points, including eavesdropping or observing traffic between two end points, including
traffic between any of the pairs of the entities described in section traffic between any of the pairs of entities described in section
2.1. Per [RFC7258], this type of actor has abilities to eavesdrop 2.1. Per [RFC7258], this type of actor has the ability to eavesdrop
pervasively on many links at once, which is a powerful form of pervasively on many links at once, which is a powerful form of
attack. Type-1 monitor are passive. They do not modify traffic or attack. Type-1 monitors are passive. They do not modify traffic or
insert traffic. insert traffic.
5.2. Risk Type-2 - Active Monitor 5.2. Risk Type-2 - Active Monitor
an actor with the same types of capabilities of monitoring links, This risk corresponds to an actor with the same types of capabilities
which selects links in order to target specific individuals. A of monitoring links. Additionally, this model can select links in
Type-2 monitor for instance might put into place intermediaries in order to target specific individuals. A Type-2 monitor for instance
order to obtain traffic on specific links. might put into place intermediaries in order to obtain traffic on
specific links.
Note that we exclude the malicious monitoring from this document Note that we exclude malicious monitoring from this document since,
since, by definition, a malicious actor has an intent associated with by definition, a malicious actor has an intent associated with his
his actions. actions.
5.3. Risks in the System Setup 5.3. Risks in the System Setup
To evaluate the privacy provided by a given mechanism or mechanisms To evaluate the privacy provided by a given mechanism or mechanisms
in a particular system model, we characterize the risk with a in a particular system model, we characterize the risk using a
template with parameters from the system model in which the risk template where parameters from the system model in which the risk
actor (eavesdropper or observer as monitors) is located. The general actor (eavesdropper or observer as monitors) is located are used.
template is: Risk(Type, [Entities], [Links]). For example, the The general template is: Risk(Type, [Entities], [Links]). For
template Risk(Type-2, R, S-R) passed as a parameter in the evaluation example, the template Risk(Type-2, R, S-R) passed as a parameter in
of a privacy mechanism indicates a Type-2 monitor that controls a the evaluation of a privacy mechanism indicates a Type-2 monitor that
recursive and has the capability of eavesdropping on the link between controls a recursive resolver and has the capability of eavesdropping
the stub and recursive resolvers. Other risk templates include the on the link between the stub and recursive resolvers (S-R). Other
appropriate parameterizations based on the above description of those risk templates include the appropriate parameterizations based on the
monitors, including monitors that have the capabilities of monitoring above description of those monitors, including monitors that have the
multiple links and controlling multiple pieces of infrastructure. capabilities of monitoring multiple links and controlling multiple
pieces of infrastructure.
6. Privacy Mechanisms 6. Privacy Mechanisms
Various mechanisms for enhancing privacy in networks are applicable Various mechanisms for enhancing privacy in networks are applicable
to DNS private exchange. Some mechanisms common to privacy research to DNS private exchange. Some mechanisms common to privacy research
include mixing networks, dummy traffic, and private information include mix networks, dummy traffic, and private information
retrieval techniques. Applicable protocol mechanisms include retrieval techniques. Applicable protocol mechanisms include
encryption-based techniques - encrypting the channel carrying the encryption-based techniques - encrypting the channel carrying the
queries using IPSEC [ipseca], TLS [dns-over-tls] or special-purpose queries using IPSEC [ipseca], TLS [dns-over-tls] or special-purpose
encryption [confidential-dns]. [privatedns] includes special-purpose encryption [confidential-dns]. [privatedns] includes special-purpose
encryption and also depends on a trusted service broker. encryption but also depends on a trusted service broker.
o Mixing Networks: in this type of mechanism, the initiator uses a o Mix Networks: in this type of mechanism, the initiator uses a mix
mixing network such as Tor to route the DNS queries to the network such as Tor to route the DNS queries to the intended DNS
intended DNS server entity. A monitor observing part of the server entity. A monitor observing part of the system finds it
system finds it difficult to determine which individual sends difficult to determine which individual sends which queries, and
which queries, and will not be able to tell which individual has will not be able to tell which individual has sent them (ideally,
sent them (ideally, though it is known that attacks exist that though it is known that attacks exist that allow correlation and
allow correlation and privacy breaches against mixing networks). privacy breaches against mix networks). The privacy property is
The privacy property is unlinkability of the queries; the unlinkability of the queries; the probability that two queries
probability that two queries coming from one exit node in the coming from one exit node in the mix network belong to the same
mixing network belong to the same individual is uniform among all individual is uniform among all the individuals using the network.
the individuals using the network.
o Dummy Traffic: a simple mechanism in which the initiator of a DNS o Dummy Traffic: a simple mechanism in which the initiator of a DNS
request will also generate k dummy queries and send the intended request will also generate k dummy queries and send the intended
query along with those queries. As such, the adversary will not query along with those queries. As such, the adversary will not
be able to tell which query is of interest to the initiator. For be able to tell which query is of interest to the initiator. For
a given k, the probability that the adversary will be able to a given k, the probability that the adversary will be able to
detect which query is interest to the initiator is equal to detect which query is of interest to the initiator is equal to
1-1/(k+1). In that sense, and for the proper parameterization of 1-1/(k+1). In that sense, and for the proper parameterization of
the protocol, the monitor is bounded to the undetectability of the the protocol, the monitor is bounded to the undetectability of the
queries. queries.
o Private Information Retrieval: a mechanism that allows a user s to o Private Information Retrieval: a mechanism that allows a user s to
retrieve a record r from a database DB on a server without retrieve a record r from a database DB on a server without
allowing the server to learn r. A trivial solution to the problem allowing the server to learn the recordr. A trivial solution to
requires that s downloads the entire DB and then perform the the problem requires that s downloads the entire database DB and
queries locally. While that provides privacy to the queries of then perform the queries locally. While this provides privacy to
the user, the solution is communication inefficient at the scale the queries of the user, the solution is communication inefficient
of the DNS. More sophisticated cryptographic solutions are multi- at the scale of the DNS. More sophisticated cryptographic
round, and thus reduce the communication overhead, but are still solutions are multi-round, and thus reduce the communication
inefficient for the DNS. overhead, but are still inefficient for the DNS.
o Query Minimization: a mechanism that allows the resolver to o Query Minimization: a mechanism that allows the resolver to
minimize the amount of information it sends on behalf of a stub minimize the amount of information it sends on behalf of a stub
resolver. A method of query minimization is specified in resolver. A method of query minimization is specified in
[qname-minimisation]. Qname minimization deprives a Type-1 risk [qname-minimisation]. Qname minimization deprives a Type-1 risk
on R-A of information from correlating queries, unless the on R-A of information from correlating queries, unless the
individuals have an Unfortunate Few problem. individuals have an Unfortunate Few problem.
o NOTE: queries on R-A generally do not include an identifier of the o NOTE: queries on R-A generally do not include an identifier of the
individual making the query, because the source address is that of individual making the query, because the source address is that of
R. With respect R or A themselves, they may have well established R. With respect R or A themselves, they may have well established
policies for respecting the sensitivity of queries they process, policies for respecting the sensitivity of queries they process,
while still using summary analysis of those queries to improve while still using summary analysis of those queries to improve
security, stability or their business operation. security, stability of their business operation.
o Encrypted Channel Mechanisms: Using these mechanisms, an initiator o Encrypted Channel Mechanisms: Using these mechanisms, an initiator
has an encrypted channel with a corresponding enabler, so that the has an encrypted channel with a corresponding enabler, so that the
queries are not available to eavesdropping Pervasive Monitor risk. queries are not available to eavesdropping Pervasive Monitor risk.
Examples include [dns-over-tls], [ipseca], and [confidential-dns]. Examples include [dns-over-tls], [ipseca], and [confidential-dns].
Depending on the characteristics of the channel, various privacy Depending on the characteristics of the channel, various privacy
properties are ensured. For instance, undetectability of queries properties are ensured. For instance, undetectability of queries
is ensured for encryption-based mechanisms once the encrypted is ensured for encryption-based mechanisms once the encrypted
channel is established. Unlinkability of the queries may depend channel is established. Unlinkability of the queries may depend
on the type of crypto-suite; it is provided as long as randomized on the type of crypto-suite; it is provided as long as randomized
encryption is used. encryption is used.
o Composed (Multiple) Mechanisms: the use of multiple mechanisms is o Composed (Multiple) Mechanisms: the use of multiple mechanisms is
a likely scenario and results in varied privacy guarantees. a likely scenario and results in varied privacy guarantees.
Consider a hypothetical system in which mixing networks (for Consider a hypothetical system in which mix networks (for
unlinkability) and randomized encryption (for undetectability) can unlinkability) and randomized encryption (for undetectability) can
both be applied, thus providing for unobservability, a stronger both be applied, thus providing for unobservability, a stronger
property than either of the two along. On the other hand, property than either of the two along. On the other hand,
consider another hypothetical system in which mixing networks are consider another hypothetical system in which mix networks are
used to reach a third party broker requiring sign-in and used to reach a third party broker requiring sign-in and
authorization. Depending on the risk type, this could mean that authorization. Depending on the risk type, this could mean that
the mixing network unlinkability was cancelled out by the the mix network unlinkability was cancelled out by the linkability
linkability due to entrusting the third party with identifying due to entrusting the third party with identifying information in
information in order to be authorized. order to be authorized.
7. Privacy Evaluation 7. Privacy Evaluation
Now we turn our attention to the evaluation of privacy mechanisms in Now we turn our attention to the evaluation of privacy mechanisms in
a standard form, given the risk models and system definitions, for a standard form, given the risk models and system definitions, for
some of the example mechanisms. some of the example mechanisms.
An evaluation takes multiple parameters as input. The output of the An evaluation takes multiple parameters as input. The output of the
evaluation template is based on the analysis of the individual evaluation template is based on the analysis of the individual
algorithms, settings, and parameters passed to this evaluation algorithms, settings, and parameters passed to this evaluation
mechanism. mechanism.
Here is the top level interface of the evaluation template: Here is the top level interface of the evaluation template:
Eval(Privacy_Mechanism(param_1, param_2, ...), Eval(Privacy_Mechanism(params),
System_Setting(param_1, param_2, ...), Risk_Model(param_1, System_Setting(params),
param_2,...) Risk_Model(params)
)
The output of the function is a privacy guarantee for the given The output of the function is a privacy guarantee for the given
settings, expressed through defined properties such as unlinkability settings, expressed through defined properties such as unlinkability
and unobservability, for the specified system and risk model. and unobservability, for the specified system and risk model.
7.1 Dummy Traffic Example 7.1 Dummy Traffic Example
Eval(Dummy_Traffic (k=10, distribution=uniform), System_Setting([S, Eval(Dummy_Traffic (k=10, distribution=uniform),
P, R, A], [S-P, P-R, R-A]), Risk_Model(Type-1A, S-R)). System_Setting([S, P, R, A], [S-P, P-R, R-A]),
Risk_Model(Type-1A, S-R))
The dummy traffic mechanism is not presented as a practical The dummy traffic mechanism is not presented as a practical
mechanism, though there's no way to know if there are deployments of mechanism, though there's no way to know if there are deployments of
this type of mechanism. This example evaluation uses k=10 to this type of mechanism. This example evaluation uses k=10 to
indicate that for every one query initiated by an individual, ten indicate that for every one query initiated by an individual, ten
queries that disguise the query of interest are selected uniformly at queries that disguise the query of interest are selected randomly
random from a pool of queries. In the parameters passed in the from a pool of queries. In the parameters passed in the evaluation
evaluation function, we indicate that the privacy assurances of function, we indicate that the privacy assurances of interest concern
interest concern the S-R link, with a Passive Pervasive Monitor the S-R link, with a Passive Pervasive Monitor (Type-1A) risk.
(Type-1A) risk.
Here is a template format for the example: Here is a template format for the example:
Eval(Dummy_Traffic (k=10, distribution=uniform), Eval(Dummy_Traffic (k=10, distribution=uniform),
System_Setting([S, P, R, A], System_Setting([S, P, R, A], [S-P, P-R, R-A]),
[S-P, P-R, R-A]), Risk_Model(Type-1A, S-R)) {
Risk_Model(Type-1A, S-R)). { Privacy_Mechanism{
Privacy_Mechanism{ Mechanism_name = Dummy_Traffic
Mechanism_name = Dummy_Traffic Parameters{
Parameters{ Queries = 10
Queries = 10 Query_distribution = uniform
Query_distribution = uniform }
} System_settings{
System_settings{ Entities = S, P, R and A;
Entities = S, P, R and A; Links = S-P, P-R, R-A
Links = S-P, P-R, R-A }
} Risk_Model{
Risk_Model{ Type = Type-1A
Type = Type-1A Links = S-R
Compromised_Entities = NA }
Links = S-R Privacy_guarantee = undetectability
} Privacy_measure = 1-(1/(queries+1)).
Privacy_guarantee = undetectability
Privacy_measure = 1-(1/(queries+1)).
Return Privacy_guarantee, Privacy_measure Return Privacy_guarantee, Privacy_measure
} }
Undetectability is provided with 0.91 probability (though we know Undetectability is provided with 0.91 probability (though we know
there are other weaknesses for dummy traffic) If the threat model is there are other weaknesses for dummy traffic) If the threat model is
replaced with Type-2, so that responses to arbitrary requests can be replaced with Type-2, so that responses to arbitrary requests can be
injected, and tracked, the undetectability probability is decreased. injected, and tracked, the undetectability probability is decreased.
7.2 Mixing Network Example 7.2 Mix Network Example
Here is an input for a mixing network privacy mechanism: Here is an input for a mix network privacy mechanism:
Eval(mix (u=10, distribution=uniform), System_Setting(link=S-R), Eval(Mix (u=10, distribution=uniform), System_Setting(link=S-R),
threat_Model(Type-1A)). threat_Model(Type-1A))
This indicates that the monitor resides between the stub and This indicates that the monitor resides between the stub and
resolver. While queries are not undetectable, two queries are not resolver. While queries are not undetectable, two queries are not
linkable to the same individual; the provided guarantee is linkable to the same individual; the provided guarantee is
unlinkability. For a given number of individuals in the mixing unlinkability. For a given number of individuals in the mix network,
network, indicated by the parameter u, assuming that at any time, indicated by the parameter u, assuming that at any time, traffic from
traffic from these individuals is uniformly random, the probability these individuals is uniformly random, the probability that one query
that one query is comes from a given individual is (1/10=0.1). The is comes from a given individual is (1/10 = 0.1). The probability
probability that two queries are issued by the same initiator is that two queries are issued by the same initiator is 0.1^2 = 0.01,
0.1^2 = 0.01, which represents the linkability probability. The which represents the linkability probability. The unlinkability
unlinkability probability is given as 1-0.01 = 0.99. Thus, probability is given as 1-0.01 = 0.99. Thus,
(unlinkability, 0.99) < Eval(mix (u=10, distribution=uniform),
(unlinkability, 0.99) < Eval(Mix (u=10, distribution=uniform),
System_Setting(link=S-R), Risk_Model(type-1)). System_Setting(link=S-R), Risk_Model(type-1)).
We note that even if there is a Type-2 Risk in R, the same results We note that even if there is a Type-2 Risk in recursive resolver R,
hold. the same results hold.
To sum up, the above example is represented in the following To sum up, the above example is represented in the following
template: template:
Eval(mix (u=10, distribution=uniform), Eval(Mix (u=10, distribution=uniform),
System_Setting([S, P, R, A], System_Setting([S, P, R, A], [S-P, P-R, R-A]),
[S-P, P-R, R-A]), Risk_Model(Type-1A, S-R)) {
Risk_Model(Type-1A, S-R)). { Privacy_Mechanism{
Mechanism_name = mix //mix network
Privacy_Mechanism{ Parameters{
Mechanism_name = mix //mixing network Users = 10
Parameters{ Query_distribution = uniform
Users = 10 }
Query_distribution = uniform System_settings{
} Entities = S, P, R and A;
System_settings{ Links = S-P, P-R, R-A
Entities = S, P, R and A; }
Links = S-P, P-R, R-A Risk_Model{
} Type = Type-1A
Risk_Model{ Links = P-R
Type = Type-1A }
Entities = NA
Links = P-R
}
Privacy_guarantee = unlinkability Privacy_guarantee = unlinkability
Privacy_measure = 1-(1/users)^2. Privacy_measure = 1-(1/users)^2.
Return privacy_guarantee, privacy_measure Return privacy_guarantee, privacy_measure
} }
7.3 Encrypted Channel (DNS-over-TLS) Example 7.3 Encrypted Channel (DNS-over-TLS) Example
For one of the encryption-based mechanisms, DNS-over-TLS For one of the encryption-based mechanisms, DNS-over-TLS
[dns-over-tls], we have the following template (TLS parameters are [dns-over-tls], we have the following template (TLS parameters are
from [RFC5246]): from [RFC5246]):
Eval(TLS_enc (SHA256, ECDSA, port 53, uniform, NA), Eval(TLS_enc (SHA256, ECDSA, port 53, uniform),
System_Setting([S, P, R, A], System_Setting([S, P, R, A], [S-P, P-R, RA]),
[S-P, P-R, RA]), Risk_Model(Type-1B, S-R)) {
Risk_Model(Type-1B, S-R)). { Privacy_Mechanism{
Mechanism_name = TLS-upgrade-based
Privacy_Mechanism{ Parameters{
Mechanism_name = TLS-upgrade-based Query_distribution = uniform
Parameters{ Hash_algorithm = SHA256
Users = NA Sig_Algorithm = ECDSA
Query_distribution = uniform Port 53
Hash_algorithm = SHA256 }
Sig_Algorithm = ECDSA System_settings{
Port 53 Entities = S, P, R and A;
} Links = S-P, P-R, R-A
System_settings{ }
Entities = S, P, R and A; Risk_Model{
Links = S-P, P-R, R-A Type = Type-1B
} Links = S-R
Risk_Model{ }
Type = Type-1B Privacy_guarantee = unlinkability, undetectability
Entities = NA Privacy_measure (unlinkability) = 1
Links = S-R Privacy_measure (undetectability) = 0 // port 53 indicates DNS used
}
Privacy_guarantee = unlinkability, undetectability
Privacy_measure (unlinkability) = 1
Privacy_measure (undetectability) = 0 // port 53 indicates DNS used
Return privacy_guarantee, privacy_measure Return privacy_guarantee, privacy_measure
} }
This template features an Active Monitor risk model (Type-2) in order This template features an Active Monitor risk model (Type-2) in order
to show how that the monitor might apply extra resources to an to show how that the monitor might apply extra resources to an
encrypted channel. Undetectability is an issue whether using encrypted channel. Undetectability is an issue whether using
upgrade-based TLS on port 53, or a port-based TLS on a dedicated port upgrade-based TLS on port 53, or a port-based TLS on a dedicated port
- both ports indicate the use of DNS. The source address of the - both ports indicate the use of DNS. The source address of the
individual is exposed in all cases. If this were a suitably individual is exposed in all cases. If this were a suitably
parameterized use of [ipseca], the monitor would not be certain that parameterized use of [ipseca], the monitor would not be certain that
all the traffic from S-R was DNS, and undetectability would be all the traffic from S-R was DNS, and undetectability would be
higher. higher.
7.4 Encrypted Channel (IPSec) Example 7.4 Encrypted Channel (IPSec) Example
In the following, we use the same template above to characterize the In the following, we use the same template above to characterize the
encryption capabilities provided by IPSec, as a potential mechanisms encryption capabilities provided by IPSec, as a potential mechanisms
for enabling privacy in DNS exchange. for enabling privacy in DNS exchanges.
Eval(IPSEc_enc([...]), Eval(IPSEc_enc([...]),
System_Setting([S, P, R, A], System_Setting([S, P, R, A], [S-P, P-R, RA]),
[S-P, P-R, RA]), Risk_Model(Type-1B, S-R)) {
Risk_Model(Type-1B, S-R)). { Privacy_Mechanism{
Mechanism_name = IPSec
Privacy_Mechanism{ Parameters{
Mechanism_name = IPSec
Parameters{
Users = NA
Query_distribution = uniform Query_distribution = uniform
} }
System_settings{ System_settings{
Entities = S, P, R and A; Entities = S, P, R and A;
Links = S-P, P-R, R-A Links = S-P, P-R, R-A
} }
Risk_Model{ Risk_Model{
Type = 2 Type = 2
Entities = NA Links = S-R
Links = S-R }
} Privacy_guarantee = unlinkability, undetectability
Privacy_measure (unlinkability) = 1
Privacy_guarantee = unlinkability, undetectability Privacy_measure (undetectability) = 1
Privacy_measure (unlinkability) = 1
Privacy_measure (undetectability) = 1
Return privacy_guarantee, privacy_measure Return privacy_guarantee, privacy_measure
} }
We note that IPSec can provide better guarantees with respect to We note that IPSec can provide better guarantees with respect to
studied privacy notions. However, whether the technique itself is studied privacy notions. However, whether the technique itself is
widely deployable or not is worth further investigation. widely deployable or not is worth further investigation.
7.5 QName Minimization Example (R-A) Example 7.5 QName Minimization Example (R-A) Example
Analyzing the privacy assurances of QName minimization is a non- Analyzing the privacy assurances of QName minimization is a non-
trivial problem, given that the notions introduced in this document trivial problem, given that the notions introduced in this document
are techniques that do not alter items of interest. This is, the are techniques that do not alter items of interest. This is, the
notions of privacy as outlined above are concerned with a certain IOI notions of privacy as outlined above are concerned with a certain IOI
that is modified by this technique. To this end, we modify the that is modified by this technique. To this end, we modify the
aforementioned notions to suite this technique for analysis purpose aforementioned notions in ordered to be able to analyze the
only. For example, we define linkability as the ability of an technique. For example, we define linkability as the ability of an
adversary to link two labels of (minimized) queries to each other, adversary to link two labels of (minimized) queries to each other,
and relate them to original source of query. Assuming a reasonable and relate them to original source of query. Assuming a reasonable
use of a recursive that minimizes queries on behalf of users, this use of a recursive resolver that minimizes queries on behalf of
task is non-trivial, although quantifying the probability would users, this task is non-trivial, although quantifying the probability
depend on the number of labels in queries, the number of queries would depend on the number of labels in queries, the number of
issued, and the number of users using the studied recursive. The queries issued, and the number of users using the studied recursive
following template captures QName minimization as a template resolvers. The following template captures QName minimization as a
template
Eval(Qname_minimisation ([...], Eval(Qname_minimisation ([...],
System_Settings([S, P, R, A], [R-A]), System_Settings([S, P, R, A], [R-A]),
Risk_Model(Type=2), Risk_Model(Type=2){
Privacy_Mechanism{ Privacy_Mechanism{
Mechanism_name = Qname_minimisation Mechanism_name = Qname_minimisation
Parameters{ Parameters{
Qtype_used = NS Qtype_used = NS
} }
}, System_settings{
System_settings{ Entities = S, P, R and A;
Entities = S, P, R and A; Links = R-A
Links = R-A }
}, Risk_model{
Risk_model{ Type = 2
Type = 2 Links = R-A
Links = R-A }
} Privacy_guarantee = unlinkability
Privacy_guarantee = unlinkability Privacy_measure = analytical
Privacy_measure = analytical
Return privacy_guarantee, privacy_measure Return privacy_guarantee, privacy_measure
} }
Note that QName minimization does not solve the problem of the Note that QName minimization does not solve the problem of the
privacy for a monitoring risk between the stub and recursive. privacy for a monitoring risk between the stub and recursive.
Encrypting the channel between the recursive and the stub, utilizing Encrypting the channel between the recursive and the stub, utilizing
other techniques such as TDNS or IPSec, can marginalize such risk. other techniques such as TDNS or IPSec, can marginalize such risk.
Furthermore, note that the risk on the link between the recursive and Furthermore, note that the risk on the link between the recursive and
authority name servers is always mitigated by the fact that recursive authority name servers is always mitigated by the fact that recursive
name servers act as a mixer of queries, even when they are sent in name servers act as a mixer of queries, even when they are sent in
full to the authority name servers. full to the authority name servers.
skipping to change at page 20, line 29 skipping to change at page 20, line 29
information. Protecting privacy is one of the dimensions of an information. Protecting privacy is one of the dimensions of an
overall security strategy. overall security strategy.
It is possible for privacy-enhancing mechanisms to be deployed in It is possible for privacy-enhancing mechanisms to be deployed in
ways that are vulnerable to security risks, with the result of not ways that are vulnerable to security risks, with the result of not
achieving security gains. For the purposes of privacy evaluation, it achieving security gains. For the purposes of privacy evaluation, it
is important for the person making an evaluation to also ensure close is important for the person making an evaluation to also ensure close
attention to the content of the Security Considerations section of attention to the content of the Security Considerations section of
each mechanism being evaluated, for instance, to ensure if TLS is each mechanism being evaluated, for instance, to ensure if TLS is
used for encryption of a link against surveillance, that TLS best used for encryption of a link against surveillance, that TLS best
security practices [uta-tls-bcp] are in use. security practices [RFC7525] are in use.
10. IANA Considerations 10. IANA Considerations
No requests are made to IANA. No requests are made to IANA.
11. Acknowledgements 11. Acknowledgements
We wish to thank Scott Hollenbeck, Burt Kaliski, Minsuk Kang, Paul We wish to thank Scott Hollenbeck, Burt Kaliski, Minsuk Kang, Paul
Livesay and Eric Osterweil for reviewing early versions. We wish to Livesay and Eric Osterweil for reviewing early versions. We wish to
thank Stephane Bortzmeyer for his detailed review and feedback on the thank Stephane Bortzmeyer and Tim Wicinski for their detailed review
previous version of this document. We also wish to thank those who and feedback on the previous versions of this document. We also wish
commented on presentations of this work ahead of publication, to thank those who commented on presentations of this work ahead of
including Simson Garfinkel, Cathy Meadows, Paul Syverson, and publication, including Simson Garfinkel, Cathy Meadows, Paul
Christine Task. Syverson, and Christine Task.
12. Informative References 12. Informative References
[confidential-dns] [confidential-dns]
Wijngaards, W. and G. Wiley, "Confidential DNS", draft- Wijngaards, W. and G. Wiley, "Confidential DNS", draft-
wijngaards-dnsop-confidentialdns-03 (work in progress), wijngaards-dnsop-confidentialdns-03 (work in progress),
March 2015. March 2015.
[dns-over-tls] [dns-over-tls]
Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A., Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A.,
and P. Hoffman, "TLS for DNS: Initiation and Performance and P. Hoffman, "TLS for DNS: Initiation and Performance
Considerations", draft-hzhwm-dprive-start-tls-for-dns- Considerations", draft-ietf-dprive-dns-over-tls-01.txt
01.txt (work in progress), February 2015. (work in progress), February 2015.
[dprive-problem]
Bortzmeyer, S., "DNS privacy considerations", draft-ietf-
dprive-problem-statement-01 (work in progress), March
2015.
[ipseca] Osterweil, E., Wiley, G., Okubo, T., Lavu, R., and A. [ipseca] Osterweil, E., Wiley, G., Okubo, T., Lavu, R., and A.
Mohaisen, "Opportunistic Encryption with DANE Semantics Mohaisen, "Opportunistic Encryption with DANE Semantics
and IPsec: IPSECA", draft-osterweil-dane-ipsec-02 (work in and IPsec: IPSECA", draft-osterweil-dane-ipsec-03 (work in
progress), March 2015. progress), March 2015.
[openresolverproject.org] [openresolverproject.org]
Mauch, J., "The Open Resolver Project", April 2015. Mauch, J., "The Open Resolver Project", April 2015.
[phb-dnse] [phb-dnse]
Hallam-Baker, P., "DNS Privacy and Censorship: Use Cases Hallam-Baker, P., "DNS Privacy and Censorship: Use Cases
and Requirements", draft-hallambaker-dnse-02 (work in and Requirements", draft-hallambaker-dnse-02 (work in
progress), November 2014. progress), November 2014.
[privatedns] [privatedns]
Hallam-Baker, P., "Private-DNS", draft-hallambaker- Hallam-Baker, P., "Private-DNS", draft-hallambaker-
privatedns-01 (work in progress), November 2014. privatedns-01 (work in progress), November 2014.
[qname-minimisation] [qname-minimisation]
Bortzmeyer, S., "DNS query name minimisation to improve Bortzmeyer, S., "DNS query name minimisation to improve
privacy", draft-ietf-dnsop-qname-minimisation-02 (work in privacy", draft-ietf-dnsop-qname-minimisation-07 (work in
progress), March 2015. progress), March 2015.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July Text on Security Considerations", BCP 72, RFC 3552, DOI
2003. 10.17487/RFC3552, July 2003,
<http://www.rfc-editor.org/info/rfc3552>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI
4949, August 2007. 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, July Considerations for Internet Protocols", RFC 6973, DOI
2013. 10.17487/RFC6973, July 2013,
<http://www.rfc-editor.org/info/rfc6973>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, May 2014. Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, December 2014. Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[uta-tls-bcp] [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
Sheffer, Y., Holz, R., and P. StAndre, "Recommendations "Recommendations for Secure Use of Transport Layer
for Secure Use of TLS and DTLS", draft-ietf-uta-tls-bcp-11 Security (TLS) and Datagram Transport Layer Security
(work in progress), February 2015. (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015,
<http://www.rfc-editor.org/info/rfc7626>.
Authors' Addresses Authors' Addresses
Aziz Mohaisen Aziz Mohaisen
Verisign Labs SUNY Buffalo
12061 Bluemont Way 323 Davis Hall
Reston, VA 20190 Buffalo, NY 14260
US US
Phone: +1 703 948-3200 Phone: +1 716 645-1592
Email: amohaisen@verisign.com Email: mohaisen@buffalo.edu
Allison Mankin Allison Mankin
Verisign Labs Verisign Labs
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
US US
Phone: +1 703 948-3200 Phone: +1 703 948-3200
Email: amankin@verisign.com Email: amankin@verisign.com
 End of changes. 80 change blocks. 
308 lines changed or deleted 306 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/