dprive
Internet Engineering Task Force (IETF)                      S. Dickinson
Internet-Draft
Request for Comments: 8310                                       Sinodun
Updates: 7858 (if approved)                                                 D. Gillmor
Intended status:
Category: Standards Track                                           ACLU
Expires: March 15, 2018
ISSN: 2070-1721                                                 T. Reddy
                                                                  McAfee
                                                      September 11, 2017
                                                              March 2018

           Usage and (D)TLS Profiles for DNS-over-(D)TLS
               draft-ietf-dprive-dtls-and-tls-profiles-11 DNS over TLS and DNS over DTLS

Abstract

   This document discusses Usage Profiles, usage profiles, based on one or more
   authentication mechanisms, which can be used for DNS over Transport
   Layer Security (TLS) or Datagram TLS (DTLS).  These profiles can
   increase the privacy of DNS transactions compared to using only clear
   text
   cleartext DNS.  This document also specifies new authentication
   mechanisms
   - -- it describes several ways that a DNS client can use an
   authentication domain name to authenticate a (D)TLS connection to a
   DNS server.  Additionally, it defines (D)TLS protocol profiles for
   DNS clients and servers implementing DNS-over-(D)TLS. DNS over (D)TLS.  This document
   updates RFC 7858.

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 an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of six months RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 March 15, 2018.
   https://www.rfc-editor.org/info/rfc8310.

Copyright Notice

   Copyright (c) 2017 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
   (http://trustee.ietf.org/license-info)
   (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
   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  . . . . . . . . . . . . . . . . . . . . . . . .   3 ....................................................4
   2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5 .....................................................6
   3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   6 ...........................................................7
   4. Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   7 ......................................................8
   5. Usage Profiles  . . . . . . . . . . . . . . . . . . . . . . .   7 ..................................................8
      5.1. DNS Resolution  . . . . . . . . . . . . . . . . . . . . .  10 ............................................11
   6. Authentication in DNS-over(D)TLS  . . . . . . . . . . . . . .  10 DNS over (D)TLS ..............................11
      6.1. DNS-over-(D)TLS Startup Configuration Problems  . . . . .  10 ............11
      6.2. Credential Verification . . . . . . . . . . . . . . . . .  11 ...................................12
      6.3. Summary of Authentication Mechanisms  . . . . . . . . . .  11 ......................12
      6.4. Combining Authentication Mechanisms . . . . . . . . . . .  14 .......................15
      6.5. Authentication in Opportunistic Privacy . . . . . . . . .  14 ...................15
      6.6. Authentication in Strict Privacy  . . . . . . . . . . . .  15 ..........................16
      6.7. Implementation guidance . . . . . . . . . . . . . . . . .  15 Guidance ...................................16
   7. Sources of Authentication Domain Names  . . . . . . . . . . .  15 .........................17
      7.1. Full direct configuration . . . . . . . . . . . . . . . .  15 Direct Configuration .................................17
      7.2. Direct configuration Configuration of ADN only  . . . . . . . . . . . .  16 Only ..........................17
      7.3. Dynamic discovery Discovery of ADN  . . . . . . . . . . . . . . . .  16 ..................................17
           7.3.1. DHCP  . . . . . . . . . . . . . . . . . . . . . . . .  16 ...............................................18
   8. Credential Verification Based on Authentication Domain Name based Credential Verification  . .  17 ....18
      8.1. Authentication Based on PKIX Certificate Based Authentication . . . . . . . . . .  17 ..................18
      8.2. DANE  . . . . . . . . . . . . . . . . . . . . . . . . . .  17 ......................................................19
           8.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . .  18 Meta-Queries ............................20
           8.2.2. TLS DNSSEC Chain extension  . . . . . . . . . . . . .  18 Extension .........................20
   9. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . .  19 ........................................20
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20 ...........................................21
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  20 .......................................21
      11.1.  Counter-measures Countermeasures to DNS Traffic Analysis . . . . . . . .  20 ..................22
   12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  21
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     13.1. ....................................................22
      12.1. Normative References . . . . . . . . . . . . . . . . . .  21
     13.2. .....................................22
      12.2. Informative References . . . . . . . . . . . . . . . . .  23 ...................................24
   Appendix A. Server capability probing Capability Probing and caching Caching by DNS clients  24
   Appendix B.  Changes between revisions  . . . . . . . . . . . . .  24
     B.1.  -11 version . . . . . . . . . . . . . . . . . . . . . . .  25
     B.2.  -10 version . . . . . . . . . . . . . . . . . . . . . . .  25
     B.3.  -09 version . . . . . . . . . . . . . . . . . . . . . . .  26
     B.4.  -08 version . . . . . . . . . . . . . . . . . . . . . . .  26
     B.5.  -07 version . . . . . . . . . . . . . . . . . . . . . . .  26
     B.6.  -06 version . . . . . . . . . . . . . . . . . . . . . . .  26
     B.7.  -05 version . . . . . . . . . . . . . . . . . . . . . . .  27
     B.8.  -04 version . . . . . . . . . . . . . . . . . . . . . . .  27
     B.9.  -03 version . . . . . . . . . . . . . . . . . . . . . . .  27
     B.10. -02 version . . . . . . . . . . . . . . . . . . . . . . .  27
     B.11. -01 version . . . . . . . . . . . . . . . . . . . . . . .  28
     B.12. draft-ietf-dprive-dtls-and-tls-profiles-00  . . . . . . .  28 Clients ..26
   Acknowledgments ...................................................27
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28 ................................................27

1.  Introduction

   DNS Privacy privacy issues are discussed in [RFC7626].  The specific issues
   described there in [RFC7626] that are most relevant to this document are

   o  Passive attacks which that eavesdrop on clear text cleartext DNS transactions on
      the wire (Section 2.4) 2.4 of [RFC7626]) and

   o  Active attacks which that redirect clients to rogue servers to monitor
      DNS traffic (Section 2.5.3). 2.5.3 of [RFC7626]).

   Mitigating against these attacks increases the privacy of DNS
   transactions, however transactions;
   however, many of the other issues raised in [RFC7626] still apply.

   Two documents that provide ways to increase DNS privacy between DNS
   clients and DNS servers are: are

   o  Specification  "Specification for DNS over Transport Layer Security (TLS) (TLS)"
      [RFC7858], referred to here as simply 'DNS-over-TLS' "DNS over TLS".

   o  DNS  "DNS over Datagram Transport Layer Security (DTLS) (DTLS)" [RFC8094],
      referred to here simply as 'DNS-over-DTLS'. simply "DNS over DTLS".  Note that this
      document has the Category of Experimental. [RFC8094]
      is an Experimental specification.

   Both documents are limited in scope to communications between stub
   clients and recursive resolvers resolvers, and the same scope is applied to
   this document (see Section Sections 2 and Section 3).  The proposals here might be
   adapted or extended in future to be used for recursive clients and
   authoritative servers, but this application was out of scope for the
   DNS PRIVate Exchange (dprive) Working Group charter at the time this
   document was finished. published.

   This document specifies two Usage Profiles usage profiles (Strict Privacy and Opportunistic)
   Opportunistic Privacy) for DTLS [RFC6347] and TLS [RFC5246] which that
   provide improved levels of mitigation against for the attacks described above
   compared to using only
   clear text cleartext DNS.

   Section 5 presents a generalized discussion of Usage Profiles usage profiles by
   separating the Usage Profile, usage profile, which is based purely on the security
   properties it offers the user, from the specific mechanism(s) mechanism or
   mechanisms that are used for DNS server authentication.  The Profiles profiles
   described are: are

   o  A Strict Profile that Privacy profile, which requires an encrypted connection
      and successful authentication of the DNS server which server; this mitigates
      both passive eavesdropping and client re-direction redirection (at the expense
      of providing no DNS service if this an encrypted, authenticated
      connection is not available).

   o  An Opportunistic Profile that Privacy profile, which will attempt, but does not
      require, encryption and successful authentication; it therefore
      provides limited or no mitigation against for such attacks but offers maximum maximizes
      the chance of DNS service.

   The above Usage Profiles usage profiles attempt authentication of the server using
   at least one authentication mechanism.  Section 6.4 discusses how to
   combine authentication mechanisms to determine the overall
   authentication result.  Depending on that overall authentication
   result (and whether encryption is available) available), the Usage Profile usage profile will
   determine if the connection should proceed, fallback fall back, or fail.

   One authentication mechanism is already described in [RFC7858].  That
   document
   [RFC7858] specifies a an authentication mechanism for DNS over TLS that
   is based on Subject Public Key Info (SPKI) based
   authentication mechanism for DNS-over-TLS in the context of a
   specific case of a Strict Usage Profile Privacy profile using that single
   authentication mechanism.  Therefore  Therefore, the "Out-of-band Key-pinned
   Privacy Profile" "out-of-band key-pinned
   privacy profile" described in [RFC7858] would qualify as a "Strict
   Usage Profile"
   Privacy profile" that used SPKI pinning for authentication.

   This document extends the use of SPKI pinset based authentication based on SPKI
   pin sets, so that it is considered a general authentication mechanism
   that can be used with either DNS-over-(D)TLS Usage Profile. usage profile.  That is,
   the SPKI
   pinset mechanism for SPKI pin sets as described in [RFC7858] MAY be used
   with DNS-
   over-(D)TLS. DNS over (D)TLS.

   This document also describes a number of additional authentication
   mechanisms
   mechanisms, all of which specify how a DNS client should authenticate
   a DNS server based on an 'authentication "authentication domain name'. name".  In
   particular, the following is topics are described:

   o  How a DNS client can obtain the combination of an authentication
      domain name and IP address for a DNS server.  See Section 7.

   o  What are the acceptable credentials a DNS server can present to prove its
      identity for (D)TLS authentication based on a given authentication
      domain name.  See Section 8.

   o  How a DNS client can verify that any given credential matches the
      authentication domain name obtained for a DNS server.  See
      Section 8.

   In Section 9 this

   This document defines a (D)TLS protocol profile for use with DNS. DNS; see
   Section 9.  This profile defines the configuration options and
   protocol extensions required of both parties to (1) optimize
   connection establishment and session resumption for transporting DNS, DNS
   and to (2) support all currently specified authentication mechanisms.

