Network Working Group A. Mohaisen Internet-Draft SUNY Buffalo Intended Status: Informational A

Network Working Group A. Mohaisen Internet-Draft SUNY Buffalo Intended status: Informational A. Mankin Expires: April 20, 2016 Verisign Labs October 18, 2015

Evaluation of Privacy for DNS Private Exchange draft-am-dprive-eval-02

Abstract

The set of DNS requests that an individual makes can provide a monitor with a large amount of information about that individual. DNS Private Exchange (DPRIVE) aims to deprive this actor of this information. This document describes methods for measuring the performance of DNS privacy mechanisms, particularly it provides methods for measuring effectiveness in the face of pervasive monitoring as defined in RFC7258. The document includes example evaluations for common use cases.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 20, 2016.

Mohaisen & Mankin Expires April 20, 2016 [Page 1] Internet-Draft Evaluation of Privacy for DNS October 2015

to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Motivation ...... 2 2. Privacy Evaluation Definitions ...... 4 2.1. Entities ...... 4 2.2. Data and Analysis ...... 5 2.3. Identifiability ...... 5 2.4. Other Central Definitions and Formalizations ...... 6 3. Assumptions about Quantification of Privacy ...... 8 4. System Model ...... 8 4.1. DNS Resolvers (System Model) ...... 9 4.2. System Setup - Putting It Together ...... 9 5. Risk Model ...... 10 5.1. Risk Type-1 - Passive Pervasive Monitor ...... 11 5.2. Risk Type-2 - Active Monitor ...... 11 5.3. Risks in the System Setup ...... 11 6. Privacy Mechanisms ...... 12 7. Privacy Evaluation ...... 13 8. Other evaluation ...... 20 9. Security Considerations ...... 20 10. IANA Considerations ...... 20 11. Acknowledgements ...... 20 12. Informative References ...... 20 Authors' Addresses ...... 22

1. Motivation

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 recent reported pervasive monitoring efforts, another goal is to design protocols and mechanisms to make such monitoring expensive or infeasible to conduct. As detailed in the DPRIVE problem statement [RFC7626], DNS resolution is an important arena for pervasive monitoring, and in some cases may be used for breaching the privacy of individuals. The set of DNS requests that an individual makes can provide a large amount of information about that individual. In some specific use cases, the sets of DNS requests from a DNS recursive resolver or other entity may also provide revealing information. This document describes methods for measuring the performance of DNS privacy mechanisms; in particular, it provides methods for measuring effectiveness in the face of pervasive monitoring as defined in [RFC7258]. The document includes example evaluations for common use cases.

Mohaisen & Mankin Expires April 20, 2016 [Page 2] Internet-Draft Evaluation of Privacy for DNS October 2015

The privacy threats associated with DNS monitoring are not new, however they were made more obvious by the issue described in [RFC7258]. The DPRIVE working group was formed to respond and at this time has several DNS private exchange mechanisms in consideration, including [dns-over-tls], [confidential-dns], [phb-dnse], and [privatedns]. There is also related work in other working groups, including DNSOP: [qname-minimisation] and (potentially) DANE [ipseca]. The recently published RFC on opportunistic security [RFC7435] also has relevance to DNS private exchange.

Each effort related to DNS privacy mechanisms asserts some privacy assurances and operational relevance. Metrics for these privacy assurances are needed and are in reach based on existing techniques from the general field of privacy engineering. Systematic evaluation of DNS privacy mechanisms will enhance the likely operational effectiveness of DNS private exchange.

Evaluating an individual mechanism for DNS privacy could be accomplished on a one-off basis, presumably as Privacy Considerations within each specification, but this will not address as much variation of operational contexts nor will it cover using multiple mechanisms together (in composition). Section 2 of [RFC6973] discussed both benefits and risks of using multiple mechanisms.

Definitions required for evaluating the privacy of stand-alone and composed design are not limited to privacy notions, but also need to include the risk model and some information about relationships among the entities in a given system. A mechanism for providing privacy to withstand the power and capabilities of a passive pervasive monitor may not withstand a more powerful actor using active monitoring by plugging itself into the path of individuals' DNS requests as a forwarder . Having some standard models, and understanding how applicable they are to various designs is a part of evaluating the privacy.

Sections 2 and 3 present privacy terminology and some assumptions. Sections 4 and 5 cover the system model or setup and the risk models of interest. In Section 6, we review a list of DNS privacy mechanisms, including some which are not in scope of the DPRIVE working group. Section 7 tackles how to evaluate privacy mechanisms, 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 interest are quantified.

Mohaisen & Mankin Expires April 20, 2016 [Page 3] Internet-Draft Evaluation of Privacy for DNS October 2015

2. Privacy Evaluation Definitions

This section provides definitions to be used for privacy evaluation of DNS. The verbatim source of most of those definitions is from [RFC6973], which are included as an aid in reasability. In some definitions, text is added to apply them to the DNS case. Also, a new section of terms has been added to include several important practical or conventional terms that were not included in [RFC6973] such as PII. For the terms from [RFC6973], we include their definitions rather than simply referencing them as an aid to readability.

2.1. Entities

o Attacker: An entity that works against one or more privacy protection goals. Unlike observers, attackers' behavior is unauthorized, in a way similar to that of an eavesdropper.

o Eavesdropper: A type of attacker that passively observes an initiator's communications without the initiator's knowledge or authorization. DNS example may include a passive pervasive monitor, defined below.

o Enabler: A protocol entity that facilitates communication between an initiator and a recipient without being directly in the communications path. DNS examples of an enabler in this sense include a recursive resolver, a proxy, or a forwarder.

o Individual: A human being (or a group of them)

o Initiator: A protocol entity that initiates communications with a recipient.

o Intermediary: A protocol entity that sits between the initiator (DNS example of stub resolver) and the recipient (DNS example of recursive resolver or authority resolver) and is necessary for the initiator and recipient to communicate. Unlike an eavesdropper, an intermediary is an entity that is part of the communication architecture and therefore at least tacitly authorized.

o Observer: An entity that is able to observe and collect information from communications, potentially posing privacy risks, depending on the context. As defined in this document, initiators, recipients, intermediaries, and enablers can all be observers. Observers are distinguished from eavesdroppers by being at least tacitly authorized.

Mohaisen & Mankin Expires April 20, 2016 [Page 4] Internet-Draft Evaluation of Privacy for DNS October 2015

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 in the context of this document, because it corresponds to the subject of interest being studied. Similar to the definition in [RFC7258], we note that an attacker is broader than an observer. While [RFC7258] claim that an attack does not consider the motive of the actor, the given context of DNS implies a motive if the term attacker is used to characterize the risk.

2.2. Data and Analysis

We assume the following definitions related to data and analysis from [RFC4949]: attacker, correlation, fingerprint, fingerprinting, item of interest (IOI), personal data, interaction, traffic analysis, undetectability, and unlinkability. We augment some of those definitions later in this document.

from [RFC4949], we relax the definition of IOI to exclude "the fact that a communication interaction has taken place" as this does not suite the evaluated context of DNS.

2.3. Identifiability

We assume the following definitions related to identifiability from [RFC4949]: anonymity, anonymity set, anonymous, attribute, identity provider, personal name, and relying party.

The following definitions are modified for the context of this document from those defined in [RFC4949]

o Identifiability: The extent to which an individual is identifiable. [RFC6973] includes the rest of the variations on this (Identifiable, Identification, Identified, Identifier, Identity, Identity Confidentiality)

o Personal Name: A natural name for an individual. Personal names are often not unique and often comprise given names in combination with a family name. An individual may have multiple personal names at any time and over a lifetime, including official names. From a technological perspective, it cannot always be determined whether a given reference to an individual is, or is based upon, the individual's personal name(s) (see Pseudonym). NOTE: The reason to import this definition is that some query names that cause privacy leakage do so by embedding personal names as identifiers of host or other equipment, e.g. AllisonMankinMac.example.com.

Mohaisen & Mankin Expires April 20, 2016 [Page 5] Internet-Draft Evaluation of Privacy for DNS October 2015

o Pseudonymity: See the formal definition in section 2.4 in lieu of [RFC6973].

NOTE: Identifiability Definitions in [RFC6973] also include some material not included here because the distinctions are not major for DNS Private Exchange, such as real and official names, and variant forms of Pseudonymity in its informal definition.

2.4. Other Central Definitions and Formalizations

Central to the presentation of this document is the definition of personally identifiable information (PII), as well as other definitions that supplement the definitions listed earlier or modify them for the context of this document. In this section, we outline such definitions we further notes on their indications.

o Personally Identifiable Information (PII): Information (attributes) that can be used as is, or along with other side information, to identify, locate, and/or contact a single individual or subject (c.f. item of interest).

NOTE: the definition above indicates that PII can be used on its own or in context. In DNS privacy, the items without additional context include IP(v4 or v6) addresses, qname, qtype, timings of queries, etc. The additional context includes organization-level attributes, such as a network prefix that can be associated with an organization. The definition of PII is complementary to the definition of items of interest.

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 can reference the group or organization as Subject rather than Individual.

Often it is desirable to reference alternative identifiers known as pseudonyms. A pseudonym is a name assumed by an individual in some context, unrelated to the names or identifiers known by others in that context.

o Pseudonymity/Pseudonym: a relaxation of the definition of anonymity for usability. In particular, pseudonymity is an anonymity feature obtained by using a pseudonym, an identifier that is used for establishing a long relationship between two entities.

As an example, in the DNS context, a randomly generated pseudonym might identify a set of query data with a shared context, such as geographic origin. Such pseudonymity enables another entity

Mohaisen & Mankin Expires April 20, 2016 [Page 6] Internet-Draft Evaluation of Privacy for DNS October 2015

interested in breaching the privacy to link multiple queries on a long-term basis. Pseudonyms are assumed long-lived and their uniqueness may be a goal. There are many findings that indicate that pseudonymity is weaker than anonymity.

