Starting TLS over DNS
draft-hzhwm-start-tls-for-dns-00

Abstract

This document describes a technique for upgrading a DNS TCP connection to use Transport Layer Security (TLS) over standard ports. Encryption provided by DNS-over-TLS eliminates opportunities for eavesdropping of DNS queries in the network. The proposed mechanism is backwards compatible with clients and servers that are not aware of DNS-over-TLS.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 18, 2014.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) 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.

1. Introduction

Today, nearly all DNS queries ([RFC1034] and [RFC1035]) are sent unencrypted, which makes them vulnerable to eavesdropping by an attacker that has access to the network channel, reducing the privacy of the querier. Recent news reports have elevated these concerns, and ongoing efforts are beginning to identify privacy concerns about DNS ([draft-bortzmeyer-dnsop-dns-privacy]).

Prior work has addressed some aspects of DNS security, but none addresses privacy between a DNS client and server using standard protocols. DNS Security Extensions (DNSSEC, [RFC4033]) provide response integrity by defining mechanisms to cryptographically sign zones, allowing end-users (or their first-hop resolver) to verify replies are correct. DNSSEC however does nothing to protect request or response privacy. Traditionally, either privacy was not considered a requirement for DNS traffic, or it was assumed that network traffic was sufficiently private, however these perceptions are evolving due to recent events.

More recently, DNSCurve [draft-dempsky-dnscurve] defines a method to provide link-level confidentiality and integrity between DNS clients and servers. However, it does so with a new cryptographic protocol and so does not take advantage of TLS. ConfidentialDNS [draft-wijngaards-confidentialdns] and IPSECA [draft-osterweil-dane-ipsec] use opportunistic encryption to provide privacy for DNS queries and responses. However, it is unclear how a client can locate an RR specific to its first-hop resolver. Finally, others have suggested DNS-over-TLS. Recent work suggests DNS-over-TLS ([draft-bortzmeyer-dnsop-privacy-sol]), and the Unbound DNS software [unbound] includes a DNS-over-TLS implementation. However, neither defines methods to negotiate TLS use over an existing connection; unbound instead requires DNS-over-TLS to run on a different port.

The mechanism described in this document enables DNS clients and servers to upgrade an existing DNS-over-TCP connection to a DNS-over-TLS connection. It is analogous to STARTTLS [RFC2595] used in SMTP [RFC3207], IMAP [RFC3501] and POP [RFC1939].

This document defines only the protocol extensions necessary to support TLS negotiation. It does not describe how DNS clients might validate server certificates or specify trusted certificate authorities. Solutions for certificate authentication are outside the scope of this document.

1.1. Reserved Words

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 RFC 2119 [RFC2119].

2. Protocol Changes

                  +0 (MSB)                +1 (LSB)
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        0: |   EXTENDED-RCODE      |       VERSION         |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        2: |DO|TO|                  Z                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    

Clients and servers indicate their support for, and desire to use, DNS-over-TLS by setting a bit in the Flags field of the EDNS0 [RFC6891] OPT meta-RR. The "TLS OK" (TO) bit is defined as the second bit of the third and fourth bytes of the "extended RCODE and flags" portion of the EDNS0 OPT meta-RR, immediately adjacent to the "DNSSEC OK" (DO) bit [RFC4033]:

2.1. Use by DNS Clients

2.1.1. Sending Queries

DNS clients MAY set the TO bit in queries sent using UDP transport to signal their general ability to support DNS-over-TLS. [For discussion: is this a bad idea because ignorant middleboxes might drop the TO=1 UDP queries?]

DNS clients MAY set the TO bit in the initial query sent to a server using TCP transport to signal their desire that the TCP connection be upgraded to TLS. DNS clients MUST NOT set the TO bit on subsequent queries when using TCP or TLS transport (to avoid ambiguity).

Since the motivation for DNS-over-TLS is to preserve privacy, DNS clients SHOULD use a query that reveals no private information in the initial TO=1 query to a server. To provide a standard "dummy" query, it is RECOMMENDED to send the initial query with RD=0, QNAME="STARTTLS", QCLASS=CH, and QTYPE=TXT ("STARTTLS/CH/TXT") analogous to administrative queries already in widespread use [RFC4892].

After sending the initial TO=1 query using TCP transport, DNS clients MUST wait for the initial response before sending any subsequent queries over the same TCP connection.

2.1.2. Receiving Responses