2.  Terminology

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

   Several terms are used specifically in the context of this draft: document:

   o  DNS client: a A DNS stub resolver or forwarder.  In the case of a
      forwarder, the term "DNS client" is used to discuss the side that
      sends queries.

   o  DNS server: a A DNS recursive resolver or forwarder.  In the case of
      a forwarder, the term "DNS server" is used to discuss the side
      that responds to queries.  For emphasis,  Note that, as used in this document the document,
      this term does not apply to authoritative servers.

   o  Privacy-enabling DNS server: A DNS server that implements DNS-
      over-TLS
      DNS over TLS [RFC7858] and may optionally implement DNS-over-DTLS DNS over DTLS
      [RFC8094].  The server should also offer at least one of the
      credentials described in Section 8 and implement the (D)TLS
      profile described in Section 9.

   o  (D)TLS: For brevity this term is used Used for statements that apply brevity; refers to both Transport Layer Security
      [RFC5246] and Datagram Transport Layer Security [RFC6347].
      Specific terms will be used for any
      statement text that applies to either
      protocol alone.

   o  DNS-over-(D)TLS: For brevity this term is used  DNS over (D)TLS: Used for statements that
      apply brevity; refers to both DNS-over-TLS DNS over TLS
      [RFC7858] and DNS-over-DTLS DNS over DTLS [RFC8094].  Specific terms will be
      used for any statement text that applies to either protocol alone.

   o  Authentication domain name: A domain name that can be used to
      authenticate a privacy-enabling DNS server.  Sources of
      authentication domain names are discussed in Section 7.

   o  SPKI Pinsets: pin sets: [RFC7858] describes the use of cryptographic
      digests to "pin" public key information in a manner similar to
      HTTP Public Key Pinning [RFC7469] (HPKP). (HPKP) [RFC7469].  An SPKI pinset pin set is a
      collection of these pins that constrains a DNS server.

   o  Authentication information: Information a DNS client may use as
      the basis of an authentication mechanism.  In this context that context, this
      information can be either a:

      *  a  an SPKI pinset pin set or

      *  an authentication domain name

   o  Reference Identifier: a Reference Identifier identifier: A reference identifier as described in
      [RFC6125], constructed by the DNS client when performing TLS
      authentication of a DNS server.

   o  Credential: Information available for a DNS server which that proves its
      identity for authentication purposes.  Credentials discussed here include:
      include

      *  a PKIX certificate

      *  DNSSEC validated  a DNSSEC-validated chain to a TLSA record

      but may also include SPKI pinsets. pin sets.