o Unlinkability: Formally, two items of interest are said to be unlinkable if the certainty of an actor concerning those items of interest is not affected by observing the system. This is, unlinkability implies that the a-posteriori probability computed a monitor that two items of interest are related is close enough to the a-priori probability computed by a monitor based on their knowledge.

Two items of interest are said to be unlinkable if there is a small chance (beta, close to 0 probability) that the monitor identifies them as associated, and they are linkable if there is a sufficiently large probability (referred to as alpha).

Informally, given two items of interest (user attributes, DNS queries, users, etc.), unlinkability is defined as the inability of the monitor to sufficiently determine whether those items are related to one another. In the context of DNS, this refers typically but not only to a monitor relating queries to the same individual.

o Undetectability: a stronger definition of privacy, where an item of interest is said to be undetectable if the monitor is not sufficiently able to know or tell whether the item exists or not.

Note that undetectability implies unlinkability. As explained below, a way of ensuring undetectability is to use encryption that is secure under known ciphertext attacks, or randomized encryption.

o Unobservability: a stronger definition of privacy that requires satisfying both undetectability and anonymity. Unobservability means that an item of interest is undetectable by any not involved individual, monitor or not.

In theory, there are many ways of ensuring unobservability by fulfilling both requirements. For example, undetectability requires that no party that is not invovled in the resolution of a DNS query shall know that query has existed or not. A mechanism to ensure this function is encryption secure under known ciphertext attacks, or randomized encryption for all other than stub resolvers, and pseudonyms for the stub resolver. An alternative mechanism to provide the anonymity property would be the use of mix networks for routing DNS queries.

Mohaisen & Mankin Expires April 20, 2016 [Page 7] Internet-Draft Evaluation of Privacy for DNS October 2015

3. Assumptions about Quantification of Privacy

The quantification of privacy is connected with the privacy goals. Is the desired privacy property unlinkability only, or is it undetectability? Is pseudonymity a sufficient property? Parameters and entire privacy mechanism choices are affected by the choice of privacy goals.

While a binary measure of privacy is sometimes possible, that is, being able to say that the transaction is anonymous, in this document, we assume that the binary is not frequently obtainable, and therefore we focus on methods for continuous quantification. Both are relevant to DNS Private Exchange. Another way to state this is that the quantification could be exactly the probabilities 1 and 0, corresponding to the binary, but the methods prefer to provide continuous values instead.

Here is an example of continuous quantification, related to identifiability of an individual or item of interest based on observing queries.

o For an individual A, and a set of observations by a monitor Y, where Y = [y1, y2, ... yn], we define the privacy of A as the uncertainty of the monitor knowing that A is itself among many 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 define the privacy of r as Privacy = 1 - P[r | Y].

4. System Model

A DNS client (a DNS stub resolver) may resolve a domain name or address into the corresponding DNS record by contacting the authoritative name server responsible for that domain name (or address) directly. However, to improve the operation of DNS resolution, and reduce the round trip time required for resolving an address, both caching and recursive resolution are implemented. Caching is implemented at an intermediary between the stub and the authoritative name server. In practice, many caching servers also implement the recursive logic of DNS resolution for finding the name server authoritative for a domain, and are thus called DNS recursive resolvers. Another type of entity, DNS forwarders (or proxies), acts as intermediaries between stub resolvers and recursive resolvers, and recursive resolvers and authoritative resolvers. The system model for DNS privacy evaluation includes the four entities quickly sketched here: stub resolvers, recursive resolvers, authoritative name servers, and forwarders.

Mohaisen & Mankin Expires April 20, 2016 [Page 8] Internet-Draft Evaluation of Privacy for DNS October 2015

4.1. DNS Resolvers (System Model)

o Stub resolver (S): a minimal resolver that does not support referral, and delegates recursive resolution to a recursive resolver. A stub resolver is a consumer of recursive resolutions. Per the terminology of [RFC6973], a stub resolver is an Initiator.

o Recursive resolver (R): a resolver that implements the recursive function of DNS resolution on behalf of a stub resolver. Per the terminology of [RFC6973], a recursive resolver is an Enabler.

o Authoritative resolver (A): is a server that is the origin of a DNS record. A recursive resolver queries the authoritative resolver to resolve a domain name or address. Per the terminology of [RFC6973], the authoritative name server is also an Enabler.

o Forwarder/proxy (P): between the stub resolver and the authoritative resolver there may be one or more DNS-involved entity. These are systems located between S and R (stub resolver and recursive), or between R and A (recursive and authoritative), which do not play a primary role in the DNS protocol. Per the terminology of [RFC6973], forwarders are Intermediaries.

4.2. System Setup - Putting It Together

Evaluating various privacy protection mechanisms in relation to monitors such as the pervasive monitors defined next requires understanding links in the system setup. We define the following links. In relation to [RFC7258] these are the attack surface where a monitor (eavesdropper) can collect sets of query information.

o Stub -> Recursive (S-R): a link between the stub resolver and a recursive resolver. At the time of writing, the scope of DPRIVE 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 forwarder/ proxy. The intended function of this link may be difficult to analyze.

o Proxy -> Recursive (P-R): a link between a proxy and a recursive server.

o Recursive -> Authoritative (R-A): a link between a recursive and an authoritative name server. Although at the time of writing, R-A is not in the DPRIVE scope, we discuss it in the evaluation.

Mohaisen & Mankin Expires April 20, 2016 [Page 9] Internet-Draft Evaluation of Privacy for DNS October 2015

Rather than notating in system setup that an entity is compromised, this is covered in the monitor model in Section 6, which has system elements as parameters.

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 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 a recursive is serving a relatively small number of individuals. The query traffic of a subject group or organization (c.f. Subject in the definitions) is obtained by the monitor who monitors this system's R-A.

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 is that PII, the individual's private identifying information, is not 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 recursive. From a functionality point of view they can all be consolidated into a single proxy without affecting the system view. However, the behavior of such proxies may affect the size and shape of the attack surface. However, we believe that an additional treatment is needed for this case and it is not included in the discussion.

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 respect for the DPRIVE charter's scope at this time. According to recent work at [openresolverproject.org], there may be multiple intermediaries with poorly defined behavior.

The system setup here leaves out other realistic considerations for simplicity, such as the impact of shared caches in DNS entities.

5. Risk Model

The Definitions section defines observer, attack and monitor, but not a Risk Model, which is needed to actually evaluate privacy.

For consistency, we note that the only difference between an attacker and an obeserver is that an attacker is an unauthorized observer with all the capabilities it may have. We also stress that for the context of DNS privacy, the term attacker may implicitly assume an intent. To that end, active and passive observers are collectively referred to as actors.

Mohaisen & Mankin Expires April 20, 2016 [Page 10] Internet-Draft Evaluation of Privacy for DNS October 2015

o Risk Model: a well-defined set of capabilities indicating how much information an observer (or eavesdropper) has, and in what context, in order to reach a goal of breaching the privacy of an individual or subject with respect to a given privacy metric.

In this document we focus on two risk models, namely a pervasive monitor and a malicious monitor.

5.1. Risk Type-1 - Passive Pervasive Monitor

This risk corresponds to the passive pervasive monitoring model described in [RFC7258]. This model relies on monitoring capabilities to breach the privacy of individuals from the DNS traffic at scale without decimation. An actor causing this risk is capable of eavesdropping or observing traffic between two end points, including traffic between any of the pairs of entities described in section 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 attack. Type-1 monitors are passive. They do not modify traffic or insert traffic.

5.2. Risk Type-2 - Active Monitor

This risk corresponds to an actor with the same types of capabilities of monitoring links. Additionally, this model can select links in order to target specific individuals. A Type-2 monitor for instance might put into place intermediaries in order to obtain traffic on specific links.

Note that we exclude malicious monitoring from this document since, by definition, a malicious actor has an intent associated with his actions.

5.3. Risks in the System Setup

To evaluate the privacy provided by a given mechanism or mechanisms in a particular system model, we characterize the risk using a template where parameters from the system model in which the risk actor (eavesdropper or observer as monitors) is located are used. The general template is: Risk(Type, [Entities], [Links]). For example, the template Risk(Type-2, R, S-R) passed as a parameter in the evaluation of a privacy mechanism indicates a Type-2 monitor that controls a recursive resolver and has the capability of eavesdropping on the link between the stub and recursive resolvers (S-R). Other risk templates include the appropriate parameterizations based on the above description of those monitors, including monitors that have the capabilities of monitoring multiple links and controlling multiple pieces of infrastructure.

Mohaisen & Mankin Expires April 20, 2016 [Page 11] Internet-Draft Evaluation of Privacy for DNS October 2015

6. Privacy Mechanisms

Various mechanisms for enhancing privacy in networks are applicable to DNS private exchange. Some mechanisms common to privacy research include mix networks, dummy traffic, and private information retrieval techniques. Applicable protocol mechanisms include encryption-based techniques - encrypting the channel carrying the queries using IPSEC [ipseca], TLS [dns-over-tls] or special-purpose encryption [confidential-dns]. [privatedns] includes special-purpose encryption but also depends on a trusted service broker.

o Mix Networks: in this type of mechanism, the initiator uses a mix network such as Tor to route the DNS queries to the intended DNS server entity. A monitor observing part of the system finds it difficult to determine which individual sends which queries, and will not be able to tell which individual has sent them (ideally, though it is known that attacks exist that allow correlation and privacy breaches against mix networks). The privacy property is unlinkability of the queries; the probability that two queries coming from one exit node in the mix network belong to the same individual is uniform among all the individuals using the network.

o Dummy Traffic: a simple mechanism in which the initiator of a DNS request will also generate k dummy queries and send the intended query along with those queries. As such, the adversary will not 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 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 the protocol, the monitor is bounded to the undetectability of the queries.

o Private Information Retrieval: a mechanism that allows a user s to retrieve a record r from a database DB on a server without allowing the server to learn the recordr. A trivial solution to the problem requires that s downloads the entire database DB and then perform the queries locally. While this provides privacy to the queries of the user, the solution is communication inefficient at the scale of the DNS. More sophisticated cryptographic solutions are multi-round, and thus reduce the communication overhead, but are still inefficient for the DNS.