A DNS client that receives a response using UDP transport that has the TO bit set MUST handle that response as usual. It MAY record the server's support for DNS-over-TLS and use that information as part of its server selection algorithm in the case where multiple servers are available to service a particular query. [For discussion: UDP is subject to spoofing and a client which depends on TO=1 in a UDP response may be tricked into never upgrading to TLS.]

A DNS client that receives a response to its initial query using TCP transport that has the TO bit set MUST immediately initiate a TLS handshake using the procedure described in [RFC5246].

A DNS client that receives a response to its initial query using TCP transport that has the TO bit clear MUST not initiate a TLS handshake and SHOULD utilize the existing TCP connection for subsequent queries. DNS clients SHOULD remember server IP addresses that don't support DNS-over-TLS (including TLS handshake failures) and SHOULD NOT request DNS-over-TLS from them for reasonable period. (We suggest 1 hour, or when the client discovers a new resolver.)

2.2. Use by DNS Servers

2.2.1. Receiving Queries

A DNS server receiving a query over UDP MUST ignore the TO bit.

A DNS server receiving a query over an existing TLS connection MUST ignore the TO bit.

A DNS server receiving an initial query over TCP that has the TO bit set MAY inform the client it is willing to establish a TLS session, as described in the next section.

A DNS server receiving subsequent queries over TCP MUST ignore the TO bit. (A client wishing to start TLS after the initial query MUST open a new TCP connection to do so.)

2.2.2. Sending Responses

A DNS server sending a response over UDP SHOULD set the TO bit to indicate its general support for DNS-over-TLS, as long as it is willing and able to support a TLS connection with the particular client.

A DNS server receiving an initial query over TCP that has the TO bit set MAY set the TO bit in its response. The server MUST then proceed with the TLS handshake protocol.

A DNS server receiving a "dummy" STARTTLS/CH/TXT query over TCP MUST respond with RCODE=0 and a TXT RR in the Answer section. Contents of the TXT RR are strictly informative (for humans) and MUST NOT be interpreted by the client software. Recommended TXT RDATA values are "STARTTLS" or "NO_TLS".

2.3. Established Sessions

After TLS negotiation completes, the connection will be encrypted and is now protected from eavesdropping and normal DNS queries SHOULD take place.

Both clients and servers SHOULD follow existing DNS-over-TCP timeout rules, which are often implementation- and situation-dependent. In the absence of any other advice, the RECOMMENDED timeout values are 30 seconds for recursive name servers, 60 seconds for clients of recursive name servers, 10 seconds for authoritative name servers, and 20 seconds for clients of authoritative name servers. Current work in this area may assist DNS-over-TLS clients and servers select useful timeout values [draft-wouters-edns-tcp-keepalive] [tdns].

As with current DNS-over-TCP, DNS servers MAY close the connection at any time (e.g., due to resource constraints). As with current DNS-over-TCP, clients MUST handle abrupt closes and be prepared to reestablish connections and/or retry queries. DNS servers SHOULD use the TLS close-notify request to shift TCP TIME-WAIT state to the clients.

DNS servers SHOULD enable fast TLS session resumption [RFC5077] to avoid keeping per-client session state.

2.4. Middleboxes

Middleboxes [RFC3234] may be present in some networks that interfere with normal DNS resolution and create problems for DNS-over-TLS. A DNS client attempting DNS-over-TLS with a middlebox could have one of the following outcomes (as discussed in prior RFCs [RFC3207]):

1. The DNS client sends a TO=1 query and receives a TO=0 response. In this case there is no upgrade to TLS and DNS resolution occurs normally, without encryption.
2. The DNS client sends a TO=1 query and receives a TO=1 response, but the TLS handshake fails because the server's certificate cannot be authenticated. In this case the client SHOULD close the established connection and fall back to unencrypted DNS for a reasonable period (as discussed in Section 2.1.2).
3. The DNS client sends a TO=1 query and receives a TO=1 response, but the middlebox does not understand the TLS negotiation. Middleboxes SHOULD clear TO in replies if they are not prepared to pass through TLS negotiation. Clients SHOULD retry DNS without TO set if negotiation fails, and then retry with TLS after a reasonable period (see Section 2.1.2).
4. The DNS client sends a TO=1 query but receives no response at all. The middlebox might be silently dropping the query, despite [RFC6891] stating that the "Z" Flags are to be ignored by receivers. The client SHOULD fall back to normal (unencrypted) DNS for a reasonable period (as discussed in Section 2.1.2).

