Using TLS for Privacy Between DNS Stub and Recursive Resolvers
draft-hoffman-dns-tls-stub-00

Network Working Group                                         P. Hoffman
Internet-Draft                                            VPN Consortium
Intended status: Standards Track                         August 18, 2014
Expires: February 19, 2015

     Using TLS for Privacy Between DNS Stub and Recursive Resolvers
                   draft-hoffman-dns-tls-stub-00

Abstract

   DNS queries and responses can contain information that reveals
   important information about the person who caused the queries, and it
   would be better if eavesdroppers were unable to see DNS traffic.
   This document describes how to use TLS for encrypting DNS traffic
   between a system acting as a DNS stub resolver and a system acting as
   a DNS recursive resolver.

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 February 19, 2015.

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

Hoffman                 Expires February 19, 2015               [Page 1]
Internet-Draft              DNS TLS for Stubs                August 2014

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Specification of Using TLS Between a Stub Resolver and a
       Recursive Resolver  . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Stub Resolver Policy  . . . . . . . . . . . . . . . . . .   4
     2.2.  Privacy Through DNS Forwarders  . . . . . . . . . . . . .   4
     2.3.  Use by Authoritative Servers  . . . . . . . . . . . . . .   4
   3.  Design Rationale  . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   As described in [I-D.bortzmeyer-dnsop-dns-privacy], there are many
   reasons why a user or system making a DNS query would like the query
   and the response to not be seen by others.  The best way to make a
   query and response private is to use encryption, and TLS is a
   commonly-deployed protocol that provides encryption to clients and
   servers.  This document describes how to use TLS for encrypting DNS
   traffic between a system acting as a stub resolver and a system
   acting as a recursive resolver.

   Because there is currently no expectation of privacy for DNS queries,
   this document defines the use of opportunistic security as described
   in [I-D.dukhovni-opportunistic-security] for adding privacy for DNS
   traffic between a stub resolver and a recursive resolver.

   The protocol described in this document cannot be used by a stub
   resolver to trust the DNSSEC validation status of responses from a
   recursive server.  Such trust might be described in a different
   protocol that always uses authenticated TLS, but not the one here.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED, "MAY", and

Hoffman                 Expires February 19, 2015               [Page 2]
Internet-Draft              DNS TLS for Stubs                August 2014

   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119, BCP 14 [RFC2119].

   The roles of agents that make DNS requests, and those that give DNS
   responses have been loosely named over time.  Because this protocol
   is meant to be used between specific types of agents, they need to be
   defined here. [[ Note: if these are adequately defined in existing
   RFCs in ways that the community agrees on, it would be better to
   simply repeat those definitions. ]]

   Stub resolver:  A system that sends DNS queries with the intention of
      using the answers locally.

   Authoritative server:  A system that responds to DNS queries with
      information about zones for which it is authoritative.

   Recursive resolver:  A system that receives DNS queries and either
      responds to those queries from a local cache or sends queries to
      authoritative servers in order to get the answers to the original
      queries.  These systems are also commonly called "recursive
      servers".

   DNS forwarder:  A system receives a DNS query from a stub resolver,
      possibly changes the query, sends the resulting query to a
      recursive resolver, receives the response from the recursive
      resolver, possibly changes the response, and sends the resulting
      response to the stub resolver.  [RFC5625] does not give a specific
      definition for DNS forwarder, but describes in detail what
      features they need to support.  The protocol interfaces for DNS
      forwarders are exactly the same as those for recursive resolvers
      (for interactions with DNS stubs) and as those for stub resolvers
      (for interactions with recursive resolvers).

2.  Specification of Using TLS Between a Stub Resolver and a Recursive
    Resolver

   A stub resolver MAY attempt to communicate with a recursive resolver
   using TLS [RFC5246] over port 443.  If the recursive resolver
   responds on port 443, both the client and the server MUST use the
   ALPN [RFC7301] extension to TLS, and MUST use "dns" as the
   identification sequence in ALPN.  After the TLS connection is
   established, the client and server communicate using the normal DNS
   protocol defined in [RFC1035] and all the relevant updates.

   A recursive resolver SHOULD offer authentication using one or more of
   the many methods allowed by TLS, and the stub resolver SHOULD
   authenticate the recursive resolver if it can.  However, if the stub
   resolver cannot authenticate the recursive resolver during TLS setup,

Hoffman                 Expires February 19, 2015               [Page 3]
Internet-Draft              DNS TLS for Stubs                August 2014

   the stub resolver SHOULD still complete the handshake in order to
   achieve encrypted communication.

   A typical form of authentication for a recursive resolver would be a
   PKIX [RFC5280] certificate that has a CommonName (CN) that is the IP
   address that stub resolvers use to connect to it.  Note that there
   are many other standardized types of TLS authentication that can be
   used, such as raw public keys keys [RFC7250].