3.  Scope

   This document is limited to describing

   o  Usage Profiles profiles based on general authentication mechanisms mechanisms.

   o  The details of domain name based domain-name-based authentication of DNS servers by
      DNS clients (as defined in the terminology section) Section 2).

   o  The (D)TLS profiles needed to support authentication in DNS-
      over-(D)TLS.
      DNS over (D)TLS.

   As such, the following things topics are out of scope: scope for this document:

   o  Authentication of authoritative servers by recursive resolvers.

   o  Authentication of DNS clients by DNS servers.

   o  The details of how to perform SPKI-pinset-based authentication. authentication based on SPKI
      pin sets.  This is defined in [RFC7858].

   o  Any server identifier other than domain names, including IP
      addresses, organizational names, country of origin, etc.

4.  Discussion

   One way to mitigate against passive attackers eavesdropping on clear
   text cleartext DNS transactions by
   passive attackers is to encrypt the query (and response).  Such
   encryption typically provides integrity protection as a side-effect,
   which side effect;
   this means that on-path attackers cannot simply inject bogus DNS
   responses.  To also mitigate against active attackers pretending to be the
   server, the client must authenticate the (D)TLS connection to the
   server.

   This document discusses Usage Profiles, usage profiles, which provide differing
   levels of attack mitigation to DNS clients, based on the requirements
   for authentication and encryption, regardless of the context (for
   example, which network the client is connected to).  A Usage Profile usage profile
   is a distinct concept to distinct from a usage policy or usage model, which model; a usage
   policy or usage model might dictate which Profile profile should be used in a
   particular context (enterprise vs vs. coffee shop), with a particular
   set of DNS Servers servers or with reference to other external factors.  A
   description of the variety of usage policies is out of scope of for this document,
   document but may be the subject of future work.

   The term 'privacy-enabling "privacy-enabling DNS server' server" is used throughout this
   document.  This is a DNS server that: that

   o  MUST implement DNS-over-TLS DNS over TLS [RFC7858].

   o  MAY implement DNS-over-DTLS DNS over DTLS [RFC8094].

   o  SHOULD offer at least one of the credentials described in
      Section 8.

   o  Implements the (D)TLS profile described in Section 9.

5.  Usage Profiles

   A DNS client has a choice of Usage Profiles usage profiles available to increase the
   privacy of DNS transactions.  This choice is briefly discussed in
   both [RFC7858] and [RFC8094].  These Usage Profiles are: usage profiles are

   o  Strict Privacy profile: the The DNS client requires both an encrypted
      and authenticated connection to a privacy-enabling DNS Server. server.  A
      hard failure occurs if this is not available.  This requires the
      client to securely obtain authentication information it can use to
      authenticate the server.  This profile mitigates against both passive and
      active attacks attacks, thereby providing the client with the best
      available privacy for DNS.  This Profile profile is discussed in detail in
      Section 6.6.

   o  Opportunistic Privacy: the Privacy profile: The DNS client uses Opportunistic
      Security as described in [RFC7435] [RFC7435].

      *  "... the use of cleartext as the baseline communication
         security policy, with encryption and authentication negotiated
         and applied to the communication when available."

      As described in [RFC7435] [RFC7435], it might result in

      *  an encrypted and authenticated connection

      *  an encrypted connection

      *  a clear text cleartext connection

      depending on the fallback logic of the client, the available
      authentication information information, and the capabilities of the DNS Server.
      server.  In all these cases cases, the DNS client is willing to continue
      with a connection to the DNS Server server and perform resolution of
      queries.  The use of Opportunistic Privacy is intended to support
      incremental deployment of increased privacy with a view to
      widespread adoption of the Strict Privacy profile.  It should be
      employed when the DNS client might otherwise settle for cleartext;
      it provides the maximum protection available available, depending on the
      combination of factors described above.  If all the configured DNS
      Servers
      servers are DNS Privacy servers privacy servers, then it provides can provide protection
      against passive attacks but not and might protect against active ones.

   Both profiles can include an initial meta query meta-query (performed using an
   Opportunistic lookup) Privacy) to obtain the IP address for the privacy-
   enabling DNS server to which the DNS client will subsequently
   connect.  The rationale for permitting this for the Strict Privacy
   profile is that requiring such meta queries meta-queries to also be performed
   using the Strict Privacy profile would introduce significant
   deployment obstacles.  However, it should be noted that in this
   scenario an active attack is
   possible on the meta query. meta-query is possible.  Such an
   attack could result in a Strict Privacy profile client connecting to
   a server it cannot authenticate and so (and therefore not obtaining DNS service,
   service) or an Opportunistic Privacy client connecting to a server
   controlled by the attacker.  DNSSEC validation can detect the attack
   on the meta query and results meta-query, which may result in the client not obtaining DNS
   service (for both Usage profiles) because it will not
   proceed to connect to the server in question (see usage profiles), depending on its DNSSEC validation
   policy.  See Section 7.2) 7.2 for more discussion.

   To compare the two Usage profiles the table usage profiles, Table 1 below shows a successful
   Strict Privacy profile along side alongside the 3 three possible outcomes of an
   Opportunistic Privacy profile.  In the best case best-case scenario for the
   Opportunistic Privacy profile (an authenticated and encrypted connection)
   connection), it is equivalent to the Strict Privacy profile.  In the worst case scenario
   worst-case scenario, it is equivalent to clear
   text. cleartext.  Clients using
   the Opportunistic Privacy profile SHOULD try for the best case but
   MAY fallback fall back to the intermediate case and eventually and, eventually, the worst worst-
   case scenario scenario, in order to obtain a response.  One reason to
   fallback fall
   back without trying every available privacy-enabling DNS server is if
   latency is more important than attack mitigation, mitigation; see Appendix A.
   The Opportunistic Privacy profile therefore provides varying
   protection
   protection, depending on what kind of connection is actually used used,
   including no attack mitigation at all.

   Note that there is no requirement in Opportunistic Security to notify
   the user regarding what type of connection is actually used, used; the 'detection'
   "detection" described below is only possible if such connection
   information is available.  However, if it is available and the user
   is informed that an unencrypted connection was used to connect to a server
   server, then the user should assume (detect) that the connection is
   subject to both active and passive attack attacks, since the DNS queries are
   sent in clear
   text. cleartext.  This might be particularly useful if a new
   connection to a certain server is unencrypted when all previous
   connections were encrypted.  Similarly  Similarly, if the user is informed that
   an encrypted but unauthenticated connection was used used, then the user
   can detect that the connection may be subject to active attack. attacks.  In
   other words words, for the cases where no protection is provided against an
   attacker (N) (N), it is possible to detect that an attack might be
   happening (D).  This is discussed in Section 6.5.

    +---------------+------------+------------------+-----------------+
    | Usage Profile | Connection | Passive Attacker | Active Attacker |
    +---------------+------------+------------------+-----------------+
    |     Strict    |    A, E    |        P         |        P        |
    | Opportunistic |    A, E    |        P         |        P        |
    | Opportunistic |     E      |        P         |       N, D      |
    | Opportunistic |            |       N, D       |       N, D      |
    +---------------+------------+------------------+-----------------+

     P == Protection; N == No protection; D == Detection is possible;
         A == Authenticated connection; E == Encrypted connection

     Table 1: Attack protection Protection by Usage Profile and type Type of attacker Attacker

   The Strict Privacy profile provides the best attack mitigation and
   therefore SHOULD always be implemented in DNS clients that implement
   the Opportunistic Privacy. Privacy profile.

   A DNS client that implements DNS-over-(D)TLS DNS over (D)TLS SHOULD NOT be configured
   by default to use only clear text. cleartext.

   The choice between the two profiles depends on a number of factors factors,
   including which is more important to the particular client:

   o  DNS service service, at the cost of no attack mitigation (Opportunistic) (Opportunistic
      Privacy) or

   o  best  Best available attack mitigation mitigation, at the potential cost of no DNS
      service (Strict).

   Additionally (Strict Privacy).

   Additionally, the two profiles require varying levels of
   configuration (or a trusted relationship with a provider) and DNS
   server
   capabilities, therefore capabilities; therefore, DNS clients will need to carefully
   select which profile to use based on their communication needs.

   A DNS server that implements DNS-over-(D)TLS DNS over (D)TLS SHOULD provide at least
   one credential (Section 2) so that those DNS clients that wish to do so are able
   to use
   the Strict Privacy profile (see Section 2). are able to do so.