o Query Minimization: a mechanism that allows the resolver to minimize the amount of information it sends on behalf of a stub resolver. A method of query minimization is specified in [qname-minimisation]. Qname minimization deprives a Type-1 risk on R-A of information from correlating queries, unless the individuals have an Unfortunate Few problem.

Mohaisen & Mankin Expires April 20, 2016 [Page 12] Internet-Draft Evaluation of Privacy for DNS October 2015

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 R. With respect R or A themselves, they may have well established policies for respecting the sensitivity of queries they process, while still using summary analysis of those queries to improve security, stability of their business operation.

o Encrypted Channel Mechanisms: Using these mechanisms, an initiator has an encrypted channel with a corresponding enabler, so that the queries are not available to eavesdropping Pervasive Monitor risk. Examples include [dns-over-tls], [ipseca], and [confidential-dns]. Depending on the characteristics of the channel, various privacy properties are ensured. For instance, undetectability of queries is ensured for encryption-based mechanisms once the encrypted channel is established. Unlinkability of the queries may depend on the type of crypto-suite; it is provided as long as randomized encryption is used.

o Composed (Multiple) Mechanisms: the use of multiple mechanisms is a likely scenario and results in varied privacy guarantees. Consider a hypothetical system in which mix networks (for unlinkability) and randomized encryption (for undetectability) can both be applied, thus providing for unobservability, a stronger property than either of the two along. On the other hand, consider another hypothetical system in which mix networks are used to reach a third party broker requiring sign-in and authorization. Depending on the risk type, this could mean that the mix network unlinkability was cancelled out by the linkability due to entrusting the third party with identifying information in order to be authorized.

7. Privacy Evaluation

Now we turn our attention to the evaluation of privacy mechanisms in a standard form, given the risk models and system definitions, for some of the example mechanisms.

An evaluation takes multiple parameters as input. The output of the evaluation template is based on the analysis of the individual algorithms, settings, and parameters passed to this evaluation mechanism.

Here is the top level interface of the evaluation template:

Eval(Privacy_Mechanism(params), System_Setting(params), Risk_Model(params) )

Mohaisen & Mankin Expires April 20, 2016 [Page 13] Internet-Draft Evaluation of Privacy for DNS October 2015

The output of the function is a privacy guarantee for the given settings, expressed through defined properties such as unlinkability and unobservability, for the specified system and risk model.

7.1 Dummy Traffic Example