2.1.  Stub Resolver Policy

   A security-oblivious stub resolver MAY use policy to allow
   unauthenticated encryption (which can possibly be intercepted by an
   on-path adversary) or authenticated encryption (which might prevent
   all DNS resolution if the server does not have correct authentication
   credentials) when contacting a recursive resolver using this
   protocol.

2.2.  Privacy Through DNS Forwarders

   A stub resolver cannot tell whether it is sending queries to a
   recursive resolver or to a DNS forwarder.  Therefore, a DNS forwarder
   that acts as a TLS server for DNS requests MUST also act as a TLS
   client for queries to its upstream recursive resolvers.

2.3.  Use by Authoritative Servers

   There is absolutely no expectation that any authoritative server will
   deploy this protocol.  Thus, a DNS recursive resolver that tries to
   contact an authoritative server on TCP port 443 in hopes of keeping
   its communication private is probably wasting its time and delaying
   getting the actual answer over port 53.

3.  Design Rationale

   The MUST-level requirement for ALPN is because a server might host
   both DNS and secure web services on the same IP address.  ALPN was
   chosen instead of wrapping DNS in HTTP because restrictions in
   [RFC3205] make doing DNS-over-HTTP fragile, while sending DNS through
   a TLS tunnel is trivial.

   A different design is proposed in [I-D.hzhwm-start-tls-for-dns].
   There, DNS over TCP is begun on port 53 as normal, but there is an
   in-band signal to change the transport to TLS.

Hoffman                 Expires February 19, 2015               [Page 4]
Internet-Draft              DNS TLS for Stubs                August 2014

4.  Privacy Considerations

   This entire document is about improving privacy for DNS requests and
   responses.

5.  IANA Considerations

   IANA is requested add the following value to the "Application-Layer
   Protocol Negotiation (ALPN) Protocol IDs" registry.  That registry is
   populated by expert review, and such a review will be requested as
   this document progresses.

   Protocol     Identification Sequence        Reference
   DNS          0x64 0x6e 0x73 ("dns")         This document

6.  Security Considerations

   An adversary who can observe encrypted queries from stub resolvers,
   and can simultaneously observe the cleartext queries from a recursive
   resolver to authoritative servers, might be able to associate those
   two sets of queries and thus ascertain that a particular client asked
   a particular query.  Such observations can be prevented by the
   recursive resolver already having the answer in its cache.  If a
   recursive resolver has ample room in its cache, it can make the
   adversary's job harder by refreshing entries in its cache before the
   TTL on those entries time out, thereby preventing the adversary's
   ability to associate encrypted queries with cleartext ones.

7.  Acknowledgements

   Many people have thought about protecting DNS queries and responses,
   and various discussions with those people resulted in this document.

   The following have made significant contributions to this document:
   Carsten Bormann and Paul Wouters.

   The proposal in this document would not have been possible without
   the work done on ALPN and NPN (the predecessor to ALPN).

8.  References

8.1.  Normative References

   [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.

Hoffman                 Expires February 19, 2015               [Page 5]
Internet-Draft              DNS TLS for Stubs                August 2014

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

   [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
              "Transport Layer Security (TLS) Application-Layer Protocol
              Negotiation Extension", RFC 7301, July 2014.

8.2.  Informative References

   [I-D.bortzmeyer-dnsop-dns-privacy]
              Bortzmeyer, S., "DNS privacy considerations", draft-
              bortzmeyer-dnsop-dns-privacy-02 (work in progress), April
              2014.

   [I-D.dukhovni-opportunistic-security]
              Dukhovni, V., "Opportunistic Security: Some Protection
              Most of the Time", draft-dukhovni-opportunistic-
              security-03 (work in progress), August 2014.

   [I-D.hzhwm-start-tls-for-dns]
              Zi, Z., Zhu, L., Heidemann, J., Mankin, A., and D.
              Wessels, "Starting TLS over DNS", draft-hzhwm-start-tls-
              for-dns-01 (work in progress), July 2014.

   [RFC3205]  Moore, K., "On the use of HTTP as a Substrate", BCP 56,
              RFC 3205, February 2002.

   [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.

   [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines", BCP
              152, RFC 5625, August 2009.

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

Author's Address

   Paul Hoffman
   VPN Consortium

   Email: paul.hoffman@vpnc.org

Hoffman                 Expires February 19, 2015               [Page 6]