Internet Engineering Task Force (IETF) Phillip Hallam-Baker
Internet-Draft Comodo Group Inc.
Intended Status: Standards Track May 9, 2014
Expires: November 10, 2014
DNS Privacy and Censorship: Use Cases and Requirements.
draft-hallambaker-dnse-01
Abstract
This document describes use cases and requirements arising from
privacy an free speech concerns in the DNS.
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."
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Hallam-Baker November 10, 2014 [Page 1]
Internet-Draft DNS Privacy and Censorship May 2014
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Cases and Requirements . . . . . . . . . . . . . . . . . . 3
2.1. Core Use Cases . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Client/Resolver Communications . . . . . . . . . . . 5
2.1.2. Resolver/Authoritative Communications . . . . . . . 7
2.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Legacy Deployment . . . . . . . . . . . . . . . . . 7
2.2.2. Integrity Attacks . . . . . . . . . . . . . . . . . 8
2.2.3. Limited message size . . . . . . . . . . . . . . . . 8
2.2.4. Confidentiality Requirements . . . . . . . . . . . . 8
2.2.5. Integrity Requirements . . . . . . . . . . . . . . . 9
2.2.6. Access Requirements . . . . . . . . . . . . . . . . 9
3. Security Considerations . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Acnowledgementsts . . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Hallam-Baker November 10, 2014 [Page 2]
Internet-Draft DNS Privacy and Censorship May 2014
1. Introduction.
Recent events have required urgent consideration of privacy concerns
in Internet protocols. In particular the lack of confidentiality
controls in the DNS [RFC1035] protocol is of considerable concern.
This document illustrates the privacy and related concerns raised
with a set of use cases which in turn give rise to a set of
requirements.
1.1. Related Work
DNS Security (DNSSEC), [RFC4033] is an existing standard that
protects the integrity of data between a DNS authoritative server and
the party making a request. DNSSEC does not provide confidentiality
and only permits blocking of integrity checks to be detcted. Since
the only action available to the client in this circumstance is to
block access to the possibly compromized site or accept a downgrade
attack, this is not a sufficient countermeasure against a denial of
service attack.
It is anticipated that the proposals developed to address the use
cases and requirements specified in this document will compliment
rather than replace the existing mechanisms provided in DNSSEC.
1.2. Terminology
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119]
1.3. Defined Terms
[[These terms are deliberately left blank here or else we will spend
time wordsmithing the defined term definitions rather than looking at
the protocol.]
Authoritative DNS Server
Caching Recursive Resolver
DNS
DNS Client
Recursive Resolver
Stub Resolver
Hallam-Baker November 10, 2014 [Page 3]
Internet-Draft DNS Privacy and Censorship May 2014
2. Use Cases and Requirements
The immediate motivation for considering a DNS transport layer
security protocol is the desire to improve the privacy of Internet
communications by allowing encryption of DNS requests and responses.
A closely related concern that is directly affected by
2.1. Core Use Cases
The DNS is the Internet infrastructure that makes authoritative
statements about DNS names. In particular the DNS is used to support
discovery of Internet services by mapping DNS names onto IP
addresses.
In the conventional configuration, a client requiring information
from the DNS does not access DNS authoritative servers directly and
instead makes requests through a resolver. The resolver in turn
determines which requests to make to answer the query and forwards
the request to the authoritative server.
+-------------+ +-------------+ +-------------+
| Client |--->| Resolver |--->|Authoritative|
+-------------+ +-------------+ +-------------+
Due to the distributed and hierarchical nature of the DNS, answering
a DNS query typically requires queries to multiple Authoritative
servers. This process is known as Recursive Resolution of the DNS
Query. In the typical configuration the Resolver is a 'Caching
Recursive Resolver' capable of making Recursive Queries and caching
the result to answer future queries. The client is typically a 'Stub
Client' that is not capable of making recursive queries itself and
must rely on a Recursive Resolver to do this for it.
One of the major security weaknesses in the DNS infrastructure as
currently deployed is that by default most Internet enabled devices
accept DNS service from the servers offered to it by DHCP when a
connection is established. Since the DNS is a naming service and thus
a trusted service, DNS services SHOULD be trustworthy. The practice
of relying on a the 'local' DNS resolver advertised in the DHCP
connection is therefore highly unsatisfactory.
In real world circumstances this configuration is further complicated
by firewalls, NAT devices and other middleboxes. Many of which filter
or in some cases modify DNS protocol packets whether or not they are
addressed to that device.
For the purposes of considering the privacy of the DNS protocol,
there are two important protocol interactions to consider:
Hallam-Baker November 10, 2014 [Page 4]
Internet-Draft DNS Privacy and Censorship May 2014
* Communications between a Client and a Resolver
* Communications between a Resolver and an Authoritative Server
The DNS protocol supports both modes of interaction without special
provision for either case. From a security point of view, the two
interactions have different characteristics and give rise to
different use cases.
2.1.1. Client/Resolver Communications
Communications between the client and the resolver reveal a lot of
privacy sensitive information about the user. A DNS query for the
address of a controversial Web Site indicates with high probability
that a user is viewing material from the site.
In the typical configuration a DNS client makes use of the DNS
resolution server(s) advertised by DHCP when a network configuration
is established or server(s) that are configured manually by an
administrator.
In either case the relationship between the client and the resolver
is at minimum persistent for the length of time the network
association is active. In the case that the DNS service is selected
and confinugred manually, the security relationship might last for
years or the entire life of the device.
2.1.1.1. Local Resolver
For the sake of completeness, we state the case in which a client
obtains DNS service from a local DNS server advertised at the time
the network connection is established as a use case. Note however
that the privacy concerns that can be protected in such circumstances
are necessarily limited as the user has no idea where the service is
being provided from.
[U-LOCAL]: User connects to untrusted local network and wishes to use
the locally provided DNS service.
While a user may not intend to use the local DNS service, there are
many real world network configurations that attempt to impose this on
the user for a variety of reasons. In particular hotels and other
providers of local wireless Internet often make use of a 'captive DNS
resolver' to direct users to a portal for a variety of business
purposes that include limiting use of the wireless network to
particular parties.
While it is clearly impossible to provide robust privacy protections
to users who accept core network functions from random untrustworthy
sources, the ability to establish network connections in such
circumstances is essential.
Hallam-Baker November 10, 2014 [Page 5]
Internet-Draft DNS Privacy and Censorship May 2014
2.1.1.2. Selected Public Resolver
A public resolver allows users to avoid the numerous security
vulnerabilities inherent in the local resolver model. Instead of
taking trusted services from random, anonymous providers, the user
selects a particular DNS resolution provider to be used regardless of
which network is in use.
Many Public DNS resolution services are for-profit commercial
ventures. The business models supporting such services include
advertising and data-mining the DNS log file data.
[[U-PUBLIC] The user takes DNS resolution service from a selected
provider offering a public DNS resolution service.
2.1.1.3. Selected Subscriber Resolver
In an alternative business model the DNS resolution service is
visible to the public Internet but only answers requests from paying
subscribers. While such a service might not be considered
sufficiently attractive for it to be offered as a stand-alone
service, an ISP or security provider might offer a privacy enhanced
DNS as part of a more general offering.
[[U-SUBSCRIBER] The user takes DNS resolution service from a selected
provider offering the service on a subscription model of some form.
2.1.1.4. Selected Private Resolver
Most medium to large enterprises run their own DNS services as part
of their trusted network infrastructure.
Although the DNS is conceptually a single uniform namespace, many
Internet sites regard the DNS names of their internal network
machines to be secret. Protecting the secrecy of such names being one
of the principle attractions of a DNS privacy protocol to such
enterprises. this leads to the widespread use of 'split-horizon' DNS
in which different views of the DNS namespace are visible depending
on whether a machine is inside or outside the enterprise.
[U-PRIVATE] A device takes DNS resolution service from a private
service restricted to authorized use.
2.1.1.5. Hybrid Resolver
To reduce equipment costs and in response to employee demand, many
enterprises now support a Bring Your Own Device (BYOD) model in which
a device that is the property of the owner. Such a device requires
access to a private DNS service to access enterprise resources within
a hidden split-horizon DNS. But the owner might not wish their
Hallam-Baker November 10, 2014 [Page 6]
Internet-Draft DNS Privacy and Censorship May 2014
private use of the device to be visible to their employer.
[U-HYBRID] A user makes use of different DNS resolution services for
different portions of the DNS namespace.
2.1.2. Resolver/Authoritative Communications
Communications between a Resolver and an Authoritative Server can
also leak privacy sensitive data. Such leakage is mitigated at
resolvers with a large number of users and a high traffic load.
Unlike clients which typically direct DNS requests to a single
resolver or a small number of resolvers, resolvers typically interact
with a large number of authoritative servers. Some of which service a
large number of DNS domains and others service are restricted to a
publishing data for a specific enterprise.
Although these use cases are not distinguished in the DNS protocol,
the privacy implications and protocol constraints of interactions
with the two types of server are very different. Any interaction
between a resolver and an authoritative server that responds to
requests for a single domain with a single host effectively discloses
the nature of the request regardless of whether encryption is used.
At the other extreme, traffic analysis of interactions with
authoritative services serving a large number of domains revealls
much less.
[U-A-BULK] Interaction between a resolver and an authoritative server
supporting a large number of domains.
[U-A-TAIL] Interaction between a resolver and an authoritative server
supporting a small number of domains such that the interaction is
effectively disclosure of the nature of the communication.
2.2. Constraints
Any proposal to address the use cases must operate within the
constraints set by existing DNS infrastructure and administration
practices.
2.2.1. Legacy Deployment
The DNS protocol specification was first published in 1987 and has
evolved significantly over time. While the vast majority of deployed
DNS servers support modern features such as EDN(0) and DNSSEC, many
do not. Likewise, most DNS clients and servers accept messages longer
than the 500 byte minimum implementation requirement.
Regretably, while most DNS clients and servers are capable of
supporting features introduced since [RFC1035], many middle-box
devices including firewalls and residential network gateway devices
Hallam-Baker November 10, 2014 [Page 7]
Internet-Draft DNS Privacy and Censorship May 2014
do not.
2.2.2. Integrity Attacks
One of the core security vulnerabilities of the original DNS protocol
is that responses are only weakly bound to requests, thus enabling an
attack known as 'DNS-Spoofing'.
While DNSSEC is intended to provide a long term solution to the
problem of DNS spoofing, deployment of DNSSEC is currently the rare
exception rather than the rule.
2.2.3. Limited message size
One of the chief performance limitations of the DNS as currently
deployed is that most DNS servers will only accept a single request
per DNS message. Th despite support for multiple queries in a single
request in the DNS protocol,
2.2.4. Confidentiality Requirements
[R-C-PASSIVE]
Prevent or mitigate disclosure of request and response data
against a passive attacker.
[R-C-AFIRST]
Prevent or mitigate disclosure of request and response data
against an active attacker after first contact.
[R-C-ACTIVE]
Prevent or mitigate disclosure of request and response data
against an active attacker on every contact.
[R-C-LINK]
Prevent or mitigate transaction linking that would disclose
communications made in different network contexts as
originating from the same soure..
[R-C-TRAFFIC]
Prevent or mitigate disclosure from the pattern of
communications.
[R-C-PROFILE]
Protect the client against profiling by a resolver.
[R-C-AUTHOR]
Protect the confidentiality of messages against profiling by
authoritative servers.
Hallam-Baker November 10, 2014 [Page 8]
Internet-Draft DNS Privacy and Censorship May 2014
Any form of disclosure could potentially be damaging. It is not the
potential for harm but rather the likelihood of harm and the
difficulty of mounting an attack that distinguishes these
requirements in practice.
As with any security concern, confidentiality is a property of a
system and not a particular component in that system. In particular
any protocol that employs end-to-end IP transport (i.e. not via TOR)
will leak indentifiable information about the client in the source IP
address of a request. While such disclosure will inevitably limit the
degree to which a technology that is built on end-to-end IP can
protect privacy, this does not mean that the requirements such as [R-
C-LINK] should be abandoned: A careless proposal could make matters
much worse.
For example consider the case in which a protocol proposal uses a
static identifier that is never changed to specify an encryption key
to a resolver. For a static machine with a fixed IP address, such an
identifier would leak no more information than the IP address. But
used on a mobile device, the static identifier would allow a passive
observer to determine that a collection of communications to the
resolver from different IP addresses all came from the same machine.
Since the IP address effectively discloses location, such entries
would essentially disclose the travelling history of the device and
thus allow the user's travel pattern to be inferred.
2.2.5. Integrity Requirements
[R-ONESPOOF]
Prevent spoofing of DNS responses by active attack that is only
possible within a narrow window of opportunity. For example
during a one-time key exchange.
[R-QUERYSPOOF]
Prevent spoofing of DNS responses by active attack on any query
transaction.
2.2.6. Access Requirements
[R-CANON]
Support anonymous access to a DNS resolution service
[R-CAUTH]
Support authentication of the client requesting access to a DNS
resolution service
[R-AMP]
Prevent Message amplification attack
Hallam-Baker November 10, 2014 [Page 9]
Internet-Draft DNS Privacy and Censorship May 2014
[R-DDOS]
Prevent Denial of Service attack on the service
Note that [[R-CANON] and [[RCAUTH] are mutually exclusive. While it
is desirable for a solution to be capable of supporting both it is
not possible for a request to be anonymous and authenticated at the
same time by definition. The access requirement [[RCAUTH] is also
distinct from the spoofing countermeasure requirements [R-PSPOOF] and
[R-ASPOOF]. The access requirement [[RCAUTH] requires that the
service identify the source of a request. The anti-spoofing
requirements require that responses be authenticated against the
requests made.
3. Security Considerations
The use cases set out above give rise to the following requirements.
The term 'requirement' is used to refer to protocol features that
might be considered desirable without taking a position as to whether
they are necessary or desirable in practice. A proposal that is
simpler or more performant may be considered to be superior to one
that satisfies every requirement.
4. IANA Considerations
None
5. Acnowledgementsts
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4033] Arends, R.,Austein, R.,Larson, M.,Massey, D.,Rose, S.,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, 1 November 1987.
Author's Address
Phillip Hallam-Baker
Comodo Group Inc.
philliph@comodo.com
Hallam-Baker November 10, 2014 [Page 10]