]> Sinodun Internet Technologies

Magdalen Centre Oxford Science Park Oxford OX4 4GA UK sara@sinodun.com http://sinodun.com

ACLU

125 Broad Street, 18th Floor New York NY 10004 USA dkg@fifthhorseman.net

Cisco Systems, Inc.

Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore Karnataka 560103 India tireddy@cisco.com

int dprive DNS transport This document describes how a DNS client can use a domain name to authenticate a DNS server that uses Transport Layer Security (TLS) and Datagram TLS (DTLS). Additionally, it defines (D)TLS profiles for DNS clients and servers implementing DNS-over-TLS and DNS-over-DTLS.

DNS Privacy issues are discussed in . Two documents that provide DNS privacy between DNS clients and DNS servers are: Specification for DNS over Transport Layer Security (TLS), referred to here as simply 'DNS-over-TLS' DNS-over-DTLS (DNSoD), referred to here simply as 'DNS-over-DTLS'. Note that this document has the Intended status of Experimental. Both documents are limited in scope to encrypting DNS messages between stub clients and recursive resolvers and the same scope is applied to this document (see and ). The proposals here might be adapted or extended in future to be used for recursive clients and authoritative servers, but this application is out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group per its current charter. This document defines two Usage Profiles (Strict and Opportunistic) for DTLS and TLS which define the security properties a user should expect when using that profile to connect to the available DNS servers. In essence: the Strict Profile requires an encrypted connection and successful authentication of the DNS server which provides strong privacy guarantees (at the expense of providing no DNS service if this is not available). the Opportunistic Profile will attempt, but does not require, encryption and successful authentication; it therefore provides no privacy guarantees but offers maximum chance of DNS service. Additionally, a number of authentication mechanisms are defined that specify how a DNS client should authenticate a DNS server based on a domain name. In particular, the following is described: How a DNS client can obtain a domain name for a DNS server to use for (D)TLS authentication. What are the acceptable credentials a DNS server can present to prove its identity for (D)TLS authentication based on a given domain name. How a DNS client can verify that any given credential matches the domain name obtained for a DNS server. It should be noted that includes a description of a specific case of a Strict Usage Profile using a single authentication mechanism (SPKI pinning). This draft generalises the picture by separating the Usage Profile, which is based purely on the security properties it offers the user, from the specific mechanism that is used for authentication. Therefore the "Out-of-band Key-pinned Privacy Profile" described in the DNS-over-TLS draft would qualify as a "Strict Usage Profile" that used SPKI pinning for authentication. This document also defines a (D)TLS protocol profile for use with DNS. This profile defines the configuration options and protocol extensions required of both parties to optimize connection establishment and session resumption for transporting DNS, and to support the authentication mechanisms defined here.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . Several terms are used specifically in the context of this draft: DNS client: a DNS stub resolver or forwarder/proxy. In the case of a forwarder, the term "DNS client" is used to discuss the side that sends queries. DNS server: a DNS recursive resolver or forwarder/proxy. In the case of a forwarder, the term "DNS server" is used to discuss the side that responds to queries. Privacy-enabling DNS server: A DNS server that: MUST implement DNS-over-TLS and MAY implement DNS-over-DTLS. Can offer at least one of the credentials described in . Implements the (D)TLS profile described in . (D)TLS: For brevity this term is used for statements that apply to both Transport Layer Security and Datagram Transport Layer Security. Specific terms will be used for any statement that applies to either protocol alone. DNS-over-(D)TLS: For brevity this term is used for statements that apply to both DNS-over-TLS and DNS-over-DTLS. Specific terms will be used for any statement that applies to either protocol alone. Credential: Information available for a DNS server which proves its identity for authentication purposes. Credentials discussed here include: PKIX certificate DNSSEC validated chain to a TLSA record but may also include SPKI pinsets. SPKI Pinsets: describes the use of cryptographic digests to "pin" public key information in a manner similar to HPKP. An SPKI pinset is a collection of these pins that constrains a DNS server. Reference Identifier: a Reference Identifier as described in , constructed by the DNS client when performing TLS authentication of a DNS server.

This document is limited to domain-name-based authentication of DNS servers by DNS clients (as defined in the terminology section), and the (D)TLS profiles needed to support this. As such, the following things are out of scope: Authentication of authoritative servers by recursive resolvers. Authentication of DNS clients by DNS servers. SPKI-pinset-based authentication. This is defined in . However, does describe how to combine that approach with the domain name based mechanism described here. Any server identifier other than domain names, including IP address, organizational name, country of origin, etc.