Eval(Dummy_Traffic (k=10, distribution=uniform), 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 mechanism, though there's no way to know if there are deployments of this type of mechanism. This example evaluation uses k=10 to indicate that for every one query initiated by an individual, ten queries that disguise the query of interest are selected randomly from a pool of queries. In the parameters passed in the evaluation function, we indicate that the privacy assurances of interest concern the S-R link, with a Passive Pervasive Monitor (Type-1A) risk.

Here is a template format for the example:

Eval(Dummy_Traffic (k=10, distribution=uniform), System_Setting([S, P, R, A], [S-P, P-R, R-A]), Risk_Model(Type-1A, S-R)) { Privacy_Mechanism{ Mechanism_name = Dummy_Traffic Parameters{ Queries = 10 Query_distribution = uniform } System_settings{ Entities = S, P, R and A; Links = S-P, P-R, R-A } Risk_Model{ Type = Type-1A Links = S-R } Privacy_guarantee = undetectability Privacy_measure = 1-(1/(queries+1)).

Return Privacy_guarantee, Privacy_measure

}

Undetectability is provided with 0.91 probability (though we know there are other weaknesses for dummy traffic) If the threat model is

Mohaisen & Mankin Expires April 20, 2016 [Page 14] Internet-Draft Evaluation of Privacy for DNS October 2015

replaced with Type-2, so that responses to arbitrary requests can be injected, and tracked, the undetectability probability is decreased.

7.2 Mix Network Example

Here is an input for a mix network privacy mechanism:

Eval(Mix (u=10, distribution=uniform), System_Setting(link=S-R), threat_Model(Type-1A))

This indicates that the monitor resides between the stub and resolver. While queries are not undetectable, two queries are not linkable to the same individual; the provided guarantee is unlinkability. For a given number of individuals in the mix network, indicated by the parameter u, assuming that at any time, traffic from these individuals is uniformly random, the probability that one query is comes from a given individual is (1/10 = 0.1). The probability that two queries are issued by the same initiator is 0.1^2 = 0.01, which represents the linkability probability. The unlinkability probability is given as 1-0.01 = 0.99. Thus,

(unlinkability, 0.99) < Eval(Mix (u=10, distribution=uniform), System_Setting(link=S-R), Risk_Model(type-1)).

We note that even if there is a Type-2 Risk in recursive resolver R, the same results hold.

To sum up, the above example is represented in the following template:

Mohaisen & Mankin Expires April 20, 2016 [Page 15] Internet-Draft Evaluation of Privacy for DNS October 2015

Eval(Mix (u=10, distribution=uniform), System_Setting([S, P, R, A], [S-P, P-R, R-A]), Risk_Model(Type-1A, S-R)) { Privacy_Mechanism{ Mechanism_name = mix //mix network Parameters{ Users = 10 Query_distribution = uniform } System_settings{ Entities = S, P, R and A; Links = S-P, P-R, R-A } Risk_Model{ Type = Type-1A Links = P-R }

Privacy_guarantee = unlinkability Privacy_measure = 1-(1/users)^2.

Return privacy_guarantee, privacy_measure }

7.3 Encrypted Channel (DNS-over-TLS) Example

For one of the encryption-based mechanisms, DNS-over-TLS [dns-over-tls], we have the following template (TLS parameters are from [RFC5246]):

Mohaisen & Mankin Expires April 20, 2016 [Page 16] Internet-Draft Evaluation of Privacy for DNS October 2015

Eval(TLS_enc (SHA256, ECDSA, port 53, uniform), System_Setting([S, P, R, A], [S-P, P-R, RA]), Risk_Model(Type-1B, S-R)) { Privacy_Mechanism{ Mechanism_name = TLS-upgrade-based Parameters{ Query_distribution = uniform Hash_algorithm = SHA256 Sig_Algorithm = ECDSA Port 53 } System_settings{ Entities = S, P, R and A; Links = S-P, P-R, R-A } Risk_Model{ Type = Type-1B Links = S-R } Privacy_guarantee = unlinkability, undetectability Privacy_measure (unlinkability) = 1 Privacy_measure (undetectability) = 0 // port 53 indicates DNS use d

Return privacy_guarantee, privacy_measure }

This template features an Active Monitor risk model (Type-2) in order to show how that the monitor might apply extra resources to an encrypted channel. Undetectability is an issue whether using 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 individual is exposed in all cases. If this were a suitably parameterized use of [ipseca], the monitor would not be certain that all the traffic from S-R was DNS, and undetectability would be higher.

7.4 Encrypted Channel (IPSec) Example

In the following, we use the same template above to characterize the encryption capabilities provided by IPSec, as a potential mechanisms for enabling privacy in DNS exchanges.

Mohaisen & Mankin Expires April 20, 2016 [Page 17] Internet-Draft Evaluation of Privacy for DNS October 2015

Eval(IPSEc_enc([...]), System_Setting([S, P, R, A], [S-P, P-R, RA]), Risk_Model(Type-1B, S-R)) { Privacy_Mechanism{ Mechanism_name = IPSec Parameters{ Query_distribution = uniform } System_settings{ Entities = S, P, R and A; Links = S-P, P-R, R-A } Risk_Model{ Type = 2 Links = S-R } Privacy_guarantee = unlinkability, undetectability Privacy_measure (unlinkability) = 1 Privacy_measure (undetectability) = 1

Return privacy_guarantee, privacy_measure }

We note that IPSec can provide better guarantees with respect to studied privacy notions. However, whether the technique itself is widely deployable or not is worth further investigation.

7.5 QName Minimization Example (R-A) Example

Analyzing the privacy assurances of QName minimization is a non- trivial problem, given that the notions introduced in this document are techniques that do not alter items of interest. This is, the notions of privacy as outlined above are concerned with a certain IOI that is modified by this technique. To this end, we modify the aforementioned notions in ordered to be able to analyze the technique. For example, we define linkability as the ability of an adversary to link two labels of (minimized) queries to each other, and relate them to original source of query. Assuming a reasonable use of a recursive resolver that minimizes queries on behalf of users, this task is non-trivial, although quantifying the probability would depend on the number of labels in queries, the number of queries issued, and the number of users using the studied recursive resolvers. The following template captures QName minimization as a template

Mohaisen & Mankin Expires April 20, 2016 [Page 18] Internet-Draft Evaluation of Privacy for DNS October 2015

Eval(Qname_minimisation ([...], System_Settings([S, P, R, A], [R-A]), Risk_Model(Type=2){ Privacy_Mechanism{ Mechanism_name = Qname_minimisation Parameters{ Qtype_used = NS } System_settings{ Entities = S, P, R and A; Links = R-A } Risk_model{ Type = 2 Links = R-A } Privacy_guarantee = unlinkability Privacy_measure = analytical

Return privacy_guarantee, privacy_measure }

Note that QName minimization does not solve the problem of the privacy for a monitoring risk between the stub and recursive. Encrypting the channel between the recursive and the stub, utilizing other techniques such as TDNS or IPSec, can marginalize such risk. Furthermore, note that the risk on the link between the recursive and 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 full to the authority name servers.

7.7 Private-DNS (S-R) Example

The template for [privatedns] takes note of deployments in which in addition to S, R and A, there is another entity in the system, the function that authenticates the individual using S prior to permitting an encrypted channel to be formed to R or A. If the Private-DNS connection is with R, then identifiability of S as an individual may be similar to the identifiability of S from source address, or it may be stronger, depending on the nature of the account information required. If the Private-DNS connection is with A, source address PII is provided to A, and linkability of the queries from S has probability 1.

Mohaisen & Mankin Expires April 20, 2016 [Page 19] Internet-Draft Evaluation of Privacy for DNS October 2015

8. Other evaluation

This document does not address a lot of the evaluation aspects not associated with privacy. For example, some of the mechanisms discussed in the working group are built of well-understood and standardized technologies, whereas others use other non-standard and less widely deployed techniques. A comprehensive evaluation of such mechanisms should take into account such facts.

9. Security Considerations

The purpose of this document is to provide methods for those deploying or using DNS private exchange to assess the effectiveness of privacy mechanisms in depriving monitors of access to private information. Protecting privacy is one of the dimensions of an overall security strategy.

It is possible for privacy-enhancing mechanisms to be deployed in ways that are vulnerable to security risks, with the result of not achieving security gains. For the purposes of privacy evaluation, it is important for the person making an evaluation to also ensure close attention to the content of the Security Considerations section of each mechanism being evaluated, for instance, to ensure if TLS is used for encryption of a link against surveillance, that TLS best security practices [RFC7525] are in use.

10. IANA Considerations

No requests are made to IANA.

11. Acknowledgements

We wish to thank Scott Hollenbeck, Burt Kaliski, Minsuk Kang, Paul Livesay and Eric Osterweil for reviewing early versions. We wish to thank Stephane Bortzmeyer and Tim Wicinski for their detailed review and feedback on the previous versions of this document. We also wish to thank those who commented on presentations of this work ahead of publication, including Simson Garfinkel, Cathy Meadows, Paul Syverson, and Christine Task.

12. Informative References

[confidential-dns] Wijngaards, W. and G. Wiley, "Confidential DNS", draft- wijngaards-dnsop-confidentialdns-03 (work in progress), March 2015.

Mohaisen & Mankin Expires April 20, 2016 [Page 20] Internet-Draft Evaluation of Privacy for DNS October 2015

[dns-over-tls] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A., and P. Hoffman, "TLS for DNS: Initiation and Performance Considerations", draft-ietf-dprive-dns-over-tls-01.txt (work in progress), February 2015.

[ipseca] Osterweil, E., Wiley, G., Okubo, T., Lavu, R., and A. Mohaisen, "Opportunistic Encryption with DANE Semantics and IPsec: IPSECA", draft-osterweil-dane-ipsec-03 (work in progress), March 2015.

[openresolverproject.org] Mauch, J., "The Open Resolver Project", April 2015.

[phb-dnse] Hallam-Baker, P., "DNS Privacy and Censorship: Use Cases and Requirements", draft-hallambaker-dnse-02 (work in progress), November 2014.

[privatedns] Hallam-Baker, P., "Private-DNS", draft-hallambaker- privatedns-01 (work in progress), November 2014.

[qname-minimisation] Bortzmeyer, S., "DNS query name minimisation to improve privacy", draft-ietf-dnsop-qname-minimisation-07 (work in progress), March 2015.

[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, .

[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, .

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ RFC5246, August 2008, .

[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, .

Mohaisen & Mankin Expires April 20, 2016 [Page 21] Internet-Draft Evaluation of Privacy for DNS October 2015

[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, .

[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, .

[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, .

[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, .

Authors' Addresses

Aziz Mohaisen SUNY Buffalo 323 Davis Hall Buffalo, NY 14260 US

Phone: +1 716 645-1592 Email: [email protected]

Allison Mankin Verisign Labs 12061 Bluemont Way Reston, VA 20190 US

Phone: +1 703 948-3200 Email: [email protected]

Mohaisen & Mankin Expires April 20, 2016 [Page 22] DPRIVE T. Reddy Internet-Draft Cisco Intended status: Experimental D. Wing Expires: June 19, 2017 P. Patil Cisco December 16, 2016

Specification for DNS over Datagram Transport Layer Security (DTLS) draft-ietf-dprive-dnsodtls-15

Abstract

DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information which is valuable to protect.

This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce DTLS handshake size. The proposed mechanism runs over port 853.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

This Internet-Draft will expire on June 19, 2017.

Reddy, et al. Expires June 19, 2017 [Page 1] Internet-Draft DNS over DTLS December 2016

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction ...... 2 1.1. Relationship to TCP Queries and to DNSSEC ...... 3 1.2. Document Status ...... 3 2. Terminology ...... 4 3. Establishing and Managing DNS-over-DTLS Sessions ...... 4 3.1. Session Initiation ...... 4 3.2. DTLS Handshake and Authentication ...... 5 3.3. Established Sessions ...... 5 4. Performance Considerations ...... 6 5. PMTU issues ...... 7 6. Anycast ...... 8 7. Usage ...... 8 8. IANA Considerations ...... 8 9. Security Considerations ...... 9 10. Acknowledgements ...... 9 11. References ...... 9 11.1. Normative References ...... 10 11.2. Informative References ...... 11 Authors' Addresses ...... 12

1. Introduction

The Domain Name System is specified in [RFC1034] and [RFC1035]. DNS queries and responses are normally exchanged unencrypted and are thus vulnerable to eavesdropping. Such eavesdropping can result in an undesired entity learning domains that a host wishes to access, thus resulting in privacy leakage. The DNS privacy problem is further discussed in [RFC7626].

This document defines DNS over DTLS (DNS-over-DTLS) which provides confidential DNS communication between stub resolvers and recursive resolvers, stub resolvers and forwarders, forwarders and recursive resolvers. DNS-over-DTLS puts an additional computational load on servers. The largest gain for privacy is to protect the communication between the DNS client (the end user's machine) and its caching resolver. DNS-over-DTLS might work equally between recursive

Reddy, et al. Expires June 19, 2017 [Page 2] Internet-Draft DNS over DTLS December 2016

clients and authoritative servers, but this application of the protocol is out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group per its current charter. This document does not change the format of DNS messages.

The motivations for proposing DNS-over-DTLS are that

o TCP suffers from network head-of-line blocking, where the loss of a packet causes all other TCP segments to not be delivered to the application until the lost packet is re-transmitted. DNS-over- DTLS, because it uses UDP, does not suffer from network head-of- line blocking.

o DTLS session resumption consumes 1 round trip whereas TLS session resumption can start only after TCP handshake is complete. However, with TCP Fast Open [RFC7413], the implementation can achieve the same RTT efficiency as DTLS.

Note: DNS-over-DTLS is an experimental update to DNS, and the experiment will be concluded when the specification is evaluated through implementations and interoperability testing.

1.1. Relationship to TCP Queries and to DNSSEC

DNS queries can be sent over UDP or TCP. The scope of this document, however, is only UDP. DNS over TCP can be protected with TLS, as described in [RFC7858]. DNS-over-DTLS alone cannot provide privacy for DNS messages in all circumstances, specifically when the DTLS record size is larger than the path MTU. In such situations the DNS server will respond with a truncated response (see Section 5). Therefore DNS clients and servers that implement DNS-over-DTLS MUST also implement DNS-over-TLS in order to provide privacy for clients that desire Strict Privacy as described in [I-D.ietf-dprive-dtls-and-tls-profiles].

DNS Security Extensions (DNSSEC [RFC4033]) provides object integrity of DNS resource records, allowing end-users (or their resolver) to verify legitimacy of responses. However, DNSSEC does not provide privacy for DNS requests or responses. DNS-over-DTLS works in conjunction with DNSSEC, but DNS-over-DTLS does not replace the need or value of DNSSEC.

1.2. Document Status

This document is an Experimental RFC. One key aspect to judge whether the approach is usable on a large scale is by observing the uptake, usability, and operational behavior of the protocol in large- scale, real-life deployments.

Reddy, et al. Expires June 19, 2017 [Page 3] Internet-Draft DNS over DTLS December 2016

This DTLS solution was considered by the DPRIVE working group as an option to use in case the TLS based approach specified in [RFC7858] turns out to have some issues when deployed. At the time of writing, it is expected that [RFC7858] is what will be deployed, and so this specification is mainly intended as a backup.

The following guidelines should be considered when performance benchmarking DNS over DTLS:

1. DNS over DTLS can recover from packet loss and reordering, and does not suffer from network head-of-line blocking. DNS over DTLS performance in comparison with DNS over TLS may be better in lossy networks.

2. The number of round trips to send the first DNS query over DNS over DTLS is less than the number of round trips to send the first DNS query over TLS. Even if TCP Fast Open is used, it only works for subsequent TCP connections between the DNS client and server (Section 3 in [RFC7413]).

3. If DTLS 1.3 protocol [I-D.rescorla-tls-dtls13] is used for DNS over DTLS, it provides critical latency improvements for connection establishment over DTLS 1.2.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] .

3. Establishing and Managing DNS-over-DTLS Sessions

3.1. Session Initiation

By default, DNS-over-DTLS MUST run over standard UDP port 853 as defined in Section 8, unless the DNS server has mutual agreement with its clients to use a port other than 853 for DNS-over-DTLS. In order to use a port other than 853, both clients and servers would need a configuration option in their software.

The DNS client should determine if the DNS server supports DNS-over- DTLS by sending a DTLS ClientHello message to port 853 on the server, unless it has mutual agreement with its server to use a port other than port 853 for DNS-over-DTLS. Such another port MUST NOT be port 53 but MAY be from the "first-come, first-served" port range (User Ports [RFC6335], range 1024- 49151) . This recommendation against use

Reddy, et al. Expires June 19, 2017 [Page 4] Internet-Draft DNS over DTLS December 2016

of port 53 for DNS-over-DTLS is to avoid complication in selecting use or non-use of DTLS and to reduce risk of downgrade attacks.

A DNS server that does not support DNS-over-DTLS will not respond to ClientHello messages sent by the client. If no response is received from that server, and the client has no better round-trip estimate, the client SHOULD retransmit the DTLS ClientHello according to Section 4.2.4.1 of [RFC6347]. After 15 seconds, it SHOULD cease attempts to re-transmit its ClientHello. The client MAY repeat that procedure to discover if DNS-over-DTLS service becomes available from the DNS server, but such probing SHOULD NOT be done more frequently than every 24 hours and MUST NOT be done more frequently than every 15 minutes. This mechanism requires no additional signaling between the client and server.

DNS clients and servers MUST NOT use port 853 to transport cleartext DNS messages. DNS clients MUST NOT send and DNS servers MUST NOT respond to cleartext DNS messages on any port used for DNS-over-DTLS (including, for example, after a failed DTLS handshake). There are significant security issues in mixing protected and unprotected data, therefore UDP connections on a port designated by a given server for DNS-over-DTLS are reserved purely for encrypted communications.

3.2. DTLS Handshake and Authentication

DNS client initiates DTLS handshake as described in [RFC6347], following the best practices specified in [RFC7525]. After DTLS negotiation completes, if the DTLS handshake succeeds according to [RFC6347] the connection will be encrypted and is now protected from eavesdropping.

DNS privacy requires encrypting the query (and response) from passive attacks. Such encryption typically provides integrity protection as a side-effect, which means on-path attackers cannot simply inject bogus DNS responses. However, to provide stronger protection from active attackers pretending to be the server, the server itself needs to be authenticated. To authenticate the server providing DNS privacy, DNS client MUST use the authenication mechanisms discussed in [I-D.ietf-dprive-dtls-and-tls-profiles]. This document does not propose new ideas for authentication.

3.3. Established Sessions

In DTLS, all data is protected using the same record encoding and mechanisms. When the mechanism described in this document is in effect, DNS messages are encrypted using the standard DTLS record encoding. When a user of DTLS wishes to send a DNS message, the data is delivered to the DTLS implementation as an ordinary application

Reddy, et al. Expires June 19, 2017 [Page 5] Internet-Draft DNS over DTLS December 2016

data write (e.g., SSL_write()). A single DTLS session can be used to send multiple DNS requests and receive multiple DNS responses.

To mitigate the risk of unintentional server overload, DNS-over-DTLS clients MUST take care to minimize the number of concurrent DTLS sessions made to any individual server. It is RECOMMENDED that for any given client/server interaction there SHOULD be no more than one DTLS session. Similarly, servers MAY impose limits on the number of concurrent DTLS sessions being handled for any particular client IP address or subnet. These limits SHOULD be much looser than the client guidelines above, because the server does not know, for example, if a client IP address belongs to a single client, is multiple resolvers on a single machine, or is multiple clients behind a device performing Network Address Translation (NAT).

In between normal DNS traffic while the communication to the DNS server is quiescent, the DNS client MAY want to probe the server using DTLS heartbeat [RFC6520] to ensure it has maintained cryptographic state. Such probes can also keep alive firewall or NAT bindings. This probing reduces the frequency of needing a new handshake when a DNS query needs to be resolved, improving the user experience at the cost of bandwidth and processing time.

A DTLS session is terminated by the receipt of an authenticated message that closes the connection (e.g., a DTLS fatal alert). If the server has lost state, a DTLS handshake needs to be initiated with the server. For the server, to mitigate the risk of unintentional server overload, it is RECOMMENDED that the default DNS-over-DTLS server application-level idle time be set to several seconds and not set to less than a second, but no particular value is specified. When no DNS queries have been received from the client after idle time out, the server MUST send a DTLS fatal alert and then destroy its DTLS state. The DTLS fatal alert packet indicates the server has destroyed its state, signaling to the client if it wants to send a new DTLS message it will need to re-establish cryptographic context with the server (via full DTLS handshake or DTLS session resumption). In practice, the idle period can vary dynamically, and servers MAY allow idle connections to remain open for longer periods as resources permit.

4. Performance Considerations

DTLS protocol profile for DNS-over-DTLS is discussed in Section 11 of [I-D.ietf-dprive-dtls-and-tls-profiles]. To reduce the number of octets of the DTLS handshake, especially the size of the certificate in the ServerHello (which can be several kilobytes), DNS clients and servers can use raw public keys [RFC7250] or Cached Information Extension [RFC7924]. Cached Information Extension avoids

Reddy, et al. Expires June 19, 2017 [Page 6] Internet-Draft DNS over DTLS December 2016

transmitting the server's certificate and certificate chain if the client has cached that information from a previous TLS handshake. TLS False Start [RFC7918] can reduce round-trips by allowing the TLS second flight of messages (ChangeCipherSpec) to also contain the (encrypted) DNS query.

It is highly advantageous to avoid server-side DTLS state and reduce the number of new DTLS sessions on the server which can be done with TLS Session Resumption without server state [RFC5077]. This also eliminates a round-trip for subsequent DNS-over-DTLS queries, because with [RFC5077] the DTLS session does not need to be re-established.

Since responses within a DTLS session can arrive out of order, clients MUST match responses to outstanding queries on the same DTLS connection using the DNS Message ID. If the response contains a question section, the client MUST match the QNAME, QCLASS, and QTYPE fields. Failure by clients to properly match responses to outstanding queries can have serious consequences for interoperability ( [RFC7766], Section 7).

5. PMTU issues

Compared to normal DNS, DTLS adds at least 13 octets of header, plus cipher and authentication overhead to every query and every response. This reduces the size of the DNS payload that can be carried. DNS client and server MUST support the EDNS0 option defined in [RFC6891] so that the DNS client can indicate to the DNS server the maximum DNS response size it can reassemble and deliver in the DNS client's network stack. If the DNS client does set the EDNS0 option defined in [RFC6891] then the maximum DNS response size of 512 bytes plus DTLS overhead will be well within the Path MTU. If the Path MTU is not known, an IP MTU of 1280 bytes SHOULD be assumed. The client sets its EDNS0 value as if DTLS is not being used. The DNS server MUST ensure that the DNS response size does not exceed the Path MTU i.e. each DTLS record MUST fit within a single datagram, as required by [RFC6347]. The DNS server must consider the amount of record expansion expected by the DTLS processing when calculating the size of DNS response that fits within the path MTU. Path MTU MUST be greater than or equal to [DNS response size + DTLS overhead of 13 octets + padding size ([RFC7830]) + authentication overhead of the negotiated DTLS cipher suite + block padding (Section 4.1.1.1 of [RFC6347]]. If the DNS server's response were to exceed that calculated value, the server MUST send a response that does fit within that value and sets the TC (truncated) bit. Upon receiving a response with the TC bit set and wanting to receive the entire response, the client behaviour is governed by the current Usage profile [I-D.ietf-dprive-dtls-and-tls-profiles]. For Strict Privacy the client MUST only send a new DNS request for the same resource

Reddy, et al. Expires June 19, 2017 [Page 7] Internet-Draft DNS over DTLS December 2016

record over an encrypted transport (e.g. DNS-over-TLS [RFC7858]). Clients using Opportunistic Privacy SHOULD try for the best case (an encrypted and authenticated transport) but MAY fallback to intermediate cases and eventually the worst case scenario (clear text) in order to obtain a response.

6. Anycast

DNS servers are often configured with anycast addresses. While the network is stable, packets transmitted from a particular source to an anycast address will reach the same server that has the cryptographic context from the DNS-over-DTLS handshake. But when the network configuration or routing changes, a DNS-over-DTLS packet can be received by a server that does not have the necessary cryptographic context. Clients using DNS-over-DTLS need to always be prepared to re-initiate DTLS handshake and in the worst case this could even happen immediately after re-initiating a new handshake. To encourage the client to initiate a new DTLS handshake, DNS servers SHOULD generate a DTLS fatal alert message in response to receiving a DTLS packet for which the server does not have any cryptographic context. Upon receipt of an un-authenicated DTLS fatal alert, the DTLS client validates the fatal alert is within the replay window (Section 4.1.2.6 of [RFC6347]). It is difficult for the DTLS client to validate that the DTLS fatal alert was generated by the DTLS server in response to a request or was generated by an on- or off- path attacker. Thus, upon receipt of an in-window DTLS fatal alert, the client SHOULD continue re-transmitting the DTLS packet (in the event the fatal alert was spoofed), and at the same time it SHOULD initiate DTLS session resumption. When the DTLS client receives an authenticated DNS response from one of those DTLS sessions, the other DTLS session should be terminated.

7. Usage

Two Usage Profiles, Strict and Opportunistic are explained in [I-D.ietf-dprive-dtls-and-tls-profiles]. Using encrypted DNS messages with an authenticated server is most preferred, encrypted DNS messages with an unauthenticated server is next preferred, and plain text DNS messages is least preferred.

8. IANA Considerations

This specification uses port 853 already allocated in the IANA port number registry as defined in Section 6 of [RFC7858].

Reddy, et al. Expires June 19, 2017 [Page 8] Internet-Draft DNS over DTLS December 2016

9. Security Considerations

The interaction between a DNS client and DNS server requires Datagram Transport Layer Security (DTLS) with a ciphersuite offering confidentiality protection. The guidance given in [RFC7525] MUST be followed to avoid attacks on DTLS. The DNS client SHOULD use the TLS Certificate Status Request extension (Section 8 of [RFC6066]), commonly called "OCSP stapling" to check the revocation status of public key certificate of the DNS server. OCSP stapling, unlike OCSP [RFC6960], does not suffer from scale and privacy issues. DNS clients keeping track of servers known to support DTLS enables clients to detect downgrade attacks. To interfere with DNS-over- DTLS, an on- or off-path attacker might send an ICMP message towards the DTLS client or DTLS server. As these ICMP messages cannot be authenticated, all ICMP errors should be treated as soft errors [RFC1122]. If the DNS query was sent over DTLS then the corresponding DNS response MUST only be accepted if it is received over the same DTLS connection. This behavior mitigates all possible attacks described in Measures for Making DNS More Resilient against Forged Answers [RFC5452]. Security considerations in [RFC6347] and [I-D.ietf-dprive-dtls-and-tls-profiles] are to be taken into account.

A malicious client might attempt to perform a high number of DTLS handshakes with a server. As the clients are not uniquely identified by the protocol and can be obfuscated with IPv4 address sharing and with IPv6 temporary addresses, a server needs to mitigate the impact of such an attack. Such mitigation might involve rate limiting handshakes from a certain subnet or more advanced DoS/DDoS techniques beyond the scope of this paper.

10. Acknowledgements

Thanks to Phil Hedrick for his review comments on TCP and to Josh Littlefield for pointing out DNS-over-DTLS load on busy servers (most notably root servers). The authors would like to thank Simon Josefsson, Daniel Kahn Gillmor, Bob Harold, Ilari Liusvaara, Sara Dickinson, Christian Huitema, Stephane Bortzmeyer, Alexander Mayrhofer, Allison Mankin, Jouni Korhonen, Stephen Farrell, Mirja Kuehlewind, Benoit Claise and Geoff Huston for discussions and comments on the design of DNS-over-DTLS. The authors would like to give special thanks to Sara Dickinson for her help.

11. References

Reddy, et al. Expires June 19, 2017 [Page 9] Internet-Draft DNS over DTLS December 2016

11.1. Normative References

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, .

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, .

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, .

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, .

[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, .

[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, DOI 10.17487/RFC5452, January 2009, .

[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, .

[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, DOI 10.17487/RFC6520, February 2012, .

[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, .

Reddy, et al. Expires June 19, 2017 [Page 10] Internet-Draft DNS over DTLS December 2016

[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, DOI 10.17487/RFC7830, May 2016, .

11.2. Informative References

[I-D.ietf-dprive-dtls-and-tls-profiles] Dickinson, S., Gillmor, D., and T. Reddy, "Authentication and (D)TLS Profile for DNS-over-(D)TLS", draft-ietf- dprive-dtls-and-tls-profiles-07 (work in progress), October 2016.

[I-D.rescorla-tls-dtls13] Rescorla, E. and H. Tschofenig, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", draft- rescorla-tls-dtls13-00 (work in progress), October 2016.

[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, .

[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, .

[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, .

[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, .

Reddy, et al. Expires June 19, 2017 [Page 11] Internet-Draft DNS over DTLS December 2016

[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, .

[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, .

[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, .

[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, .

[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, .

[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", RFC 7918, DOI 10.17487/RFC7918, August 2016, .

[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016, .

Authors' Addresses

Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India

Email: [email protected]

Reddy, et al. Expires June 19, 2017 [Page 12] Internet-Draft DNS over DTLS December 2016

Dan Wing

Email: [email protected]

Prashanth Patil Cisco Systems, Inc. Bangalore India

Email: [email protected]

Reddy, et al. Expires June 19, 2017 [Page 13] Network Working Group Z. Hu Internet-Draft L. Zhu Intended status: Standards Track J. Heidemann Expires: January 6, 2016 USC/Information Sciences Institute A. Mankin D. Wessels Verisign Labs P. Hoffman ICANN July 5, 2015

TLS for DNS: Initiation and Performance Considerations draft-ietf-dprive-start-tls-for-dns-01

Abstract

This document offers an approach to initiating TLS for DNS: use of a dedicated DNS-over-TLS port, and fallback to a mechanism for upgrading a DNS-over-TCP connection over the standard port (TCP/53) to a DNS-over-TLS connection. Encryption provided by TLS eliminates opportunities for eavesdropping on DNS queries in the network, such as discussed in RFC 7258. In addition it specifies two usage profiles for DNS-over-TLS. Finally, it provides advice on performance considerations to minimize overheads from using TCP and TLS with DNS, pertaining to both approaches.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

This Internet-Draft will expire on January 6, 2016.

Hu, et al. Expires January 6, 2016 [Page 1] Internet-Draft TLS for DNS July 2015

Table of Contents

1. Introduction ...... 3 1.1. Reserved Words ...... 4 2. Protocol Changes ...... 4 2.1. Use by DNS Clients ...... 5 2.1.1. Port-Based DNS-over-TLS for Clients ...... 5 2.1.2. Sending Queries for Upgrade-Based DNS-over-TLS . . . . 5 2.1.3. Receiving Responses for Upgrade-Based DNS-over-TLS . . 5 2.1.4. Use by DNS Servers ...... 6 2.1.5. Established Sessions ...... 7 2.2. Downgrade Attacks and Middleboxes ...... 8 3. Usage Profiles ...... 9 3.1. Opportunistic Privacy Profile ...... 9 3.2. Pre-Deployed Profile ...... 9 4. Performance Considerations ...... 10 5. IANA Considerations ...... 11 6. Implementation Status ...... 11 6.1. Unbound ...... 12 6.2. ldns ...... 12 6.3. digit ...... 12 6.4. getdns ...... 12 7. Security Considerations ...... 12 8. Acknowledgments ...... 13 9. References ...... 14 9.1. Normative References ...... 14 9.2. Informative References ...... 14 Authors' Addresses ...... 17

Hu, et al. Expires January 6, 2016 [Page 2] Internet-Draft TLS for DNS July 2015

1. Introduction

Today, nearly all DNS queries ([RFC1034] and [RFC1035]) are sent unencrypted, which makes them vulnerable to eavesdropping by an attacker that has access to the network channel, reducing the privacy of the querier. Recent news reports have elevated these concerns, and ongoing efforts are beginning to identify privacy concerns about DNS ([I-D.ietf-dprive-problem-statement]).

Prior work has addressed some aspects of DNS security, but until recently there has been little work on privacy between a DNS client and server. DNS Security Extensions (DNSSEC, [RFC4033]) provide _response integrity_ by defining mechanisms to cryptographically sign zones, allowing end-users (or their first-hop resolver) to verify replies are correct. By intention, DNSSEC does not protect request and response privacy. Traditionally, either privacy was not considered a requirement for DNS traffic, or it was assumed that network traffic was sufficiently private, however these perceptions are evolving due to recent events [RFC7258].

DNSCurve [draft-dempsky-dnscurve] defines a method to add confidentiality to the link between DNS clients and servers; however, it does so with a new cryptographic protocol and does not take advantage of an existing standard protocol such as TLS. ConfidentialDNS [draft-wijngaards-confidentialdns] and IPSECA [draft-osterweil-dane-ipsec] use opportunistic encryption to offer privacy for DNS queries and responses. Finally, others have suggested DNS-over-TLS. Unbound DNS software [unbound] includes a DNS-over-TLS implementation. The present document goes beyond past DNS-over-TLS discussions by providing two modes of initiation for DNS-over-TLS: use of a well-known port, and use of a negotiation mechanism in an established connection.

Protocol changes proposed here must consider potential interactions with middle boxes. The port-based initiation of TLS is very straightforward, but might be blocked by firewalls or be unwelcome to some DNS client or server implementations. If port-based initiation of TLS fails, the negotiation mechanism allows DNS clients and servers to upgrade an existing DNS-over-TCP connection to a DNS-over- TLS connection, analogous to upgrade mechanisms in other uses of TLS, such as STARTTLS [RFC2595] used in SMTP [RFC3207], IMAP [RFC3501] and POP [RFC1939], to name just a few of many. Adding TLS to DNS-over- TCP avoids port blocking, but maybe interact poorly with middle boxes that inspect DNS traffic. As is generally the case with TLS, both approaches are subject to downgrade attacks, as discussed in Section 2.2.

The protocol described here works for any DNS client to server

Hu, et al. Expires January 6, 2016 [Page 3] Internet-Draft TLS for DNS July 2015

communication using DNS-over-TCP. There can be different profiles providing different levels of privacy, as discussed in Section 3. The protocol may be used for any DNS communication both from stub to recursive, and from recursive to authoritative servers, but different protocols may be preferable for different environments.

This document describes two profiles Section 3 providing different levels of assurance of privacy: an opportunistic privacy profile and a pre-deployed profile.

1.1. Reserved Words

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

2. Protocol Changes

The only changes required for port-based DNS-over-TLS are those optimizing TCP and TLS performance discussed in the following. The DNS protocol itself is unchanged.

DISCUSSION: Draft authors seek input from the working group regarding the need for both port- and upgrade-based approaches. Removing the upgrade-based technique would simplify this document and implementations. However, there may perhaps be situations where the upgrade-based technique works (over port 53) that a port-based technique would not work (i.e., due to aggressive port blocking by firewalls).

Clients and servers negotiate upgrade-based DNS-over-TLS by setting a bit in the Flags field of the EDNS0 [RFC6891] OPT meta-RR. The "TLS OK" (TO) bit is defined as the second bit of the third and fourth bytes of the "extended RCODE and flags" portion of the EDNS0 OPT meta-RR, immediately adjacent to the "DNSSEC OK" (DO) bit [RFC4033]:

+0 (MSB) +1 (LSB) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0: | EXTENDED-RCODE | VERSION | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2: |DO|TO| Z | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Hu, et al. Expires January 6, 2016 [Page 4] Internet-Draft TLS for DNS July 2015

2.1. Use by DNS Clients

DNS clients first try port-based DNS-over-TLS. If that connection fails, they try upgrade-based DNS-over-TLS.

2.1.1. Port-Based DNS-over-TLS for Clients

DNS clients SHOULD first try using port-based DNS-over-TLS by establishing the TCP connection to the dedicated port TBD (number to be defined in Section 5). Clients MAY try STARTTLS upgrade before the dedicated port if there is information that this ordering is preferred. It SHOULD be an implementation and/or local determination as to whether to attempt TLS via the dedicated port first and then fall back to STARTTLS use, or to choose some other order of attempts and fallbacks.

2.1.2. Sending Queries for Upgrade-Based DNS-over-TLS

Setting the TO bit in queries sent using UDP transport has no protocol meaning. However, the client MAY set the TO bit when using UDP transport. The server MUST ignore the TO bit when receiving UDP transport.

DNS clients set the TO bit in the initial query sent to a server using TCP transport to signal their desire that the TCP connection be upgraded to TLS. DNS clients SHOULD NOT set the TO bit on queries when using TLS transport because doing so has no meaning in this protocol.

Since the motivation for upgrade-based DNS-over-TLS is to preserve privacy, DNS clients SHOULD use an initial (unprotected) query that reveals no private information in the initial TO=1 query to a server. To provide a standard "dummy" query, it is RECOMMENDED to send the initial query with RD=0, QNAME="STARTTLS", QCLASS=CH, and QTYPE=TXT ("STARTTLS/CH/TXT") analogous to administrative queries already in widespread use [RFC4892]. (For some profiles, the client MUST use a dummy query for the initial query.)

After sending the initial TO=1 query using TCP transport, DNS clients MUST wait for the initial response before sending any subsequent queries over the same TCP connection.

2.1.3. Receiving Responses for Upgrade-Based DNS-over-TLS

A DNS client that receives a response using UDP transport that has the TO bit set handles that response as usual. It MAY record the server's support for DNS-over-TLS and use that information as part of its server selection algorithm in the case where multiple servers are

Hu, et al. Expires January 6, 2016 [Page 5] Internet-Draft TLS for DNS July 2015

available to service a particular query.

A DNS client that receives a response to its initial query using TCP transport that has the TO bit clear MUST NOT initiate a TLS handshake and MAY utilize the existing TCP connection for subsequent (unencrypted) queries. DNS clients SHOULD remember server IP addresses that don't support upgrade-based DNS-over-TLS, including TLS handshake failures, and not request DNS-over-TLS from them for a reasonable period (such as one hour per server).

A DNS client that has sent the TO bit using TCP transport and receives a response to its initial query that has the TO bit set MUST immediately initiate a TLS handshake using the procedure described in [RFC5246]. If the TLS handshake does not succeed, the client MUST close the connection and treat the server as described above for future queries.

2.1.4. Use by DNS Servers

A DNS server that supports DNS-over-TLS SHOULD support port-based DNS-over-TLS, and SHOULD support upgrade-based DNS-over-TLS.

2.1.4.1. Receiving Queries for Upgrade-Based DNS-over-TLS

A DNS server receiving a query over UDP with the TO bit ignores that bit. A DNS server receiving a query over an existing TLS connection with the TO bit ignores that bit.

A DNS server receiving an initial query over TCP that has the TO bit set MAY inform the client it is willing to establish a TLS session, as described in the next section.

A DNS server receiving subsequent queries over TCP MUST ignore the TO bit. (A client wishing to start TLS after the initial query MUST open a new TCP connection to do so.)

2.1.4.2. Sending Responses

A DNS server sending a response over UDP to a query that had an OPT meta-RR SHOULD set the TO bit to indicate its general support for DNS-over-TLS, as long as it is willing and able to support a TLS connection with the particular client.

A DNS server receiving an initial query over TCP that has the TO bit set MAY set the TO bit in its response. The server MUST then proceed with the TLS handshake protocol.

A DNS server receiving a "dummy" STARTTLS/CH/TXT query over TCP MUST

Hu, et al. Expires January 6, 2016 [Page 6] Internet-Draft TLS for DNS July 2015

respond with RCODE=0 and a TXT RR in the Answer section. Contents of the TXT RR are strictly informative (for humans) and MUST NOT be interpreted by the client software. Recommended TXT RDATA values are "STARTTLS" or "NO_TLS".

2.1.5. Established Sessions

After TLS negotiation completes, the connection will be encrypted and is now protected from eavesdropping and normal DNS queries SHOULD take place, following DNS-over-TCP framing ([RFC1035], section 4.2.2). For reasons of efficiency, DNS clients and servers SHOULD transmit the two-octet length field, and the message described by that length field, in a single TCP segment ([I-D.ietf-dnsop-5966bis], section 8).

For DNS clients that use library functions such as "gethostbyname()", current implementations are known to open and close UDP connections each DNS call. To avoid many TCP connections, each with a single query, clients SHOULD reuse a single TCP connection to the recursive resolver. Alternatively they may prefer to use UDP to a DNS-over-TLS enabled caching resolver on the same machine that then uses a system- wide TCP connection to the recursive resolver.

In order to amortize TCP and TLS connetion setup costs, clients and servers SHOULD NOT immediately close a connection after each response. Instead, clients and servers SHOULD reuse existing connections for subsequent queries as long as they have sufficient resources. In some cases, this means that clients and servers may need to keep idle connections open for some amount of time.

Proper management of established and idle connections is important to the healthy operation of a DNS server. An implementor of DNS-over- TLS SHOULD follow best practices for DNS-over-TCP, as described in [I-D.ietf-dnsop-5966bis]. Failure to do so may lead to resource exhaustion and denial-of-service.

Whereas client and server implementations from the [RFC1035] era are known to have poor TCP connection management, this document stipulates that successful negotation of TLS indicates the willingness of both parties to keep idle DNS connections open, independent of timeouts or other recommendations for DNS-over-TCP without TLS. In other words, software implemeting this protocol is assumed to support idle, persistent connections and to have good connection management.

This document does not make specific recommendations for timeout values on idle connections. Clients and servers should reuse and/or close connections depending on the level of available resources.

Hu, et al. Expires January 6, 2016 [Page 7] Internet-Draft TLS for DNS July 2015

Timeouts may be longer during periods of low activity and shorter during periods of high activity. Current work in this area may also assist DNS-over-TLS clients and servers select useful timeout values [draft-wouters-edns-tcp-keepalive] [tdns].

Clients and servers that keep idle connections open MUST be robust to termination of idle connection by either party. As with current DNS- over-TCP, DNS servers MAY close the connection at any time (e.g., due to resource constraints). As with current DNS-over-TCP, clients MUST handle abrupt closes and be prepared to reestablish connections and/or retry queries.

When closing a connection, DNS servers SHOULD use the TLS close- notify request to shift TCP TIME-WAIT state to the clients. Additional requirements and guidance for optimizing DNS-over-TCP are provided by [RFC5966], [I-D.ietf-dnsop-5966bis]. As discussed in [I-D.ietf-dnsop-5966bis], TCP Fast Open [RFC7413] is of benefit.

2.2. Downgrade Attacks and Middleboxes

Middleboxes [RFC3234] may be present in some networks and have been known to interfere with normal DNS resolution and create problems for DNS-over-TLS. Remarkably, downgrade attacks can affect plaintext protocols that utilize "STARTTLS" signaling in a similar way. A DNS client attempting upgrade-based DNS-over-TLS through a middlebox, or in the presence of a downgrade attack, could have one of the following outcomes. (These outcomes are similar to those discussed in prior RFCs, such as [RFC3207].)

o The DNS client sends a TO=1 query and receives a TO=0 response. In this case there is no upgrade to TLS and DNS resolution occurs normally, without encryption.

o The DNS client sends a TO=1 query and receives a TO=1 response, but the middlebox does not understand the TLS negotiation and does not allow the TLS handshake packets to pass. Clients SHOULD retry DNS without TO set if negotiation fails, and then retry with TLS after a reasonable period (see Section 2.1.3).

o The DNS client sends a TO=1 query but receives no response at all. The middlebox might be silently dropping the query due to the presence of the TO bit, when it should, in fact, ignore and pass through unknown flag bits [RFC6891]. The client SHOULD fall back to normal (unencrypted) DNS for a reasonable period (as discussed in Section 2.1.3).

In general, clients that attempt TLS and fail can either fall back on unencrypted DNS, or wait and retry later, depending on their privacy

Hu, et al. Expires January 6, 2016 [Page 8] Internet-Draft TLS for DNS July 2015

requirements.

3. Usage Profiles

This protocol provides flexibility to accommodate several different use cases. Two usage profiles are defined here to identify specific design points in performance and privacy. Other profiles are possible but are outside the scope of this document.

3.1. Opportunistic Privacy Profile

For opportunistic privacy, analogous to SMTP opportunistic encryption [RFC7435] one desires privacy when possible, but does not require it.

With opportunistic privacy, a client might acquire a recursive DNS resolver from an untrusted source (such as DHCP while roaming), it might or might not validate the TLS certificate, and it might not use a dummy value for the initial query. These choices maximize availability and performance, but they are vulnerable to on-path attacks.

Opportunistic privacy can be used by any current client, but it only provides privacy when there are no on-path active attackers.

3.2. Pre-Deployed Profile

For pre-deployed privacy, the DNS client has one or more trusted recursive DNS providers. This profile provides strong privacy guarantees to the user.

With pre-deployed privacy, a client retains a copy of the TLS certificate (and/or other authentication credentials as appropriate) and IP address of each provider. The client will only use one of those DNS providers. Because it has a pre-deployed TLS certificate, it may detect person-in-the-middle and downgrade attacks.

With pre-deployed privacy, the DNS client MUST signal to the user when none of the designated DNS servers are available, and MUST NOT provide DNS service until one of the designated DNS servers becomes available.

The designated DNS provider may be temporarily unavailable when configuring a network. For example, for clients on networks that require authentication through web-based login, such authentication may require DNS interception and spoofing. Techniques such as those used by DNSSEC-trigger [dnssec-trigger] MAY be used during network configuration, with the intent to transition to the designated DNS

Hu, et al. Expires January 6, 2016 [Page 9] Internet-Draft TLS for DNS July 2015

provider after authentication. The user MUST be alerted that the DNS is not private during such bootstrap.

Methods for pre-deployment of the designated DNS provider are outside the scope of this document. In corporate settings, such information may be provided at system installation. Use of multiple public DNS providers suggests that end users are able to configure DNS by hand.

4. Performance Considerations

DNS-over-TLS incurs additional latency at session startup. It also requires additional state (memory) and increased processing (CPU).

1. Latency: Compared to UDP, DNS-over-TCP requires an additional round-trip-time (RTT) of latency to establish the connection. The TLS handshake adds another two RTTs of latency. Clients and servers should support connection keepalive (reuse) and out-of- order processing to amortize connection setup costs. Moreover, TLS connection resumption can further reduce the setup delay. DNS servers SHOULD enable fast TLS session resumption [RFC5077] to avoid keeping per-client session state. TLS False Start [draft-tls-falsestart] can also lead to a latency reduction in certain situations.

2. State: The use of connection-oriented TCP requires keeping additional state in both kernels and applications. TLS has marginal increases in state over TCP alone. The state requirements are of particular concerns on servers with many clients. Smaller timeout values will reduce the number of concurrent connections, and servers can preemptively close connections when resources limits are exceeded.

3. Processing: Use of TLS encryption algorithms results in slightly higher CPU usage. Servers can choose to refuse new DNS-over-TCP clients if processing limits are exceeded.

4. Number of connections: To minimize state on DNS servers and connection startup time, clients SHOULD minimize creation of new TCP connections. Use of a local DNS request aggregator (a particular type of forwarder) allows a single active DNS-over-TLS connection from any given client computer to its server. Additional guidance can be found in [I-D.ietf-dnsop-5966bis].

A full performance evaluation is outside the scope of this specification. A more detailed analysis of the performance implications of DNS-over-TLS (and DNS-over-TCP) is discussed in a technical report [tdns] and [I-D.ietf-dnsop-5966bis].

Hu, et al. Expires January 6, 2016 [Page 10] Internet-Draft TLS for DNS July 2015

5. IANA Considerations

This document defines a new bit ("TO") in the Flags field of the EDNS0 OPT meta-RR. At the time of approval of this draft in the standards track, as per the IANA Considerations of RFC 6891, IANA is requested to reserve the second leftmost bit of the flags as the TO bit, immediately adjacent to the DNSSEC DO bit, as shown in Section 2.

IANA is requested add the following value to the "Service Name and Transport Protocol Port Number Registry" registry. That registry is populated by expert review [RFC6335], and such a review will be requested if this document progresses.

Service Name DNS-over-TLS Transport Protocol(s) TCP Assignee IESG Contact TBD Description DNS query-response protocol run over TLS Reference This document

6. Implementation Status

[Note to RFC Editor: please remove this section and reference to RFC 6982 prior to publication.]

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 6982. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.

According to RFC 6982, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

Hu, et al. Expires January 6, 2016 [Page 11] Internet-Draft TLS for DNS July 2015

6.1. Unbound

The Unbound recursive name server software added support for port- based DNS-over-TLS in version 1.4.14. The unbound.conf configuration file has the following configuration directives: ssl-port, ssl- service-key, ssl-service-pem, ssl-upstream. See https://unbound.net/documentation/unbound.conf.html.

Sinodun Internet Technologies has implemented upgrade-based DNS-over- TLS in Unbound-1.5.1 (patch available at https://portal.sinodun.com/ stash/projects/TDNS/repos/dns-over-tls_patches/browse) for both stub- to-recursive and recursive-to-authoritative.

6.2. ldns

Sinodun Internet Technologies has implemented both upgrade-based and port-based DNS-over-TLS in the ldns library from NLnetLabs. This also gives DNS-over-TLS support to the drill DNS client program. Patches available at https://portal.sinodun.com/stash/projects/TDNS/ repos/dns-over-tls_patches/browse.

6.3. digit

The digit DNS client from USC/ISI supports both port- and upgrade- based DNS-over-TLS. Source code available at http://www.isi.edu/ant/software/tdns/index.html.

6.4. getdns

The getdns API implementation supports both port- and upgrade-based DNS-over-TLS. Upgrade-based operation requires linking getdns with a patched version of libunbound. Source code available at https://getdnsapi.net.

7. Security Considerations

Use of TLS for DNS addresses is designed to address the privacy risks arise because DNS queries may be eavesdropped upon. It does not address other security issues in DNS, and there are a number of residual risks that may affect its success at protecting privacy:

1. There are known attacks on TLS, such as person-in-the-middle and protocol downgrade. These are general attacks on TLS and not specific to DNS-over-TLS; please refer to the TLS RFCs for discussion of these security issues.

Hu, et al. Expires January 6, 2016 [Page 12] Internet-Draft TLS for DNS July 2015

2. Any protocol interactions prior to the TLS handshake are performed in the clear and can be modified by a man-in-the-middle attacker. For this reason, clients MAY discard cached information about server capabilities advertised prior to the start of the TLS handshake.

3. As with other uses of STARTTLS-upgrade to TLS, the mechanism specified here is susceptible to downgrade attacks, where a person-in-the-middle prevents a successful TLS upgrade. Keeping track of servers known to support TLS (i.e., "pinning") enables clients to detect downgrade attacks. For servers with no connection history, clients may choose to refuse non-TLS DNS, or they may continue without TLS, depending on their privacy requirements.

4. This document does not propose new ideas to provide resistance to known traffic analysis techniques. Even with encrypted messages, a well-positioned party may be able to glean certain details from an analysis of message timings and sizes.

5. This document does not propose new ideas for certificate authentication for TLS in the context of DNS. Several external methods are possible, although each has weaknesses. The current Certificate Authority infrastructure [RFC5280] is used by HTTP/ TLS [RFC2818]. With many trusted CAs, this approach has recognized weaknesses [CA_Compromise]. Some work is underway to partially address these concerns (for example, with certificate pinning [certificate_pinning], but more work is needed. DANE [RFC6698] provides mechanisms to root certificate trust with DNSSEC. That use here must be carefully evaluated to address potential issues in trust recursion. For stub-to-recursive resolver use, certificate authentication is sometimes either easy or nearly impossible. If the recursive resolver is manually configured, its certificate can be authenticated when it is configured. If the recursive resolver is automatically configured (such as with DHCP [RFC2131]), it could use DHCP authentication mechanisms [RFC3118]).

Ongoing discussion and development of opportunistic TLS (connections without CA validation, [RFC7435]) may be relevant to DNS-over-TLS.

8. Acknowledgments

The authors would like to thank Stephane Bortzmeyer, Brian Haberman, Kim-Minh Kaplan, Bill Manning, George Michaelson, Eric Osterweil, Glen Wiley, John Dickinson, Sara Dickinson, and Daniel Kahn Gillmor for reviewing this Internet-draft, and Nikita Somaiya for early work

Hu, et al. Expires January 6, 2016 [Page 13] Internet-Draft TLS for DNS July 2015

on this idea.

Work by Zi Hu, Liang Zhu, and John Heidemann in this paper is partially sponsored by the U.S. Dept. of Homeland Security (DHS) Science and Technology Directorate, HSARPA, Cyber Security Division, BAA 11-01-RIKA and Air Force Research Laboratory, Information Directorate under agreement number FA8750-12-2-0344, and contract number D08PC75599.

9. References

9.1. Normative References

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC5966] Bellis, R., "DNS Transport over TCP - Implementation Requirements", RFC 5966, August 2010.

[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.

9.2. Informative References

[CA_Compromise] Infosec Island Admin, "CA Compromise", January 2012,

Hu, et al. Expires January 6, 2016 [Page 14] Internet-Draft TLS for DNS July 2015

Fix.html>.

[I-D.ietf-dnsop-5966bis] Dickinson, J., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", draft-ietf-dnsop-5966bis-01 (work in progress), December 2014.

[I-D.ietf-dprive-problem-statement] Bortzmeyer, S., "DNS privacy considerations", draft-ietf-dprive-problem-statement-06 (work in progress), October 2014.

[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.

[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.

[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.

[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.

[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.

[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.

[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.

[RFC4892] Woolf, S. and D. Conrad, "Requirements for a Mechanism Identifying a Name Server Instance", RFC 4892, June 2007.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.

Hu, et al. Expires January 6, 2016 [Page 15] Internet-Draft TLS for DNS July 2015

[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012.

[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014.

[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, December 2014.

[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, December 2014.

[certificate_pinning] OWASP, "Certificate and Public Key Pinning", 2014, .

[dnssec-trigger] NLnet Labs, "Dnssec-Trigger", May 2014, .

[draft-dempsky-dnscurve] Dempsky, M., "DNSCurve", draft-dempsky-dnscurve-01 (work in progress), August 2010, .

[draft-osterweil-dane-ipsec] Osterweil, E., Wiley, G., Mitchell, D., and A. Newton, "Opportunistic Encryption with DANE Semantics and IPsec: IPSECA", draft-osterweil-dane-ipsec-00 (work in progress), February 2014, .

[draft-tls-falsestart] Moeller, B. and A. Langley, "Transport Layer Security (TLS) False Start", draft-bmoeller-tls-falsestart-01 (work in progress), November 2014, .

[draft-wijngaards-confidentialdns] Wijngaards, W., "Confidential DNS", draft-wijngaards-dnsop-confidentialdns-03 (work in progress), November 2013, .

[draft-wouters-edns-tcp-keepalive]

Hu, et al. Expires January 6, 2016 [Page 16] Internet-Draft TLS for DNS July 2015

Wouters, P. and J. Abley, "The edns-tcp-keepalive EDNS0 Option", draft-wouters-edns-tcp-keepalive-00 (work in progress), October 2013, .

[tdns] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A., and N. Somaiya, "T-DNS: Connection-Oriented DNS to Improve Privacy and Security", Technical report ISI-TR-688, February 2014, .

[unbound] NLnet Labs, Verisign labs, "Unbound", December 2013, .

Authors' Addresses

Zi Hu USC/Information Sciences Institute 4676 Admiralty Way, Suite 1133 Marina del Rey, CA 90292 USA

Phone: +1 213 587-1057 Email: [email protected]

Liang Zhu USC/Information Sciences Institute 4676 Admiralty Way, Suite 1133 Marina del Rey, CA 90292 USA

Phone: +1 310 448-8323 Email: [email protected]

John Heidemann USC/Information Sciences Institute 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292 USA

Phone: +1 310 822-1511 Email: [email protected]

Hu, et al. Expires January 6, 2016 [Page 17] Internet-Draft TLS for DNS July 2015

Allison Mankin Verisign Labs 12061 Bluemont Way Reston, VA 20190

Phone: +1 703 948-3200 Email: [email protected]

Duane Wessels Verisign Labs 12061 Bluemont Way Reston, VA 20190

Phone: +1 703 948-3200 Email: [email protected]

Paul Hoffman ICANN

Email: [email protected]

Hu, et al. Expires January 6, 2016 [Page 18]