Internet DRAFT - draft-hallambaker-dnse

draft-hallambaker-dnse



Internet Engineering Task Force (IETF)              Phillip Hallam-Baker
Internet-Draft                                         Comodo Group Inc.
Intended Status: Standards Track                        November 7, 2014
Expires: May 11, 2015


        DNS Privacy and Censorship: Use Cases and Requirements.
                       draft-hallambaker-dnse-02

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                  May 11, 2015                      [Page 1]

Internet-Draft         DNS Privacy and Censorship          November 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                  May 11, 2015                      [Page 2]

Internet-Draft         DNS Privacy and Censorship          November 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                  May 11, 2015                      [Page 3]

Internet-Draft         DNS Privacy and Censorship          November 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                  May 11, 2015                      [Page 4]

Internet-Draft         DNS Privacy and Censorship          November 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                  May 11, 2015                      [Page 5]

Internet-Draft         DNS Privacy and Censorship          November 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                  May 11, 2015                      [Page 6]

Internet-Draft         DNS Privacy and Censorship          November 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                  May 11, 2015                      [Page 7]

Internet-Draft         DNS Privacy and Censorship          November 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                  May 11, 2015                      [Page 8]

Internet-Draft         DNS Privacy and Censorship          November 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                  May 11, 2015                      [Page 9]

Internet-Draft         DNS Privacy and Censorship          November 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                  May 11, 2015                     [Page 10]