In general, clients that attempt TLS and fail can either fall back on unencrypted DNS, or wait and retry later, depending on their privacy requirements. [For discussion: should IETF recommend defaulting to postpone and retry instead of non-private operation? This is a policy decision.]

3. Performance Considerations

DNS-over-TLS incurs additional latency at session startup. It also requires additional state (memory) increased processing (CPU). [tdns].

1. Latency: Compared to UDP, DNS-over-TCP requires an additional round-trip-time (RTT) of latency to establish the connection. The TLS handshake adds another two RTTs of latency. Using a single connection for multiple requests amortizes the connection setup costs. Moreover, TLS connection resumption can further reduce the setup delay.
2. State: The use of connection-oriented TCP requires keeping additional state in both kernels and applications. TLS has marginal increases in state over TCP alone. The state requirements are of particular concerns on servers with many clients. Smaller timeout values will reduce the number of concurrent connections, and servers can preemptively close connections when resources limits are exceeded.
3. Processing: Use of TLS encryption algorithms necessarily results in increased CPU usage. Servers can choose to refuse new DNS-over-TCP clients if processing limits are exceeded.

A full performance evaluation is outside the scope of this specification. A more detailed analysis of the performance implications of DNS-over-TLS (and DNS-over-TCP) is discussed in a technical report

4. IANA Considerations

This document defines a new bit ("TO") in the Flags field of the EDNS0 OPT meta-RR. At the time of approval of this draft in the standards track, as per the IANA Considerations of RFC 6891, IANA is requested to reserve the second leftmost bit of the flags as the TO bit, immediately adjacent to the DNSSEC DO bit, as shown in Section 2.

5. Security Considerations

The goal of this proposal is to address the security risks that arise because DNS queries may be eavesdropped upon, as described above. There are a number of residual risks that may impact this goal.

1. There are known attacks on TLS, such as person-in-the-middle and protocol downgrade. These are general attacks on TLS and not specific to DNS-over-TLS; we refer to the TLS RFCs for discussion of these security issues.
2. Any protocol interactions prior to the TLS handshake are performed in the clear and can be modified by a man-in-the-middle attacker. For this reason, clients MAY discard cached information about server capabilities advertised prior to the start of the TLS handshake.
3. As with other uses of STARTTLS-upgrade to TLS, the mechanism specified here is susceptible to downgrade attacks, where a person-in-the-middle prevents a successful TLS upgrade. Keeping track of servers known to support TLS (i.e., "pinning") enables clients to detect downgrade attacks. For servers with no connection history, clients may choose to refuse non-TLS DNS, or they may continue without TLS, depending on their privacy requirements.
4. This document does not propose new ideas for certificate authentication for TLS in the context of DNS. Several external methods are possible, although each has weaknesses. The current Certificate Authority infrastructure [RFC5280] is used by HTTP/TLS [RFC2818]. With many trusted CAs, this approach has recognized weaknesses [CA_Compromise]. Some work is underway to partially address these concerns (for example, with certificate pinning [certificate_pinning], but more work is needed. DANE [RFC6698] provides mechanisms to root certificate trust with DNSSEC. That use here must be carefully evaluated to address potential issues in trust recursion. For stub-to-recursive resolver use, certificate authentication is sometimes either easy or nearly impossible. If the recursive resolver is manually configured, its certificate can be authenticated when it is configured. If the recursive resolver is automatically configured (such as with DHCP [RFC2131]), it could use DHCP authentication mechanisms [RFC3118]).

Ongoing discussion of opportunistic TLS (connections without CA validation, [draft-hoffman-uta-opportunistic-tls]) may be relevant to DNS-over-TLS.

6. Acknowledgements

We would like to thank Stephane Bortzmeyer, Brian Haberman, Paul Hoffman, Kim-Minh Kaplan, Bill Manning, George Michaelson, Eric Osterweil and Glen Wiley for reviewing this Internet-draft.

7. References

7.1. Normative References

7.2. Informative References

Authors' Addresses

Table of Contents

• 1. Introduction
• 1.1. Reserved Words
• 2. Protocol Changes
• 2.1. Use by DNS Clients
• 2.1.1. Sending Queries
• 2.1.2. Receiving Responses
• 2.2. Use by DNS Servers
• 2.2.1. Receiving Queries
• 2.2.2. Sending Responses
• 2.3. Established Sessions
• 2.4. Middleboxes
• 3. Performance Considerations
• 4. IANA Considerations
• 5. Security Considerations
• 6. Acknowledgements
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses