Skip to main content

Authenticated DNS over TLS to Authoritative Servers
draft-dickson-dprive-adot-auth-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Brian Dickson
Last updated 2021-09-17
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-dickson-dprive-adot-auth-00
Network Working Group                                         B. Dickson
Internet-Draft                                                   GoDaddy
Intended status: Informational                         16 September 2021
Expires: 20 March 2022

          Authenticated DNS over TLS to Authoritative Servers
                   draft-dickson-dprive-adot-auth-00

Abstract

   This Internet Draft proposes a mechanism for DNS resolvers to
   discover support for TLS transport to authoritative DNS servers, to
   validate this indication of support, and to authenticate the TLS
   certificates involved.

   This requires that the name server _names_ are in a DNSSEC signed
   zone.

   This also requires that the delegation of the zone served is
   protected by [I-D.dickson-dnsop-ds-hack], since the NS names are the
   keys used for discovery of TLS transport support.

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 20 March 2022.

Copyright Notice

   Copyright (c) 2021 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.

Dickson                   Expires 20 March 2022                 [Page 1]
Internet-Draft             Authenticated ADoT             September 2021

   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
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Purpose, Requirements, and Limitations  . . . . . . . . . . .   3
   5.  DNS Records To Publish for ADoT . . . . . . . . . . . . . . .   4
     5.1.  Server DNS Transport Support Signaling  . . . . . . . . .   4
       5.1.1.  Prerequisite: New SVCB Binding for DNS and DoT  . . .   5
       5.1.2.  Example . . . . . . . . . . . . . . . . . . . . . . .   5
     5.2.  DANE TLSA Records for ADoT  . . . . . . . . . . . . . . .   6
       5.2.1.  Example . . . . . . . . . . . . . . . . . . . . . . .   6
     5.3.  Signaling DNS Transport for a Name Server . . . . . . . .   6
       5.3.1.  Example . . . . . . . . . . . . . . . . . . . . . . .   7
     5.4.  Signaling DNS Transport for a Domain  . . . . . . . . . .   7
       5.4.1.  Example . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Validation Using DS Records, DNS Records, TLSA Records, and
           DNSSEC Validation . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Complete Example  . . . . . . . . . . . . . . . . . . . .   8
   7.  Signaling Support and Desire for ADoT . . . . . . . . . . . .   8
     7.1.  Server Side Support Signaling . . . . . . . . . . . . . .   9
     7.2.  Client Side Desire Signaling  . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   9
   11. Informative References  . . . . . . . . . . . . . . . . . . .  10
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   The Domain Name System (DNS) predates any concerns over privacy,
   including the possibility of pervasive surveillance.  The original
   transports for DNS were UDP and TCP, unencrypted.  Additionally, DNS
   did not originally have any form of data integrity protection,
   including against active on-path attackers.

   DNSSEC (DNS Security extensions) added data integrity protection, but
   did not address privacy concerns.  The original DNS over TLS
   [RFC7858] and DNS over HTTPS [RFC8484] specifications were limited to
   client-to-resolver traffic.

Dickson                   Expires 20 March 2022                 [Page 2]
Internet-Draft             Authenticated ADoT             September 2021

   The remaining privacy component is recursive-to-authoritative
   servers.  This Internet Draft is designed to provide a solution to
   this problem.

2.  Conventions and Definitions

   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 BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Background

   The result is that the parental side of the zone cut has records
   needed for DNS resolution which are not signed and not validatable.

4.  Purpose, Requirements, and Limitations

   Authoritative DNS over TLS is intended to provide the following for
   communications from recursive resolvers to authoritative servers:

   *  Enable discovery of support for ADoT by use of SVCB, specifically
      using the RRTYPE "DNST" (service binding for DNS Transport)

   *  Validate the name server names serving specific domain names/
      zones, by use of DS records which encode the NS delegation names

   *  Validate the TLS certificates used for the TLS connection to the
      server names at the corresponding IP addresses, either directly
      (End Entity) or indirectly (Sigining Certifiate) obtained by TLSA
      lookup

   *  Authenticate the server name by requiring a match between the
      server name and the TLS certificate sent by the server on the TLS
      connection

   *  Provide privacy via the end-to-end encrypted transport provided by
      TLS session which was validated by the above components

   This protocol depends on correct configuration and operation of the
   respective components, and that those are maintained according to
   Best Current Practices:

   *  DS records for the protection of the delegation to the authoritive
      name servers

