summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8310.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8310.txt')
-rw-r--r--doc/rfc/rfc8310.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc8310.txt b/doc/rfc/rfc8310.txt
new file mode 100644
index 0000000..21316c5
--- /dev/null
+++ b/doc/rfc/rfc8310.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) S. Dickinson
+Request for Comments: 8310 Sinodun
+Updates: 7858 D. Gillmor
+Category: Standards Track ACLU
+ISSN: 2070-1721 T. Reddy
+ McAfee
+ March 2018
+
+
+ Usage Profiles for DNS over TLS and DNS over DTLS
+
+Abstract
+
+ This document discusses 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
+ 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. This document
+ updates RFC 7858.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8310.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dickinson, et al. Standards Track [Page 1]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 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
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dickinson, et al. Standards Track [Page 2]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 2. Terminology .....................................................6
+ 3. Scope ...........................................................7
+ 4. Discussion ......................................................8
+ 5. Usage Profiles ..................................................8
+ 5.1. DNS Resolution ............................................11
+ 6. Authentication in DNS over (D)TLS ..............................11
+ 6.1. DNS-over-(D)TLS Startup Configuration Problems ............11
+ 6.2. Credential Verification ...................................12
+ 6.3. Summary of Authentication Mechanisms ......................12
+ 6.4. Combining Authentication Mechanisms .......................15
+ 6.5. Authentication in Opportunistic Privacy ...................15
+ 6.6. Authentication in Strict Privacy ..........................16
+ 6.7. Implementation Guidance ...................................16
+ 7. Sources of Authentication Domain Names .........................17
+ 7.1. Full Direct Configuration .................................17
+ 7.2. Direct Configuration of ADN Only ..........................17
+ 7.3. Dynamic Discovery of ADN ..................................17
+ 7.3.1. DHCP ...............................................18
+ 8. Credential Verification Based on Authentication Domain Name ....18
+ 8.1. Authentication Based on PKIX Certificate ..................18
+ 8.2. DANE ......................................................19
+ 8.2.1. Direct DNS Meta-Queries ............................20
+ 8.2.2. TLS DNSSEC Chain Extension .........................20
+ 9. (D)TLS Protocol Profile ........................................20
+ 10. IANA Considerations ...........................................21
+ 11. Security Considerations .......................................21
+ 11.1. Countermeasures to DNS Traffic Analysis ..................22
+ 12. References ....................................................22
+ 12.1. Normative References .....................................22
+ 12.2. Informative References ...................................24
+ Appendix A. Server Capability Probing and Caching by DNS Clients ..26
+ Acknowledgments ...................................................27
+ Authors' Addresses ................................................27
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dickinson, et al. Standards Track [Page 3]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+1. Introduction
+
+ DNS privacy issues are discussed in [RFC7626]. The specific issues
+ described in [RFC7626] that are most relevant to this document are
+
+ o Passive attacks that eavesdrop on cleartext DNS transactions on
+ the wire (Section 2.4 of [RFC7626]) and
+
+ o Active attacks that redirect clients to rogue servers to monitor
+ DNS traffic (Section 2.5.3 of [RFC7626]).
+
+ Mitigating these attacks increases the privacy of DNS 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
+
+ o "Specification for DNS over Transport Layer Security (TLS)"
+ [RFC7858], referred to here as simply "DNS over TLS".
+
+ o "DNS over Datagram Transport Layer Security (DTLS)" [RFC8094],
+ referred to here as simply "DNS over DTLS". Note that [RFC8094]
+ is an Experimental specification.
+
+ Both documents are limited in scope to communications between stub
+ clients and recursive resolvers, and the same scope is applied to
+ this document (see Sections 2 and 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 published.
+
+ This document specifies two usage profiles (Strict Privacy and
+ Opportunistic Privacy) for DTLS [RFC6347] and TLS [RFC5246] that
+ provide improved levels of mitigation for the attacks described above
+ compared to using only cleartext DNS.
+
+ Section 5 presents a generalized discussion of usage profiles by
+ separating the usage profile, which is based purely on the security
+ properties it offers the user, from the specific mechanism or
+ mechanisms that are used for DNS server authentication. The profiles
+ described are
+
+ o A Strict Privacy profile, which requires an encrypted connection
+ and successful authentication of the DNS server; this mitigates
+ both passive eavesdropping and client redirection (at the expense
+ of providing no DNS service if an encrypted, authenticated
+ connection is not available).
+
+
+
+Dickinson, et al. Standards Track [Page 4]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+ o An Opportunistic Privacy profile, which will attempt, but does not
+ require, encryption and successful authentication; it therefore
+ provides limited or no mitigation for such attacks but maximizes
+ the chance of DNS service.
+
+ The above 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), the usage profile will
+ determine if the connection should proceed, fall back, or fail.
+
+ One authentication mechanism is already described in [RFC7858].
+ [RFC7858] specifies an authentication mechanism for DNS over TLS that
+ is based on Subject Public Key Info (SPKI) in the context of a
+ specific case of a Strict Privacy profile using that single
+ authentication mechanism. Therefore, the "out-of-band key-pinned
+ privacy profile" described in [RFC7858] would qualify as a "Strict
+ Privacy profile" that used SPKI pinning for authentication.
+
+ This document extends the use of 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. That is,
+ the mechanism for SPKI pin sets as described in [RFC7858] MAY be used
+ with DNS over (D)TLS.
+
+ This document also describes a number of additional authentication
+ mechanisms, all of which specify how a DNS client should authenticate
+ a DNS server based on an "authentication domain name". In
+ particular, the following 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 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.
+
+ This document defines a (D)TLS protocol profile for use with 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
+ and (2) support all currently specified authentication mechanisms.
+
+
+
+
+Dickinson, et al. Standards Track [Page 5]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+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
+ 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 document:
+
+ o DNS client: 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 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. Note that, as used in this document,
+ this term does not apply to authoritative servers.
+
+ o Privacy-enabling DNS server: A DNS server that implements
+ DNS over TLS [RFC7858] and may optionally implement 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: Used for brevity; refers to both Transport Layer Security
+ [RFC5246] and Datagram Transport Layer Security [RFC6347].
+ Specific terms will be used for any text that applies to either
+ protocol alone.
+
+ o DNS over (D)TLS: Used for brevity; refers to both DNS over TLS
+ [RFC7858] and DNS over DTLS [RFC8094]. Specific terms will be
+ used for any 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 pin sets: [RFC7858] describes the use of cryptographic
+ digests to "pin" public key information in a manner similar to
+ HTTP Public Key Pinning (HPKP) [RFC7469]. An SPKI pin set is a
+ collection of these pins that constrains a DNS server.
+
+
+
+
+
+
+
+
+
+Dickinson, et al. Standards Track [Page 6]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+ o Authentication information: Information a DNS client may use as
+ the basis of an authentication mechanism. In this context, this
+ information can be either
+
+ * an SPKI pin set or
+
+ * an authentication domain name
+
+ o Reference 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 that proves its
+ identity for authentication purposes. Credentials discussed here
+ include
+
+ * a PKIX certificate
+
+ * a DNSSEC-validated chain to a TLSA record
+
+ but may also include SPKI pin sets.
+
+3. Scope
+
+ This document is limited to describing
+
+ o Usage profiles based on general authentication mechanisms.
+
+ o The details of domain-name-based authentication of DNS servers by
+ DNS clients (as defined in Section 2).
+
+ o The (D)TLS profiles needed to support authentication in
+ DNS over (D)TLS.
+
+ As such, the following topics are out of 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 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.
+
+
+
+
+
+
+Dickinson, et al. Standards Track [Page 7]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+4. Discussion
+
+ One way to mitigate eavesdropping on cleartext DNS transactions by
+ passive attackers is to encrypt the query (and response). Such
+ encryption typically provides integrity protection as a side effect;
+ this means that on-path attackers cannot simply inject bogus DNS
+ responses. To also mitigate active attackers pretending to be the
+ server, the client must authenticate the (D)TLS connection to the
+ server.
+
+ This document discusses 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
+ is a concept distinct from a usage policy or usage model; a usage
+ policy or usage model might dictate which profile should be used in a
+ particular context (enterprise vs. coffee shop), with a particular
+ set of DNS servers or with reference to other external factors. A
+ description of the variety of usage policies is out of scope for this
+ document but may be the subject of future work.
+
+ The term "privacy-enabling DNS server" is used throughout this
+ document. This is a DNS server that
+
+ o MUST implement DNS over TLS [RFC7858].
+
+ o MAY implement 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 available to increase the
+ privacy of DNS transactions. This choice is briefly discussed in
+ both [RFC7858] and [RFC8094]. These usage profiles are
+
+ o Strict Privacy profile: The DNS client requires both an encrypted
+ and authenticated connection to a privacy-enabling DNS 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 both passive and
+ active attacks, thereby providing the client with the best
+ available privacy for DNS. This profile is discussed in detail in
+ Section 6.6.
+
+
+
+
+Dickinson, et al. Standards Track [Page 8]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+ o Opportunistic Privacy profile: The DNS client uses Opportunistic
+ Security as described in [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], it might result in
+
+ * an encrypted and authenticated connection
+
+ * an encrypted connection
+
+ * a cleartext connection
+
+ depending on the fallback logic of the client, the available
+ authentication information, and the capabilities of the DNS
+ server. In all these cases, the DNS client is willing to continue
+ with a connection to the DNS 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, depending on the
+ combination of factors described above. If all the configured DNS
+ servers are DNS privacy servers, then it can provide protection
+ against passive attacks and might protect against active ones.
+
+ Both profiles can include an initial meta-query (performed using
+ Opportunistic 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 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 on the meta-query is possible. Such an
+ attack could result in a Strict Privacy profile client connecting to
+ a server it cannot authenticate (and therefore not obtaining DNS
+ service) or an Opportunistic Privacy client connecting to a server
+ controlled by the attacker. DNSSEC validation can detect the attack
+ on the meta-query, which may result in the client not obtaining DNS
+ service (for both usage profiles), depending on its DNSSEC validation
+ policy. See Section 7.2 for more discussion.
+
+ To compare the two usage profiles, Table 1 below shows a successful
+ Strict Privacy profile alongside the three possible outcomes of an
+ Opportunistic Privacy profile. In the best-case scenario for the
+ Opportunistic Privacy profile (an authenticated and encrypted
+
+
+
+Dickinson, et al. Standards Track [Page 9]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+ connection), it is equivalent to the Strict Privacy profile. In the
+ worst-case scenario, it is equivalent to cleartext. Clients using
+ the Opportunistic Privacy profile SHOULD try for the best case but
+ MAY fall back to the intermediate case and, eventually, the worst-
+ case scenario, in order to obtain a response. One reason to fall
+ back without trying every available privacy-enabling DNS server is if
+ latency is more important than attack mitigation; see Appendix A.
+ The Opportunistic Privacy profile therefore provides varying
+ protection, depending on what kind of connection is actually 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; the
+ "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, then the user should assume (detect) that the connection is
+ subject to both active and passive attacks, since the DNS queries are
+ sent in cleartext. This might be particularly useful if a new
+ connection to a certain server is unencrypted when all previous
+ connections were encrypted. Similarly, if the user is informed that
+ an encrypted but unauthenticated connection was used, then the user
+ can detect that the connection may be subject to active attacks. In
+ other words, for the cases where no protection is provided against an
+ attacker (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 by Usage Profile and Type of Attacker
+
+ The Strict Privacy profile provides the best attack mitigation and
+ therefore SHOULD always be implemented in DNS clients that implement
+ the Opportunistic Privacy profile.
+
+ A DNS client that implements DNS over (D)TLS SHOULD NOT be configured
+ by default to use only cleartext.
+
+
+
+
+Dickinson, et al. Standards Track [Page 10]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+ The choice between the two profiles depends on a number of factors,
+ including which is more important to the particular client:
+
+ o DNS service, at the cost of no attack mitigation (Opportunistic
+ Privacy) or
+
+ o Best available attack mitigation, at the potential cost of no DNS
+ service (Strict Privacy).
+
+ Additionally, the two profiles require varying levels of
+ configuration (or a trusted relationship with a provider) and DNS
+ server 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 SHOULD provide at least
+ one credential (Section 2) so that those DNS clients that wish to use
+ the Strict Privacy profile are able to do so.
+
+5.1. DNS Resolution
+
+ A DNS client SHOULD select a particular usage profile when resolving
+ a query. A DNS client MUST NOT fall back from Strict Privacy to
+ Opportunistic Privacy during the resolution of a given query, as this
+ could invalidate the protection offered against attackers. It is
+ anticipated that DNS clients will use a particular 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
+
+ This section describes authentication mechanisms and how they can be
+ used in either Strict or Opportunistic Privacy for 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.
+
+
+
+
+
+Dickinson, et al. Standards Track [Page 11]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+ One advantage of this domain-name-based approach is that it
+ encourages the association of stable, human-recognizable identifiers
+ with secure DNS service providers.
+
+6.2. Credential Verification
+
+ Verification of SPKI pin sets is discussed in [RFC7858].
+
+ In terms of domain-name-based verification, once an authentication
+ domain name is known for a DNS server, a choice of authentication
+ mechanisms can be used for credential verification. Section 8
+ discusses these mechanisms -- namely, PKIX certificate-based
+ authentication and 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. Table 2 below indicates how the DNS client obtains
+ information to use for authentication for each option: either
+ statically via direct configuration or dynamically. Of course, the
+ Opportunistic Privacy profile does not require 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dickinson, et al. Standards Track [Page 12]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+ +---+------------+-------------+------------------------------------+
+ | # | Static | Dynamically | Short name: Description |
+ | | Config | Obtained | |
+ +---+------------+-------------+------------------------------------+
+ | 1 | SPKI + IP | | SPKI: SPKI 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 Privacy |
+ | | | | meta-queries to a NP DNS server |
+ | | | | 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 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 pin set(s); IP == IP Address;
+ ADN == Authentication Domain Name; NP == Network-Provided;
+ PE == 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" from Table 2), indicating
+ attractive attributes with a "+" and undesirable attributes
+ with a "-".
+
+ 1. SPKI
+
+ + Minimal leakage (note that the ADN is always leaked in the
+ Server Name Indication (SNI) field in the ClientHello in TLS
+ when communicating with a privacy-enabling DNS server)
+
+ - Overhead of ongoing key management required
+
+
+
+Dickinson, et al. Standards Track [Page 13]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+ 2. ADN
+
+ + Minimal leakage
+
+ + One-off direct configuration only
+
+ 3. ADN only
+
+ + Minimal one-off direct configuration; only a human-recognizable
+ domain name needed
+
+ - A/AAAA meta-queries leaked to network-provided DNS server that
+ may be subject to active attack (attack can be mitigated by
+ DNSSEC 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 Privacy profile
+
+ 5. DANE
+
+ The ADN and/or IP may be obtained statically or dynamically, and
+ the relevant attributes of that method apply.
+
+ + DANE options (e.g., matching on entire certificate)
+
+ - Requires a DNSSEC-validating stub implementation (the
+ deployment of which is limited at the time of this writing)
+
+ - DNSSEC chain meta-queries leaked to 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, and
+ the relevant attributes of that method apply.
+
+ + Reduced latency compared with DANE
+
+ + No network-provided DNS server required if ADN and IP
+ statically configured
+
+
+
+
+Dickinson, et al. Standards Track [Page 14]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+ + DANE options (e.g., matching on entire certificate)
+
+ - Requires a DNSSEC-validating stub implementation
+
+6.4. Combining Authentication Mechanisms
+
+ This document does not make explicit recommendations about how an
+ authentication mechanism based on SPKI pin sets should be combined
+ with a domain-based mechanism from an operator perspective. However,
+ it can be envisaged that a DNS server operator may wish to make both
+ an SPKI pin set and an authentication domain name available to allow
+ clients to choose which mechanism to use. Therefore, the following
+ 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 an SPKI pin set for a DNS server SHOULD match on both a
+ valid credential for the authentication domain name and a valid SPKI
+ pin set (if both are available) when connecting to that DNS server.
+ In this case, the client SHOULD treat individual SPKI pins as
+ specified in Section 2.6 of [RFC7469] with regard to 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]) that MAY be used for DNS over (D)TLS is described in
+ [RFC7858] and is further specified in this document.
+
+ DNS clients that issue queries under an Opportunistic Privacy profile
+ and 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 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 that successfully authenticated (see Section 5)
+ might not continue to use the failing server if there were
+ alternative servers available.
+
+
+
+
+
+Dickinson, et al. Standards Track [Page 15]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+ 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., where all the configured servers
+ support 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 that
+ attempt to redirect clients to rogue DNS servers.
+
+ A DNS client requiring Strict Privacy MUST use either (1) one of the
+ sources listed in Section 7, to obtain an authentication domain name
+ for the server it contacts or (2) an SPKI 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 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] MAY be used during network configuration, with the
+ intent to transition to the designated privacy-enabling DNS servers
+ after captive-portal registration. If using a Strict Privacy
+ profile, the system MUST alert by some means that the DNS is not
+ private during such a bootstrap operation.
+
+6.7. Implementation Guidance
+
+ Section 9 describes the (D)TLS profile for DNS over (D)TLS.
+ Additional considerations relating to general implementation
+ guidelines are discussed in both Section 11 and Appendix A.
+
+
+
+
+
+
+Dickinson, et al. Standards Track [Page 16]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+7. Sources of Authentication Domain Names
+
+7.1. Full Direct Configuration
+
+ DNS clients may be directly and securely provisioned with the
+ authentication domain name of each privacy-enabling DNS server -- for
+ example, using a 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 that were obtained via an out-of-band mechanism.
+
+7.2. Direct Configuration of ADN 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 example, using a 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 Recursive Name Server option
+ [RFC3646]). It can then use meta-queries performed using an
+ Opportunistic Privacy profile to an untrusted recursive DNS resolver
+ to establish the IP address of the intended privacy-enabling DNS
+ resolver by doing a lookup of A/AAAA records. A DNSSEC-validating
+ client SHOULD apply the same validation policy to the A/AAAA
+ meta-queries as it does to other queries. A client that does not
+ validate DNSSEC 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 DNS resolver, using the IP address 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 meta-query.
+
+7.3. Dynamic Discovery of ADN
+
+ This section discusses the general case of a DNS client discovering
+ both the authentication domain name and IP address dynamically. At
+ the time of this writing, this is not possible by any standard means.
+ However, since, for example, a future DHCP extension could (in
+ principle) provide this mechanism, the required security properties
+ of such mechanisms are outlined here.
+
+
+
+
+
+
+Dickinson, et al. Standards Track [Page 17]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+ When using a Strict 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 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]) 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; 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, the issues outlined in Section 8 of [RFC7227] should be
+ taken into account, as should the security considerations discussed
+ in Section 23 of [RFC3315].
+
+ This document does not attempt to describe secured and trusted
+ relationships to DHCP servers, as this is purely a DHCP issue (and
+ still open, at the time of this writing). Whilst some implementation
+ work is in progress to secure IPv6 connections for DHCP, IPv4
+ connections have received little or no implementation attention in
+ this area.
+
+8. Credential Verification Based on Authentication Domain Name
+
+8.1. Authentication Based on PKIX Certificate
+
+ 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 validation
+ techniques as described in [RFC6125] to compare the domain name to
+ the certificate provided.
+
+ A DNS client constructs one reference identifier for the server based
+ on the authentication domain name: a DNS-ID, which is simply the
+ authentication domain name itself.
+
+ If the reference identifier is found (as described in Section 6 of
+ [RFC6125]) in the PKIX certificate's subjectAltName extension, the
+ DNS client should accept the certificate for the server.
+
+
+
+
+Dickinson, et al. Standards Track [Page 18]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+ A compliant DNS client MUST only inspect the certificate's
+ subjectAltName extension for the reference identifier. In
+ particular, it MUST NOT inspect the Subject field itself.
+
+8.2. DANE
+
+ DANE [RFC6698] provides various mechanisms using DNSSEC to anchor
+ trust for certificates and raw public keys. However, this requires
+ the DNS client to have an authentication domain name (which must be
+ obtained via a trusted source) for the DNS privacy server.
+
+ This section assumes a solid understanding of both DANE [RFC6698] and
+ DANE 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.
+
+ Note that [RFC6698] says
+
+ 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.
+
+ Note that [RFC7671] covers the following topics:
+
+ o Sections 4.1 ("Opportunistic Security and PKIX Usages") and 14
+ ("Security Considerations") of [RFC7671], which both discuss the
+ use of schemes based on trust anchors and end entities (PKIX-TA(0)
+ and PKIX-EE(1), respectively) for Opportunistic Security.
+
+ o Section 5 ("Certificate-Usage-Specific DANE Updates and
+ Guidelines") of [RFC7671] -- specifically, Section 5.1 of
+ [RFC7671], which outlines the combination of certificate usage
+ DANE-EE(3) and selector SPKI(1) with raw public keys [RFC7250].
+ Section 5.1 of [RFC7671] also discusses the security implications
+ of this 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") of [RFC7671], which
+ discusses TLSA TTLs and signature validity periods.
+
+ The specific DANE record for a DNS privacy server would take the form
+
+ _853._tcp.[authentication-domain-name] for TLS
+
+ _853._udp.[authentication-domain-name] for DTLS
+
+
+
+
+Dickinson, et al. Standards Track [Page 19]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+8.2.1. Direct DNS Meta-Queries
+
+ The DNS client MAY choose to perform the DNS meta-queries to retrieve
+ the required DANE records itself. The DNS meta-queries for such DANE
+ records MAY use the Opportunistic Privacy profile or be in the clear
+ to avoid trust recursion. The records MUST be validated using DNSSEC
+ as described in [RFC6698].
+
+8.2.2. TLS DNSSEC Chain Extension
+
+ The DNS client MAY offer the TLS extension described in
+ [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 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.
+
+ Clients and servers MUST adhere to the (D)TLS implementation
+ recommendations and security considerations of [RFC7525], except with
+ respect to the (D)TLS version.
+
+ Since encryption of DNS using (D)TLS is a greenfield deployment, DNS
+ clients and servers MUST implement only (D)TLS 1.2 or later. For
+ example, implementing (D)TLS 1.3 [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 Compression Ratio Info-leak Made Easy
+ (CRIME) attacks [CRIME].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dickinson, et al. Standards Track [Page 20]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+ Implementations compliant with this profile MUST implement the
+ following items:
+
+ o TLS session resumption without server-side state [RFC5077], which
+ eliminates the need for the server to retain cryptographic state
+ for longer than necessary. (This statement updates [RFC7858].)
+
+ o Raw public keys [RFC7250], which reduce the size of the
+ 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
+ pin set pre-configured (for interoperability reasons).
+
+ Implementations compliant with this profile SHOULD implement the
+ following items:
+
+ o TLS False Start [RFC7918], which reduces round trips by allowing
+ the TLS second flight of messages (ChangeCipherSpec) to also
+ contain the (encrypted) DNS query.
+
+ o The Cached Information Extension [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], and guidance
+ specific to DTLS is provided in [RFC8094].
+
+10. IANA Considerations
+
+ This document does not require any IANA actions.
+
+11. Security Considerations
+
+ Security considerations discussed in [RFC7525], [RFC8094], and
+ [RFC7858] apply to this document.
+
+ DNS clients SHOULD implement (1) support for the mechanisms described
+ in Section 8.2 and (2) offering a configuration option that limits
+ authentication to using only those mechanisms (i.e., with no fallback
+ to pure PKIX-based authentication) such that authenticating solely
+ via the PKIX infrastructure can be avoided.
+
+
+
+
+
+
+
+
+
+
+Dickinson, et al. Standards Track [Page 21]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+11.1. 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 or via monitoring of the unencrypted traffic from a DNS
+ recursive resolver to an authoritative server).
+
+ DNS-over-(D)TLS clients and servers SHOULD implement the following
+ relevant DNS extensions:
+
+ o Extension Mechanisms for DNS (EDNS(0)) padding [RFC7830], which
+ allows encrypted queries and responses to hide their size, making
+ analysis of encrypted traffic harder.
+
+ Guidance on padding policies for EDNS(0) is provided in
+ [EDNS0-Pad-Policies].
+
+ DNS-over-(D)TLS clients SHOULD implement the following relevant DNS
+ extensions:
+
+ o Privacy election per [RFC7871] ("Client Subnet in DNS Queries").
+ If a DNS client does not include an edns-client-subnet EDNS0
+ option with 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 that it does not want any address
+ information leaked, and the DNS resolver should honor that
+ request.
+
+12. References
+
+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>.
+
+ [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>.
+
+
+
+Dickinson, et al. Standards Track [Page 22]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+ [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>.
+
+ [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>.
+
+
+
+
+Dickinson, et al. Standards Track [Page 23]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+ [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>.
+
+ [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>.
+
+ [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>.
+
+ [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", Ekoparty
+ Security Conference, 2012,
+ <https://www.ekoparty.org/archivo/2012/eko8-CRIME.pdf>.
+
+ [dnssec-trigger]
+ NLnetLabs, "Dnssec-Trigger", December 2017,
+ <https://www.nlnetlabs.nl/projects/dnssec-trigger/>.
+
+ [DTLS-1.3]
+ Rescorla, E., Tschofenig, H., and N. Modadugu, "The
+ Datagram Transport Layer Security (DTLS) Protocol
+ Version 1.3", Work in 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>.
+
+
+
+Dickinson, et al. Standards Track [Page 24]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+ [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>.
+
+ [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>.
+
+ [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>.
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+Dickinson, et al. Standards Track [Page 25]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+Appendix A. Server Capability Probing and Caching by DNS Clients
+
+ This section presents a non-normative discussion of how DNS clients
+ might probe for, and cache capabilities of, privacy-enabling DNS
+ servers.
+
+ Deployment of both DNS over TLS and DNS over DTLS will be gradual.
+ Not all servers will support one or both of these 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 and/or
+ DNS over DTLS, as well as those that have been previously
+ authenticated.
+
+ If no server capability information is 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 an
+ unauthenticated or cleartext connection. DNS clients using an
+ Opportunistic 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.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dickinson, et al. Standards Track [Page 26]
+
+RFC 8310 Usage Profiles for DNS over (D)TLS March 2018
+
+
+Acknowledgments
+
+ Thanks to the authors of both [RFC8094] and [RFC7858] for laying the
+ groundwork for this 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, 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
+ United Kingdom
+
+ Email: sara@sinodun.com
+ URI: https://www.sinodun.com/
+
+
+ Daniel Kahn Gillmor
+ ACLU
+ 125 Broad Street, 18th Floor
+ New York, NY 10004
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dickinson, et al. Standards Track [Page 27]
+