To protect against passive attacks DNS privacy requires encrypting the query (and response). Such encryption typically provides integrity protection as a side-effect, which means on-path attackers cannot simply inject bogus DNS responses. For DNS privacy to also provide protection against active attackers pretending to be the server, the client must authenticate the server. This draft discusses Usage Profiles, which provide differing levels of privacy guarantees 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 distinct concept to a usage policy or usage model, which 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 of this document, but may be the subject of future work.

A DNS client has a choice of privacy Usage Profiles available. This choice is briefly discussed in both and . In summary, the usage profiles are: Strict Privacy: 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 information it can use to authenticate the server. This profile can include some initial meta queries (performed using Opportunistic Privacy) to securely obtain the IP address and authentication information for the privacy-enabling DNS server to which the DNS client will subsequently connect. The rationale for this is that requiring Strict Privacy for such meta queries would introduce significant deployment obstacles. This profile provides strong privacy guarantees to the client. This Profile is discussed in detail in . Opportunistic Privacy: the DNS client uses Opportunistic Security as described in "... the use of cleartext as the baseline communication security policy, with encryption and authentication negotiated and applied to the communication when available." The use of Opportunistic Privacy is intended to support incremental deployment of security capabilities with a view to widespread adoption of Strict Privacy. It should be employed when the DNS client might otherwise settle for cleartext; it provides the maximum protection available. As described in it might result in an encrypted and authenticated connection an encrypted connection a clear text connection hard failure depending on the fallback logic of the client, the available authentication information and the capabilities of the DNS Server. In the first three cases the DNS client is willing to continue with a connection to the DNS Server and perform resolution of queries. To compare the two Usage profiles the table below shows successful Strict Privacy along side the 3 possible successful outcomes of Opportunistic Privacy. In the best case scenario for Opportunistic Privacy (an authenticated and encrypted connection) it is equivalent to Strict Privacy. In the worst case scenario it is equivalent to clear text. Clients using Opportunistic Privacy SHOULD try for the best case but MAY fallback to intermediate cases and eventually the worst case scenario in order to obtain a response. It therefore provides no privacy guarantee to the user and varying protection depending on what kind of connection is actually used. Note that there is no requirement in Opportunistic Security to notify the user 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 attack since the DNS queries are sent in clear text. 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 user can detect that the connection may be subject to active attack. This is discussed in . 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 Since Strict Privacy provides the strongest privacy guarantees it is preferable to Opportunistic Privacy. However since the two profiles require varying levels of configuration (or a trusted relationship with a provider) and DNS server capabilities, DNS clients will need to carefully select which profile to use based on their communication privacy needs. For the case where a client has a trusted relationship with a provider it is expected that the provider will provide either a domain name or SPKI pinset via a secure out-of-band mechanism and therefore Strict Privacy should be used.

A DNS client SHOULD select a particular usage profile when resolving a query. A DNS client MUST NOT fallback from Strict Privacy to Opportunistic Privacy during the resolution process as this could invalidate the protection offered against active attackers.

This document describes authentication mechanisms that can be used in either Strict or Opportunistic Privacy for DNS-over-(D)TLS.

Many (D)TLS clients use PKIX authentication based on a 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. A DNS client therefore has a bootstrap problem. DNS clients typically know only the IP address of a DNS server. As such, before connecting to a DNS server, a DNS client needs to learn the domain name it should associate with the IP address of a DNS server for authentication purposes. Sources of domains names are discussed in and . One advantage of this domain name based approach is that it encourages association of stable, human recognisable identifiers with secure DNS service providers.

The use of SPKI pinset verification is discussed in . In terms of domain name based verification, once a domain name is known for a DNS server a choice of mechanisms can be used for authentication. discusses these mechanisms in detail, namely PKIX certificate based authentication and DANE. 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 .

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

An Opportunistic Security profile is described in which MAY be used for DNS-over-(D)TLS. DNS clients issuing queries under an opportunistic profile which know of a domain name or SPKI pinset for a given privacy-enabling DNS server MAY choose to try to authenticate the server using the mechanisms described here. This is useful for detecting (but not preventing) active attack, 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, encrypted connection. In this case, whilst a client cannot know the reason for an authentication failure, from a privacy standpoint the client should consider an active attack in progress and proceed under that assumption. 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.

To authenticate a privacy-enabling DNS server, a DNS client needs to know the domain name for each server it is willing to contact. This is necessary to protect against active attacks on DNS privacy. A DNS client requiring Strict Privacy MUST either use one of the sources listed in to obtain a domain name for the server it contacts, or use an SPKI pinset as described in . A DNS client requiring Strict Privacy MUST only attempt to connect to DNS servers for which either a domain name or a SPKI pinset is known (or both). The client MUST use the available verification mechanisms described in 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 MAY be used during network configuration, with the intent to transition to the designated privacy-enabling DNS servers after captive portal registration. The system MUST alert by some means that the DNS is not private during such bootstrap.