Dickson                   Expires 20 March 2022                 [Page 3]
Internet-Draft             Authenticated ADoT             September 2021

   *  DNSSEC signing of the zone serving the authoritative name servers'
      names

   *  DNSSEC signing of any other zones involved in serving the
      authoritative name servers' names (e.g. zones containing names of
      the name servers for the authoritative name servers).

   *  Proper management of key signing material for DNSSEC

   *  Ongoing management of RRSIGs on a timely basis (avoiding RRSIG
      expiry)

   *  Ensuring TLSA records are kept synchronized with the TLS
      certificates for the name servers in question doing ADoT

   *  Proper management of TLS private keys for TLS certificates

   There are external dependencies that impact the system security of
   any DNSSEC zone, which are inherently unavoidable in establishing
   this scheme.  Specifially, the original DS record enrollment and any
   updates to the DS records involved in DNSSEC delegations are presumed
   secure and outside of the scope of the DNS protocol per se.

   Other risks relate to normal information security practices,
   including access controls, role based access, audits, multi-factor
   authentication, multi-party controls, etc.  These are out of scope
   for this protocol itself.

5.  DNS Records To Publish for ADoT

5.1.  Server DNS Transport Support Signaling

   In order to support ADoT for a DNS server, it is necessary to publish
   a record specifyig explicit DoT support.  This record also indicates
   other supported transports for the DNS server, e.g. the standard
   ports (TCP and UDP port 53).

   The record type is "DNST", which is a specific instance of SVCB with
   unique RRTYPE.

   The zone serving the record MUST be DNSSEC signed.  The absence of
   the DNST RRTYPE is proven by the NSEC(3) record, or the DNST RRTYPE
   plus RRSIG is returned in response to a query for this record.

Dickson                   Expires 20 March 2022                 [Page 4]
Internet-Draft             Authenticated ADoT             September 2021

5.1.1.  Prerequisite: New SVCB Binding for DNS and DoT

   (NB: To be separated out into its own draft and expanded fully.)
   This SVCB binding will be given the RRTYPE value {TBD} with mnemonic
   name DNST ("DNS Transport").  Like any SVCB binding, there is a
   mandatory TargetName (which will normally be ".", indicating the
   target is the same as the record owner name).  The default binding is
   the standard DNS ports, UDP/53 and TCP/53.  The SVCB binding includes
   support for an optional ADoT port, which is the standard DoT port
   TCP/853.  This is signaled by "alpn=dot".  The actual port number may
   be overridden with the "port=N" SvcParam.  Since DNST is a type-
   specific binding, it does NOT require the underscore prefix naming
   that the generic SVCB RRTYPE requires.  It may occur anywhere,
   including at the apex of a DNS zone, and may co-exist with any other
   type that also permits other types (i.e. anything except CNAME or
   DNAME).

5.1.1.1.  Default Ports for DNS

   This scheme uses an SVCB binding for DNS Transport, DNST.  The
   binding has default ports UDP/53 and TCP/53 as the default-alpn.
   These are assumed unless "no-default-alpn" is added as an optional
   SvcParam.

5.1.1.2.  Optional Port for DoT

   The DNST binding uses the defined ALPN for DNS-over-TLS with the
   assigned label "dot".  Use of ADoT is signaled if and only if the the
   SvcParam of "alpn=dot" is present.

5.1.2.  Example

   Suppose the name server ns1.example.net supports only the normal DNS
   ports, and the name server ns2.example.net supports both the normal
   ports and ADoT.  The zone example.net would include the records:

       ns1.example.net. IN DNST 1 "."
       ns2.example.net. IN DNST 1 "." alpn=dot

   The first parameter is the SvcPriority, which must be non-zero (zero
   indicates AliasForm SVCB record type).  Note that it is possible to
   use different SvcPriority, directing resolvers to prefer non-DoT over
   DoT or vice versa.  This would be appropriate based on the resolver's
   local policy, and potentially support mandatory use of DoT if present
   on any server in the NS RRset.

Dickson                   Expires 20 March 2022                 [Page 5]
Internet-Draft             Authenticated ADoT             September 2021

5.2.  DANE TLSA Records for ADoT

   The presence of ADoT requires additionally that a TLSA [RFC6698]
   record be provided.  A new RRTYPE is to be created for this as an
   alias of TLSA, with mnemonic of "ADOTC" (ADOT Certificate).  This
   record will be published at the location NS_NAME, where NS_NAME is
   the name of the name server.  Any valid TLSA RDATA is permitted.  The
   use of Certificate Usage types PKIX-TA and PKIX-EE is NOT
   RECOMMENDED.  The use of Certificate Usage types DANE-TA TLSA records
   may provide more flexibility in provisioning, including use of wild
   cards.  Per [RFC7218][RFC6761] the RECOMMENDED Selector and Matching
   types for this are CERT and FULL, giving the recommended TLSA record
   type of DANE-TA CERT FULL, with the full encoded certificate.

   Note that this ADOTC record is "wildcard friendly".  Use of
   aggressive synthesis by resolvers (per [RFC8198]) allows RRTYPE-
   specific wildcards to be used, avoiding repetitive entries where the
   RDATA is identical.

