From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8310.txt | 1515 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1515 insertions(+) create mode 100644 doc/rfc/rfc8310.txt (limited to 'doc/rfc/rfc8310.txt') 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, + . + + [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, . + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + . + + + +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, + . + + [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, . + + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, + January 2012, . + + [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, . + + [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, . + + [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, . + + [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, . + + [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, + DOI 10.17487/RFC7830, May 2016, + . + + [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, . + + + + +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, + . + + [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security + (TLS) Cached Information Extension", RFC 7924, + DOI 10.17487/RFC7924, July 2016, + . + + [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram + Transport Layer Security (DTLS)", RFC 8094, + DOI 10.17487/RFC8094, February 2017, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in + RFC 2119 Key Words", BCP 14, RFC 8174, + DOI 10.17487/RFC8174, May 2017, + . + +12.2. Informative References + + [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", Ekoparty + Security Conference, 2012, + . + + [dnssec-trigger] + NLnetLabs, "Dnssec-Trigger", December 2017, + . + + [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, + . + + [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, + . + + + +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, . + + [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic + Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, + DOI 10.17487/RFC3646, December 2003, + . + + [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, + . + + [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection + Most of the Time", RFC 7435, DOI 10.17487/RFC7435, + December 2014, . + + [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning + Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, + April 2015, . + + [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, + DOI 10.17487/RFC7626, August 2015, + . + + [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, + . + + [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] + -- cgit v1.2.3