5.1.  DNS Resolution

   A DNS client SHOULD select a particular Usage Profile usage profile when resolving
   a query.  A DNS client MUST NOT fallback fall back from Strict Privacy to
   Opportunistic Privacy during the resolution of a given query query, as this
   could invalidate the protection offered against attackers.  It is
   anticipated that DNS clients will use a particular Usage Profile usage profile for
   all queries to all configured servers until an operational issue or
   policy update dictates a change in the profile used.

6.  Authentication in DNS-over(D)TLS DNS over (D)TLS

   This section describes authentication mechanisms and how they can be
   used in either Strict or Opportunistic Privacy for DNS-over-(D)TLS. DNS over (D)TLS.

6.1.  DNS-over-(D)TLS Startup Configuration Problems

   Many (D)TLS clients use PKIX authentication [RFC6125] based on an
   authentication domain name for the server they are contacting.  These
   clients typically first look up the server's network address in the
   DNS before making this connection.  Such a DNS client therefore has a
   bootstrap problem, as it will typically only know the IP address of
   its DNS server.

   In this case, before connecting to a DNS server, a DNS client needs
   to learn the authentication domain name it should associate with the
   IP address of a DNS server for authentication purposes.  Sources of
   authentication domain names are discussed in Section 7.

   One advantage of this domain name based domain-name-based approach is that it
   encourages the association of stable, human recognizable human-recognizable identifiers
   with secure DNS service providers.

6.2.  Credential Verification

   The use

   Verification of SPKI pinset verification pin sets is discussed in [RFC7858].

   In terms of domain name based domain-name-based verification, once an authentication
   domain name is known for a DNS server server, a choice of authentication
   mechanisms can be used for credential verification.  Section 8
   discusses these mechanisms in detail, namely -- namely, PKIX certificate based certificate-based
   authentication and DANE. DNS-Based Authentication of Named Entities (DANE)
   -- in detail.

   Note that the use of DANE adds requirements on the ability of the
   client to get validated DNSSEC results.  This is discussed in more
   detail in Section 8.2.