This specification adds a SRV service label "domain-s" for privacy-enabling DNS servers. Example service records (for TLS and DTLS respectively): _domain-s._tcp.dns.example.com. SRV 0 1 853 dns1.example.com. _domain-s._tcp.dns.example.com. SRV 0 1 853 dns2.example.com. _domain-s._udp.dns.example.com. SRV 0 1 853 dns3.example.com.

DNS clients may be directly and securely provisioned with the 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 a domain name for each DNS server.

A DNS client may be configured directly and securely with only the domain name of its privacy-enabling DNS server. 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 server option ). It can then use opportunistic DNS connections to untrusted recursive DNS resolver to establish the IP address of the intended privacy-enabling DNS server by doing a lookup of SRV records. Such records MUST be validated using DNSSEC. Private DNS resolution can now be done by the DNS client against the configured privacy-enabling DNS server. Example: A DNSSEC validating DNS client is configured with the domain name dns.example.net for a privacy-enabling DNS server Using Opportunistic Privacy to a default DNS resolver (acquired, for example, using DHCP) the client performs look ups for SRV record for _domain-s._tcp.dns.example.net to obtain the server host name A and/or AAAA lookups to obtain IP address for the server host name Client validates all the records obtained in the previous step using DNSSEC. If the records successfully validate the client proceeds to connect to the privacy-enabling DNS server using Strict Privacy. A DNS client so configured that successfully connects to a privacy-enabling DNS server MAY choose to locally cache the looked up addresses in order to not have to repeat the opportunistic lookup.

Some clients may have an established trust relationship with a known DHCP server for discovering their network configuration. In the typical case, such a DHCP server provides a list of IP addresses for DNS servers (see section 3.8 of ), but does not provide a domain name for the DNS server itself. In the future, a DHCP server might use a DHCP extension to provide a list of domain names for the offered DNS servers, which correspond to IP addresses listed. Use of such a mechanism with any DHCP server when using an Opportunistic profile is reasonable, given the security expectation of that profile. However when using a Strict profile the DHCP servers used as sources of domain names MUST be considered secure and trustworthy. This document does not attempt to describe secured and trusted relationships to DHCP servers. [NOTE: It is noted (at the time of writing) that whilst some implementation work is in progress to secure IPv6 connections for DHCP, IPv4 connections have received little to no implementation attention in this area.]

When a DNS client configured with a domain name connects to its configured DNS server over (D)TLS, the server may present it with an PKIX certificate. In order to ensure proper authentication, DNS clients MUST verify the entire certification path per . The DNS client additionally uses validation techniques to compare the domain name to the certificate provided. A DNS client constructs two Reference Identifiers for the server based on the domain name: A DNS-ID and an SRV-ID. The DNS-ID is simply the domain name itself. The SRV-ID uses a "_domain-s." prefix. So if the configured domain name is "dns.example.com", then the two Reference Identifiers are: DNS-ID: dns.example.com SRV-ID: _domain-s.dns.example.com If either of the Reference Identifiers are found in the PKIX certificate's subjectAltName extension as described in section 6 of , the DNS client should accept the certificate for the server. A compliant DNS client MUST only inspect the certificate's subjectAltName extension for these Reference Identifiers. In particular, it MUST NOT inspect the Subject field itself.

DANE provides mechanisms to root certificate and raw public key trust with DNSSEC. However this requires the DNS client to have a domain name for the DNS Privacy Server which must be obtained via a trusted source. This section assumes a solid understanding of both DANE and DANE Operations. A few pertinent issues covered in these documents are outlined here as useful pointers, but familiarity with both these documents in their entirety is expected. It is noted that 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." It is noted that covers the following topics: Section 4.1: Opportunistic Security and PKIX Usages and Section 14: Security Considerations, which both discuss the use of PKIX-TA(0) and PKIX-EE(1) for OS. Section 5: Certificate-Usage-Specific DANE Updates and Guidelines. Specifically Section 5.1 which outlines the combination of Certificate Usage DANE-EE(3) and Selector Usage SPKI(1) with Raw Public Keys . Section 5.1 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. [QUESTION: Should an appendix be added with an example of how to use DANE without PKIX certificates?] Section 13: Operational Considerations, which discusses TLSA TTLs and signature validity periods. The specific DANE record for a DNS Privacy Server would take the form: _853._tcp.[server-domain-name] for TLS _853._udp.[server-domain-name] for DTLS

