Encryption and authentication of the DNS resolver-to-authoritative communication
draft-bortzmeyer-dprive-resolver-to-auth-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2018-01-02
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
DNS Privacy (dprive) Working Group                         S. Bortzmeyer
Internet-Draft                                                     AFNIC
Intended status: Standards Track                         January 1, 2018
Expires: July 5, 2018

   Encryption and authentication of the DNS resolver-to-authoritative
                             communication
              draft-bortzmeyer-dprive-resolver-to-auth-00

Abstract

   This document proposes a mechanism for securing (privacy-wise) the
   communication between the DNS resolver and the authoritative name
   server.

   REMOVE BEFORE PUBLICATION: this document should be discussed in the
   IETF DPRIVE group, through its mailing list.  The source of the
   document, as well as a list of open issues, is currently kept at
   Github [1].

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 https://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 July 5, 2018.

Copyright Notice

   Copyright (c) 2018 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
   (https://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

Bortzmeyer                Expires July 5, 2018                  [Page 1]
Internet-Draft      DPRIVE resolver to authoritative        January 2018

   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 and background . . . . . . . . . . . . . . . . .   2
   2.  Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Operational considerations  . . . . . . . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   6
     6.3.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .   7
   Appendix B.  Alternatives . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction and background

   To improve the privacy of the DNS user ([RFC7626]), the standard
   solution is to encrypt the requests with TLS ([RFC7858]).  We use
   this DNS-over-TLS solution as well here, since it is standardized,
   already implemented in many programs, and relies on a well-know
   security protocol (inventing a new security protocol is quite
   dangerous).  But just encrypting, without authenticating the remote
   server, leaves the user's privacy vulnerable to active man-in-the-
   middle attacks.  [RFC7858] and
   [I-D.ietf-dprive-dtls-and-tls-profiles] describe how to authenticate
   the DNS resolver, in the stub-to-resolver link.  We describe here
   authentication of the authoritative name server, in the resolver-to-
   authoritative link.

   A stub DNS resolver has only a few resolvers, and there is typically
   a pre-existing relationship.  But a resolver speaks to many
   authoritative name servers, without any prior relationship.  This
   means that, for instance, having a static key for the resolver makes
   sense while it would be clearly unrealistic for the authoritative
   server.

   Instead, we rely on DANE ([RFC6698]).  Authoritative name servers are
   known by name (obtained from zone delegation).  The manager of the
   ns1.example.net name server adds a TLSA record under example.net.
   The client establishes the TLS session, then authentify in the normal
   DANE way.

Bortzmeyer                Expires July 5, 2018                  [Page 2]
Internet-Draft      DPRIVE resolver to authoritative        January 2018

   The original charter of the DPRIVE working group, in force at the
   time of this draft, says "The primary focus of this Working Group is
   to develop mechanisms that provide confidentiality between DNS
Show full document text