6.3.  Summary of Authentication Mechanisms

   This section provides an overview of the various authentication
   mechanisms.  The table  Table 2 below indicates how the DNS client obtains
   information to use for authentication for each option; option: either
   statically via direct configuration or dynamically.  Of course, the
   Opportunistic Usage Profile Privacy profile does not require authentication authentication, and so
   a client using that profile may choose to connect to a
   privacy-enabling DNS server on the basis of just an IP address.

   +---+------------+-------------+------------------------------------+
   | # | Static     | Dynamically | Short name: Description            |
   |   | Config     | Obtained    |                                    |
   +---+------------+-------------+------------------------------------+
   | 1 | SPKI + IP  |             | SPKI: SPKI pinset(s) pin set(s) and IP       |
   |   |            |             | address obtained out of band       |
   |   |            |             | [RFC7858]                          |
   |   |            |             |                                    |
   | 2 | ADN + IP   |             | ADN: ADN and IP address obtained   |
   |   |            |             | out of band (see Section 7.1)      |
   |   |            |             |                                    |
   | 3 | ADN        | IP          | ADN only: Opportunistic lookups to Privacy    |
   |   |            |             | meta-queries to a NP DNS server for A/AAAA (see    |
   |   |            |             | for A/AAAA (see Section 7.2)       |
   |   |            |             |                                    |
   | 4 |            | ADN + IP    | DHCP: DHCP configuration only (see |
   |   |            |             | Section 7.3.1)                     |
   |   |            |             |                                    |
   | 5 | [ADN + IP] | [ADN + IP]  | DANE: DNSSEC chain obtained via    |
   |   |            | TLSA record | Opportunistic lookups to NP DNS Privacy meta-queries |
   |   |            |             | to NP DNS server (see Section      |
   |   |            |             | 8.2.1)                             |
   |   |            |             |                                    |
   | 6 | [ADN + IP] | [ADN + IP]  | TLS extension: DNSSEC chain        |
   |   |            | TLSA record | provided by PE DNS server in TLS   |
   |   |            |             | DNSSEC chain extension (see        |
   |   |            |             | Section 8.2.2)                     |
   +---+------------+-------------+------------------------------------+

                SPKI == SPKI pinset(s), pin set(s); IP == IP Address, Address;
        ADN == Authentication Domain Name, Name; NP == Network provided, Network-Provided;
        PE == Privacy-enabling, Privacy-Enabling; [ ] == Data may be obtained either
                         statically or dynamically

              Table 2: Overview of Authentication Mechanisms

   The following summary attempts to present some key attributes of each
   of the mechanisms (using the 'Short name' "Short name" from Table 2), indicating
   attractive attributes with a '+' "+" and undesirable attributes
   with a
   '-'. "-".

   1.  SPKI

       + Minimal leakage (Note (note that the ADN is always leaked in the
         Server Name Indication (SNI) field in the Client Hello ClientHello in TLS
         when communicating with a privacy-enabling DNS server)

       - Overhead of on-going ongoing key management required
   2.  ADN

       + Minimal leakage

       + One-off direct configuration only

   3.  ADN only

       + Minimal one-off direct configuration, configuration; only a human
          recognizable human-recognizable
         domain name needed

       - A/AAAA meta queries meta-queries leaked to network provided network-provided DNS server that
         may be subject to active attack (attack can be mitigated by
         DNSSEC validation). validation)

   4.  DHCP

       + No static config

       - Requires a non-standard or future DHCP option in order to
         provide the ADN

       - Requires secure and trustworthy connection to DHCP server if
         used with a Strict Usage Privacy profile

   5.  DANE

       The ADN and/or IP may be obtained statically or dynamically dynamically, and
       the relevant attributes of that method apply apply.

       + DANE options (e.g., matching on entire certificate)

       - Requires a DNSSEC validating DNSSEC-validating stub implementation (deployment (the
         deployment of which is limited at the time of this writing)

       - DNSSEC chain meta queries meta-queries leaked to network provided network-provided DNS server
         that may be subject to active attack

   6.  TLS extension

       The ADN and/or IP may be obtained statically or dynamically dynamically, and
       the relevant attributes of that method apply apply.

       + Reduced latency compared with 'DANE' DANE

       + No network provided network-provided DNS server required if ADN and IP
         statically configured
       + DANE options (e.g., matching on entire certificate)

       - Requires a DNSSEC validating DNSSEC-validating stub implementation

6.4.  Combining Authentication Mechanisms

   This draft document does not make explicit recommendations about how an SPKI
   pinset based
   authentication mechanism based on SPKI pin sets should be combined
   with a
   domain based domain-based mechanism from an operator perspective.  However  However,
   it can be envisaged that a DNS server operator may wish to make both
   an SPKI
   pinset pin set and an authentication domain name available to allow
   clients to choose which mechanism to use.  Therefore, the following is
   text provides guidance on how clients ought to behave if they choose
   to configure both, as is possible in HPKP [RFC7469].

   A DNS client that is configured with both an authentication domain
   name and a an SPKI pinset pin set for a DNS server SHOULD match on both a
   valid credential for the authentication domain name and a valid SPKI pinset
   pin set (if both are available) when connecting to that DNS server.
   In this
   case case, the client SHOULD treat the individual SPKI pin pins as
   specified in Section 2.6 of [RFC7469] with regard to user defined user-defined
   trust anchors.  The overall authentication result SHOULD only be
   considered successful if both authentication mechanisms are
   successful.

6.5.  Authentication in Opportunistic Privacy

   An Opportunistic Privacy Profile (based on Opportunistic Security [RFC7435] profile is described in [RFC7858]
   which
   [RFC7435]) that MAY be used for DNS-over-(D)TLS. DNS over (D)TLS is described in
   [RFC7858] and is further specified in this document.

   DNS clients issuing that issue queries under an opportunistic Opportunistic Privacy profile
   and which that know authentication information for a given privacy-enabling
   DNS server SHOULD try to authenticate the server using the mechanisms
   described here.  This is useful for detecting (but not preventing)
   active attack, attacks, since the fact that authentication information is
   available indicates that the server in question is a privacy-enabling
   DNS server to which it should be possible to establish an
   authenticated and encrypted connection.  In this case, whilst a
   client cannot know the reason for an authentication failure, from a
   security standpoint the client should consider an active attack in
   progress and proceed under that assumption.  For example, a client
   that implements a nameserver selection algorithm that preferentially
   uses nameservers which that successfully authenticated (see Section 5)
   might not continue to use the failing server if there were
   alternative servers available.

   Attempting authentication is also useful for debugging or diagnostic
   purposes if there are means to report the result.  This information
   can provide a basis for a DNS client to switch to (preferred) Strict
   Privacy where it is viable e.g, viable, e.g., where all the configured servers
   support DNS-over-(D)TLS DNS over (D)TLS and successfully authenticate.

6.6.  Authentication in Strict Privacy

   To authenticate a privacy-enabling DNS server, a DNS client needs to
   know authentication information for each server it is willing to
   contact.  This is necessary to protect against active attacks which that
   attempt to re-direct redirect clients to rogue DNS servers.

   A DNS client requiring Strict Privacy MUST either use either (1) one of the
   sources listed in Section 7 7, to obtain an authentication domain name
   for the server it contacts, contacts or use (2) an SPKI pinset pin set as described in
   [RFC7858].

   A DNS client requiring Strict Privacy MUST only attempt to connect to
   DNS servers for which at least one piece of authentication
   information is known.  The client MUST use the available verification
   mechanisms described in Section 8 to authenticate the server, server and MUST
   abort connections to a server when no verification mechanism
   succeeds.

   With Strict Privacy, the DNS client MUST NOT commence sending DNS
   queries until at least one of the privacy-enabling DNS servers
   becomes available.

   A privacy-enabling DNS server may be temporarily unavailable when
   configuring a network.  For example, for clients on networks that
   require registration through web-based login (a.k.a. "captive
   portals"), such registration may rely on DNS interception and
   spoofing.  Techniques such as those used by DNSSEC-trigger dnssec-trigger
   [dnssec-trigger] MAY be used during network configuration, with the
   intent to transition to the designated privacy-enabling DNS servers
   after captive portal captive-portal registration.  If using a Strict Usage profile Privacy
   profile, the system MUST alert by some means that the DNS is not
   private during such bootstrap. a bootstrap operation.

6.7.  Implementation guidance Guidance

   Section 9 describes the (D)TLS profile for DNS-over(D)TLS. DNS over (D)TLS.
   Additional considerations relating to general implementation
   guidelines are discussed in both Section 11 and in Appendix A.

7.  Sources of Authentication Domain Names

7.1.  Full direct configuration Direct Configuration

   DNS clients may be directly and securely provisioned with the
   authentication domain name of each privacy-enabling DNS server.  For server -- for
   example, using a client specific client-specific configuration file or API.

   In this case, direct configuration for a DNS client would consist of
   both an IP address and an authentication domain name for each DNS
   server.
   server that were obtained via an out-of-band mechanism.

7.2.  Direct configuration Configuration of ADN only Only

   A DNS client may be configured directly and securely with only the
   authentication domain name of each of its privacy-enabling DNS
   servers.  For
   servers -- for example, using a client specific client-specific configuration file
   or API.

   A DNS client might learn of a default recursive DNS resolver from an
   untrusted source (such as DHCP's DNS server Recursive Name Server option
   [RFC3646]).  It can then use meta-queries performed using an
   Opportunistic DNS connections Privacy profile to an untrusted recursive DNS resolver
   to establish the IP address of the intended privacy-
   enabling privacy-enabling DNS
   resolver by doing a lookup of A/AAAA records.  Such
   records  A DNSSEC-validating
   client SHOULD be apply the same validation policy to the A/AAAA
   meta-queries as it does to other queries.  A client that does not
   validate DNSSEC validated when using a Strict Usage profile
   and MUST be validated when using Opportunistic Privacy. SHOULD apply the same policy (if any) to the A/AAAA
   meta-queries as it does to other queries.  Private DNS resolution can
   now be done by the DNS client against the pre-
   configured privacy-enabling pre-configured privacy-
   enabling DNS resolver, using the IP address
   gathered obtained from the
   untrusted DNS resolver.

   A DNS client so configured that successfully connects to a privacy-
   enabling DNS server MAY choose to locally cache the server host IP
   addresses in order to not have to repeat the opportunistic lookup. meta-query.

7.3.  Dynamic discovery Discovery of ADN

   This section discusses the general case of a DNS client discovering
   both the authentication domain name and IP address dynamically.  This
   is not possible at  At
   the time of writing this writing, this is not possible by any standard means.
   However
   However, since, for example, a future DHCP extension could (in
   principle) provide this mechanism mechanism, the required security properties
   of such mechanisms are outlined here.

   When using a Strict profile Privacy profile, the dynamic discovery technique
   used as a source of authentication domain names MUST be considered
   secure and trustworthy.  This requirement does not apply when using
   an Opportunistic profile Privacy profile, given the security expectation of
   that profile.

7.3.1.  DHCP

   In the typical case today, a DHCP server [RFC2131] [RFC3315] provides
   a list of IP addresses for DNS resolvers (see Section 3.8 of
   [RFC2132]),
   [RFC2132]) but does not provide an authentication domain name for the
   DNS resolver, thus preventing the use of most of the authentication
   methods described here (all of those that are based on a mechanism
   with ADN in ADN; see Table 2).

   This document does not specify or request any DHCP extension to
   provide authentication domain names.  However, if one is developed in
   future work work, the issues outlined in Section 8 of [RFC7227] should be
   taken into account account, as should the Security Considerations security considerations discussed
   in Section 23 of [RFC3315]). [RFC3315].

   This document does not attempt to describe secured and trusted
   relationships to DHCP servers, which as this is a purely a DHCP issue (still (and
   still open, at the time of writing.) this writing).  Whilst some implementation
   work is in progress to secure IPv6 connections for DHCP, IPv4
   connections have received little to or no implementation attention in
   this area.

8.  Credential Verification Based on Authentication Domain Name based Credential Verification

8.1.  Authentication Based on PKIX Certificate Based Authentication

   When a DNS client configured with an authentication domain name
   connects to its configured DNS server over (D)TLS, the server may
   present it with a PKIX certificate.  In order to ensure proper
   authentication, DNS clients MUST verify the entire certification path
   per [RFC5280].  The DNS client additionally uses [RFC6125] validation
   techniques as described in [RFC6125] to compare the domain name to
   the certificate provided.

   A DNS client constructs one Reference Identifier reference identifier for the server based
   on the authentication domain name: A DNS-ID a DNS-ID, which is simply the
   authentication domain name itself.

   If the Reference Identifier reference identifier is found (as described in Section 6 of
   [RFC6125]) in the PKIX certificate's subjectAltName extension as described in section 6 of [RFC6125], extension, the
   DNS client should accept the certificate for the server.

   A compliant DNS client MUST only inspect the certificate's
   subjectAltName extension for the Reference Identifier. reference identifier.  In
   particular, it MUST NOT inspect the Subject field itself.

8.2.  DANE

   DANE [RFC6698] provides various mechanisms using DNSSEC to anchor certificate
   trust for certificates and raw public key trust with DNSSEC.  However keys.  However, this requires
   the DNS client to have an authentication domain name for the DNS Privacy Server
   which (which must be
   obtained via a trusted source. source) for the DNS privacy server.

   This section assumes a solid understanding of both DANE [RFC6698] and
   DANE Operations operations [RFC7671].  A few pertinent issues covered in these
   documents are outlined here as useful pointers, but familiarity with
   both of these documents in their entirety is expected.

   It is noted

   Note that [RFC6698] says
      "Clients

      Clients that validate the DNSSEC signatures themselves MUST use
      standard DNSSEC validation procedures.  Clients that rely on
      another entity to perform the DNSSEC signature validation MUST use
      a secure mechanism between themselves and the validator."

   It is noted validator.

   Note that [RFC7671] covers the following topics:

   o  Section 4.1: Opportunistic  Sections 4.1 ("Opportunistic Security and PKIX Usages Usages") and
      Section 14: Security Considerations, 14
      ("Security Considerations") of [RFC7671], which both discuss the
      use of
      Trust Anchor and End Entity based schemes based on trust anchors and end entities (PKIX-TA(0)
      and PKIX-
      EE(1) PKIX-EE(1), respectively) for Opportunistic Security.

   o  Section 5: Certificate-Usage-Specific 5 ("Certificate-Usage-Specific DANE Updates and Guidelines.
      Specifically
      Guidelines") of [RFC7671] -- specifically, Section 5.1 of
      [RFC7671], which outlines the combination of
      Certificate Usage certificate usage
      DANE-EE(3) and Selector Usage selector SPKI(1) with Raw
      Public Keys raw public keys [RFC7250].
      Section 5.1 of [RFC7671] also discusses the security implications
      of this mode, mode; for example, it discusses key lifetimes and
      specifies that validity period enforcement is based solely on the
      TLSA RRset properties for this case.

   o  Section 13: Operational Considerations, 13 ("Operational Considerations") of [RFC7671], which
      discusses TLSA TTLs and signature validity periods.

   The specific DANE record for a DNS Privacy Server privacy server would take the
   form: form

      _853._tcp.[authentication-domain-name] for TLS

      _853._udp.[authentication-domain-name] for DTLS

8.2.1.  Direct DNS Lookup Meta-Queries

   The DNS client MAY choose to perform the DNS lookups meta-queries to retrieve
   the required DANE records itself.  The DNS queries meta-queries for such DANE
   records MAY use the Opportunistic encryption Privacy profile or be in the clear
   to avoid trust recursion.  The records MUST be validated using DNSSEC
   as described
   above in [RFC6698].

8.2.2.  TLS DNSSEC Chain extension Extension

   The DNS client MAY offer the TLS extension described in
   [I-D.ietf-tls-dnssec-chain-extension].
   [TLS-DNSSEC-Chain-Ext].  If the DNS server supports this extension,
   it can provide the full chain to the client in the handshake.

   If the DNS client offers the TLS DNSSEC Chain chain extension, it MUST be
   capable of validating the full DNSSEC authentication chain down to
   the leaf.  If the supplied DNSSEC chain does not validate, the client
   MUST ignore the DNSSEC chain and validate only via other supplied
   credentials.

9.  (D)TLS Protocol Profile

   This section defines the (D)TLS protocol profile of DNS-over-(D)TLS. DNS over (D)TLS.

   Clients and servers MUST adhere to the (D)TLS implementation
   recommendations and security considerations of [RFC7525] [RFC7525], except with
   respect to the (D)TLS version.

   Since encryption of DNS using (D)TLS is a green-field deployment greenfield deployment, DNS
   clients and servers MUST implement only (D)TLS 1.2 or later.  For
   example, implementing TLS (D)TLS 1.3 [I-D.ietf-tls-tls13] [TLS-1.3] [DTLS-1.3] is also an
   option.

   Implementations MUST NOT offer or provide TLS compression, since
   compression can leak significant amounts of information, especially
   to a network observer capable of forcing the user to do an arbitrary
   DNS lookup in the style of the CRIME Compression Ratio Info-leak Made Easy
   (CRIME) attacks [CRIME].

   Implementations compliant with this profile MUST implement all of the
   following items:

   o  TLS session resumption without server-side state [RFC5077] [RFC5077], which
      eliminates the need for the server to retain cryptographic state
      for longer than necessary necessary.  (This statement updates [RFC7858]). [RFC7858].)

   o  Raw public keys [RFC7250] [RFC7250], which reduce the size of the
      ServerHello,
      ServerHello and can be used by servers that cannot obtain
      certificates (e.g., DNS servers on private networks).  A client
      MUST only indicate support for raw public keys if it has an SPKI
      pinset
      pin set pre-configured (for interoperability reasons).

   Implementations compliant with this profile SHOULD implement all of the
   following items:

   o  TLS False Start [RFC7918] [RFC7918], which reduces round-trips round trips by allowing
      the TLS second flight of messages (ChangeCipherSpec) to also
      contain the (encrypted) DNS query.

   o  The Cached Information Extension [RFC7924] [RFC7924], which avoids
      transmitting the server's certificate and certificate chain if the
      client has cached that information from a previous TLS handshake.

   Guidance specific to TLS is provided in [RFC7858] [RFC7858], and that guidance
   specific to DTLS it is provided in [RFC8094].

10.  IANA Considerations

   This memo includes no request to IANA. document does not require any IANA actions.

11.  Security Considerations

   Security considerations discussed in [RFC7525], [RFC8094] [RFC8094], and
   [RFC7858] apply to this document.

   DNS Clients clients SHOULD implement (1) support for the mechanisms described
   in Section 8.2 and (2) offering a configuration option which that limits
   authentication to using only those mechanisms (i.e., with no fallback
   to pure PKIX based PKIX-based authentication) such that authenticating solely
   via the PKIX infrastructure can be avoided.

11.1.  Counter-measures  Countermeasures to DNS Traffic Analysis

   This section makes suggestions for measures that can reduce the
   ability of attackers to infer information pertaining to encrypted
   client queries by other means (e.g., via an analysis of encrypted
   traffic size, size or via monitoring of the unencrypted traffic from a DNS
   recursive resolver to an authoritative
   traffic). server).

   DNS-over-(D)TLS clients and servers SHOULD implement the following
   relevant DNS extensions extensions:

   o  EDNS(0)  Extension Mechanisms for DNS (EDNS(0)) padding [RFC7830], which
      allows encrypted queries and responses to hide their size size, making
      analysis of encrypted traffic harder.

   Guidance on padding policies for EDNS(0) is provided in
   [I-D.ietf-dprive-padding-policy]
   [EDNS0-Pad-Policies].

   DNS-over-(D)TLS clients SHOULD implement the following relevant DNS
   extensions
   extensions:

   o  Privacy Election using Client election per [RFC7871] ("Client Subnet in DNS Queries [RFC7871]. Queries").
      If a DNS client does not include an edns-client-subnet EDNS0 Client Subnet Option
      option with a SOURCE PREFIX-LENGTH set to 0 in a query, the DNS
      server may potentially leak client address information to the
      upstream authoritative DNS servers.  A DNS client ought to be able
      to inform the DNS Resolver resolver that it does not want any address
      information leaked, and the DNS Resolver resolver should honor that
      request.