The DNS client MAY choose to perform the DNS lookups to retrieve the required DANE records itself. The DNS queries for such DANE records MAY use opportunistic encryption or be in the clear to avoid trust recursion. The records MUST be validated using DNSSEC as described above in .

The DNS client MAY offer the TLS extension described in . 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.

The SPKI pinset profile described in MAY be used with DNS-over-(D)TLS. This draft does not make explicit recommendations about how a SPKI pinset based authentication mechanism 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 pinset and a domain name available to allow clients to choose which mechanism to use. Therefore, the following is guidance on how clients ought to behave if they choose to configure both, as is possible in HPKP. A DNS client that is configured with both a domain name and a SPKI pinset for a DNS server SHOULD match on both a valid credential for the domain name and a valid SPKI pinset if both are available when connecting to that DNS server.

This section defines the (D)TLS protocol profile of DNS-over-(D)TLS. There are known attacks on (D)TLS, such as machine-in-the-middle and protocol downgrade. These are general attacks on (D)TLS and not specific to DNS-over-TLS; please refer to the (D)TLS RFCs for discussion of these security issues. Clients and servers MUST adhere to the (D)TLS implementation recommendations and security considerations of except with respect to (D)TLS version. Since encryption of DNS using (D)TLS is virtually a green-field deployment DNS clients and server MUST implement only (D)TLS 1.2 or later. Implementations MUST NOT offer or provide TLS compression, since compression can leak significant amounts of information, especially to a network observer capable of forcing the user to do an arbitrary DNS lookup in the style of the CRIME attacks. Implementations compliant with this profile MUST implement all of the following items: TLS session resumption without server-side state which eliminates the need for the server to retain cryptographic state for longer than necessary. Raw public keys which reduce the size of the ServerHello, and can be used by servers that cannot obtain certificates (e.g., DNS servers on private networks). Implementations compliant with this profile SHOULD implement all of the following items: TLS False Start which reduces round-trips by allowing the TLS second flight of messages (ChangeCipherSpec) to also contain the (encrypted) DNS query Cached Information Extension 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 and that specific to DTLS it is provided in.

This memo includes no request to IANA.

Security considerations discussed in , and apply to this document.

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 resolver to authoritative traffic). DNS-over-(D)TLS clients and servers SHOULD consider implementing the following relevant DNS extensions EDNS(0) padding, which allows encrypted queries and responses to hide their size. DNS-over-(D)TLS clients SHOULD consider implementing the following relevant DNS extensions Privacy Election using Client Subnet in DNS Queries. If a DNS client does not include an EDNS0 Client Subnet Option with a SOURCE PREFIX-LENGTH set to 0 in a query, the DNS server may potentially leak client address information to the upstream authoritative DNS servers. A DNS client ought to be able to inform the DNS Resolver that it does not want any address information leaked, and the DNS Resolver should honor that request.

Thanks to the authors of both and for laying the ground work that this draft builds on 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 and Christian Huitema for review and discussion of the ideas presented here.

EKOparty Security Conference NLnetLabs

This section presents a non-normative discussion of how DNS clients might probe for and cache privacy capabilities of 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, and 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 a lower security. DNS clients using opportunistic security should try all available servers (possibly in parallel) in order to obtain an authenticated encrypted connection before falling back to a lower security. (RATIONALE: This approach can increase latency while discovering server capabilities but maximizes the chance of sending the query over an authenticated encrypted connection.)

[Note to RFC Editor: please remove this section prior to publication.]

Add more details on detecting passive attacks to section 4.2 Changed X.509 to PKIX throughout Change comment about future I-D on usage policies.

Introduction: Add comment that DNS-over-DTLS draft is Experiments Update 2 I-D references to RFCs.

Section 9: Update DANE section with better references to RFC7671 and RFC7250

Introduction: Added paragraph on the background and scope of the document. Introduction and Discussion: Added more information on what a Usage profiles is (and is not) the the two presented here. Introduction: Added paragraph to make a comparison with the Strict profile in RFC7858 clearer. Section 4.2: Re-worked the description of Opportunistic and the table. Section 8.3: Clarified statement about use of DHCP in Opportunistic profile Title abbreviated.

Section 4.2: Make clear that the Strict Privacy Profile can include meta queries performed using Opportunistic Privacy. Section 4.2, Table 1: Update to clarify that Opportunistic Privacy does not guarantee protection against passive attack. Section 4.2: Add sentence discussing client/provider trusted relationships. Section 5: Add more discussion of detection of active attacks when using Opportunistic Privacy. Section 8.2: Clarify description and example.

Re-submission of draft-dgr-dprive-dtls-and-tls-profiles with name change to draft-ietf-dprive-dtls-and-tls-profiles. Also minor nits fixed.