5.2.1.  Example

   In the above example, ns2.example.net supports DNS over TLS, and
   would need to have a TLSA record.  The zone would include:

       ns2.example.net. IN ADOTC DANE-TA CERT FULL (signing cert)

   If there were another zone containing many DNS server names,
   example2.net, it would be relatively simple to apply a wildcard
   record and use a signing cert (rather than end-entity cert) in the
   ADOTC record).  This would allow DNS caching to avoid repeated
   queries to the authoritative server for the zone containing the DNS
   server names, to obtain the TLSA-type information.  This would look
   like the following:

       *.example2.net IN ADOTC DANE-TA CERT FULL (signing cert)
       ns1.example2.net IN A IP_ADDRESS1
       ns2.example2.net IN A IP_ADDRESS2
       ns3.example2.net IN A IP_ADDRESS3
       ns4.example2.net IN A IP_ADDRESS4

5.3.  Signaling DNS Transport for a Name Server

   This transport signaling MUST only be trusted if the name server
   names for the domain containing the relevant name servers' names are
   protected with [I-D.dickson-dnsop-ds-hack] and validated.  The name
   servers must also be in a DNSSEC signed zone (i.e. securely delegated
   where the delegation has been successfully DNSSEC validated).

Dickson                   Expires 20 March 2022                 [Page 6]
Internet-Draft             Authenticated ADoT             September 2021

   The specific DNS transport that a name server supports is indicated
   via use of an RRSet of RRTYPE "DNST".  This is a SVCB binding, and
   normally will use the TargetName of "." (meaning the same name).  The
   default ALPN (transport mechanisms) are TCP/53 and UDP/53.  The ADoT
   transport support is signaled by "alpn=dot".  There is an existing
   entry for "dot" in the ALPN table, with port TCP/853.

   Note that this RRTYPE is also "wildcard friendly".  If a DNS zone
   containing the names of many servers with identical policy (related
   to ADoT support), those could be managed via one or more wildcard
   entries.

5.3.1.  Example

   We re-use the same example from above, indicating whether or not
   individual authoritative name servers support DoT:

       ns1.example.net. IN DNST 1 "."
       ns2.example.net. IN DNST 1 "." alpn=dot

   And similarly, if another zone with many name server names wanted to
   have a policy of all-ADoT support, this could be encoded as:

       *.example2.net DNST 1 "." alpn=dot

5.4.  Signaling DNS Transport for a Domain

   A domain inherits the signaled transport for the name servers serving
   the domain.

   This transport signaling MUST only be trusted for use of ADoT if the
   delegated name server names for the domain are protected with
   [I-D.dickson-dnsop-ds-hack].

   The delegation to NS names "A" and "B", along with the DS record
   protecting/encoding "A" and "B", results in the DNS transport that is
   signaled for "A" and "B" being applied to the domain being delegated.
   This transport will include ADoT IFF the transport for "A" and "B"
   has included ADoT via DNS records.

5.4.1.  Example

   No additional configutation is needed, beyond use of authority
   servers which signal DoT support.  The following example assumes the
   previous DNS records are provisioned:

   example.comm NS ns1.example.net.
   example.comm NS ns2.example.net.

Dickson                   Expires 20 March 2022                 [Page 7]
Internet-Draft             Authenticated ADoT             September 2021

   In this example, ns1 does not have ADoT support (since the DNS record
   excludes the "alpn=dot" parameter), while ns2 does support ADoT
   (since it includes "alpn=dot").

6.  Validation Using DS Records, DNS Records, TLSA Records, and DNSSEC
    Validation

   These records are used to validate corresponding delegation records,
   DNS records, and TLSA records, as follows:

   *  Initial domain NS records are validated using
      [I-D.dickson-dnsop-ds-hack]

   *  All DS records imlementing [I-D.dickson-dnsop-ds-hack] must be
      DNSSEC validated prior to use

   *  Once the NS names have been validated, and the delegations to the
      appropriate name servers are validated, the DNS records for the NS
      name are obtained to identify the DNS transport methods supported.

   *  If ADoT is among the supported transports, the TLSA record for the
      name server is obtained, and used for verification of the TLS
      certificate when making the TLS connection.