13.

12.  References

13.1.

12.1.  Normative References

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

   [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
              "Transport Layer Security (TLS) Session Resumption without
              Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
              January 2008, <https://www.rfc-editor.org/info/rfc5077>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
              editor.org/info/rfc5246>.
              <https://www.rfc-editor.org/info/rfc5246>.

   [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, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125,
              March 2011, <https://www.rfc-editor.org/info/rfc6125>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <https://www.rfc-editor.org/info/rfc6347>.

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

   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
              Transport Layer Security (TLS) and Datagram Transport
              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
              June 2014, <https://www.rfc-editor.org/info/rfc7250>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525,
              May 2015, <https://www.rfc-editor.org/info/rfc7525>.

   [RFC7671]  Dukhovni, V. and W. Hardaker, "The DNS-Based
              Authentication of Named Entities (DANE) Protocol: Updates
              and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
              October 2015, <https://www.rfc-editor.org/info/rfc7671>.

   [RFC7830]  Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
              DOI 10.17487/RFC7830, May 2016, <https://www.rfc-
              editor.org/info/rfc7830>.
              <https://www.rfc-editor.org/info/rfc7830>.

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

   [RFC7918]  Langley, A., Modadugu, N., and B. Moeller, "Transport
              Layer Security (TLS) False Start", RFC 7918,
              DOI 10.17487/RFC7918, August 2016, <https://www.rfc-
              editor.org/info/rfc7918>.
              <https://www.rfc-editor.org/info/rfc7918>.

   [RFC7924]  Santesson, S. and H. Tschofenig, "Transport Layer Security
              (TLS) Cached Information Extension", RFC 7924,
              DOI 10.17487/RFC7924, July 2016, <https://www.rfc-
              editor.org/info/rfc7924>.
              <https://www.rfc-editor.org/info/rfc7924>.

   [RFC8094]  Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
              Transport Layer Security (DTLS)", RFC 8094,
              DOI 10.17487/RFC8094, February 2017, <https://www.rfc-
              editor.org/info/rfc8094>.

13.2.
              <https://www.rfc-editor.org/info/rfc8094>.

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

12.2.  Informative References

   [CRIME]    Rizzo, J. and T. Duong, "The CRIME Attack", 2012. Ekoparty
              Security Conference, 2012,
              <https://www.ekoparty.org/archivo/2012/eko8-CRIME.pdf>.

   [dnssec-trigger]
              NLnetLabs, "Dnssec-Trigger", May 2014, December 2017,
              <https://www.nlnetlabs.nl/projects/dnssec-trigger/>.

   [I-D.ietf-dprive-padding-policy]
              Mayrhofer, A., "Padding Policy for EDNS(0)", draft-ietf-
              dprive-padding-policy-01 (work in progress), July 2017.

   [I-D.ietf-tls-dnssec-chain-extension]
              Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE
              Record and DNSSEC Authentication Chain Extension for TLS",
              draft-ietf-tls-dnssec-chain-extension-04 (work in
              progress), June 2017.

   [I-D.ietf-tls-tls13]

   [DTLS-1.3]
              Rescorla, E., Tschofenig, H., and N. Modadugu, "The
              Datagram Transport Layer Security (TLS) (DTLS) Protocol
              Version 1.3", draft-ietf-tls-tls13-21 (work Work in progress),
              July 2017. Progress, draft-ietf-tls-dtls13-26,
              March 2018.

   [EDNS0-Pad-Policies]
              Mayrhofer, A., "Padding Policy for EDNS(0)", Work in
              Progress, draft-ietf-dprive-padding-policy-04,
              February 2018.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, DOI 10.17487/RFC2131, March 1997,
              <https://www.rfc-editor.org/info/rfc2131>.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
              <https://www.rfc-editor.org/info/rfc2132>.

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315,
              July 2003, <https://www.rfc-editor.org/info/rfc3315>.

   [RFC3646]  Droms, R., Ed., "DNS Configuration options for Dynamic
              Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
              DOI 10.17487/RFC3646, December 2003, <https://www.rfc-
              editor.org/info/rfc3646>.
              <https://www.rfc-editor.org/info/rfc3646>.

   [RFC7227]  Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
              S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
              BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
              <https://www.rfc-editor.org/info/rfc7227>.

   [RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
              Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
              December 2014, <https://www.rfc-editor.org/info/rfc7435>.

   [RFC7469]  Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
              Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469,
              April 2015, <https://www.rfc-editor.org/info/rfc7469>.

   [RFC7626]  Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
              DOI 10.17487/RFC7626, August 2015, <https://www.rfc-
              editor.org/info/rfc7626>.
              <https://www.rfc-editor.org/info/rfc7626>.

   [RFC7871]  Contavalli, C., van der Gaast, W., Lawrence, D., and W.
              Kumari, "Client Subnet in DNS Queries", RFC 7871,
              DOI 10.17487/RFC7871, May 2016, <https://www.rfc-
              editor.org/info/rfc7871>.
              <https://www.rfc-editor.org/info/rfc7871>.

   [TLS-1.3]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", Work in Progress, draft-ietf-tls-tls13-27,
              March 2018.

   [TLS-DNSSEC-Chain-Ext]
              Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE
              Record and DNSSEC Authentication Chain Extension for TLS",
              Work in Progress, draft-ietf-tls-dnssec-chain-
              extension-06, January 2018.

Appendix A.  Server capability probing Capability Probing and caching Caching by DNS clients Clients

   This section presents a non-normative discussion of how DNS clients
   might probe for for, and cache capabilities of of, privacy-enabling DNS
   servers.

   Deployment of both DNS-over-TLS DNS over TLS and DNS-over-DTLS DNS over DTLS will be gradual.
   Not all servers will support one or both of these protocols protocols, and the
   well-known port might be blocked by some middleboxes.  Clients will
   be expected to keep track of servers that support DNS-over-TLS DNS over TLS and/or
   DNS-over-DTLS, and
   DNS over DTLS, as well as those that have been previously
   authenticated.

   If no server capability information is available available, then (unless
   otherwise specified by the configuration of the DNS client) DNS
   clients that implement both TLS and DTLS should try to authenticate
   using both protocols before failing or falling back to a an
   unauthenticated or clear text connections. cleartext connection.  DNS clients using an
   Opportunistic Usage Privacy profile should try all available servers
   (possibly in parallel) in order to obtain an authenticated and
   encrypted connection before falling back.  (RATIONALE: This approach
   can increase latency while discovering server capabilities but
   maximizes the chance of sending the query over an authenticated and
   encrypted connection.)

12.

Acknowledgments

   Thanks to the authors of both [RFC8094] and [RFC7858] for laying the
   ground work that
   groundwork for this draft builds on document and for reviewing the contents.  The
   authors would also like to thank John Dickinson, Shumon Huque,
   Melinda Shore, Gowri Visweswaran, Ray Bellis, Stephane Bortzmeyer,
   Jinmei Tatuya, Paul Hoffman, Christian Huitema Huitema, and John Levine for
   review and discussion of the ideas presented here.

Authors' Addresses

   Sara Dickinson
   Sinodun Internet Technologies
   Magdalen Centre
   Oxford Science Park
   Oxford  OX4 4GA
   UK
   United Kingdom

   Email: sara@sinodun.com
   URI:   http://sinodun.com   https://www.sinodun.com/

   Daniel Kahn Gillmor
   ACLU
   125 Broad Street, 18th Floor
   New York York, NY  10004
   USA
   United States of America

   Email: dkg@fifthhorseman.net

   Tirumaleswar Reddy
   McAfee, Inc.
   Embassy Golf Link Business Park
   Bangalore, Karnataka  560071
   India

   Email: TirumaleswarReddy_Konda@McAfee.com