6.1.  Complete Example

   Suppose a client requests resolution for the IP address of
   "sensitive-name.example.com".  Suppose the client's resolver has a
   "cold" cache without any entries beyond the standard Root Zone and
   relevant TLD name server records.

   Suppose the following entries are present at their respective TLD
   authority servers, delegating to the respective authority servers:

   FIXME

7.  Signaling Support and Desire for ADoT

   The following presume some new OPT sub-types, to be added to the IANA
   action section or to be split out as separate drafts.  The sub-type
   mnemonics are "ADOTA" (available) and "ADOTD" (desired), each with an
   enumerated set of values and mnemonic codes.  Respectively those are:
   "Always", "Upon Request", and "Never"; and "Force", "If Available",
   and "Never".

Dickson                   Expires 20 March 2022                 [Page 8]
Internet-Draft             Authenticated ADoT             September 2021

7.1.  Server Side Support Signaling

   A DNS server (e.g. recursive resolver or forwarder) MAY signal to
   clients that it offers the use of ADoT.  The mechanism used is to set
   the EDNS option "ADOTA".  The values for this option are "Always",
   "Upon Request", and "Never".  The value "Always" indicates the server
   will always attempt to use ADoT without regards to client requests
   for ADoT.  The value "Upon Request" indicates that the server will
   ONLY use ADoT for upstream queries if the client requests that ADoT
   be used.  These values have no effect on answers served from the
   resolver's cache.  (The "Never" case is unusual, in that it signals
   the server understands the option, but does not perform ADoT.
   Generally this would be used to allow a client to track changes in
   the status, if the client is interested in uses of ADoT.)

7.2.  Client Side Desire Signaling

   A DNS client (e.g. stub or forwarder) MAY signal the desire to have
   the resolver use ADoT.  The mechanism used is to set the EDNS option
   "ADOTD".  The values for this option are "Force", "If Available", and
   "Never".  The value "Force" indicates the server should attempt to
   use ADoT, and return a failure code of XXXX and an EDE value of YYYY
   if the authoritative server does not offer ADoT, or any other ADoT
   failure occurs.  The value "If Available" indicates that the server
   should use ADoT for upstream queries if it is availble, but SHOULD
   NOT allow any downgrades if the authoritative server signals that
   ADoT is available.  These values have no effect on answers served
   from the resolver's cache.  (The "Never" case is unusual, in that it
   signals the client understands the option, but does not perform ADoT.
   Generally this would be used to allow a server to track changes in
   the client base, so the server operator can make informed decisions
   about enabling ADoT.)

8.  Security Considerations

   As outlined above, there could be security issues in various use
   cases.

9.  IANA Considerations

   This document may or many not have any IANA actions. (e.g. if the
   RRTYPEs, EDNS subtypes, DNSKEY algorithms, etc., are defined in other
   documents, no IANA actions are needed.)

10.  Normative References

Dickson                   Expires 20 March 2022                 [Page 9]
Internet-Draft             Authenticated ADoT             September 2021

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
              2012, <https://www.rfc-editor.org/info/rfc6698>.

   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
              RFC 6761, DOI 10.17487/RFC6761, February 2013,
              <https://www.rfc-editor.org/info/rfc6761>.

   [RFC7218]  Gudmundsson, O., "Adding Acronyms to Simplify
              Conversations about DNS-Based Authentication of Named
              Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April
              2014, <https://www.rfc-editor.org/info/rfc7218>.

   [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, <https://www.rfc-editor.org/info/rfc7858>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8198]  Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
              DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
              July 2017, <https://www.rfc-editor.org/info/rfc8198>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/info/rfc8484>.

11.  Informative References

   [I-D.dickson-dnsop-ds-hack]
              Dickson, B., "DS Algorithms for Securing NS and Glue",
              Work in Progress, Internet-Draft, draft-dickson-dnsop-ds-
              hack-00, 11 August 2021,
              <https://datatracker.ietf.org/doc/html/draft-dickson-
              dnsop-ds-hack-00>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Dickson                   Expires 20 March 2022                [Page 10]
Internet-Draft             Authenticated ADoT             September 2021

Appendix A.  Acknowledgments

   Thanks to everyone who helped create the tools that let everyone use
   Markdown to create Internet Drafts, and the RFC Editor for xml2rfc.

   Thanks to Dan York for his Tutorial on using Markdown (specificially
   mmark) for writing IETF drafts.

   Thanks to YOUR NAME HERE for contributions, reviews, etc.

Author's Address

   Brian Dickson
   GoDaddy

   Email: brian.peter.dickson@gmail.com

Dickson                   Expires 20 March 2022                [Page 11]