Cloudflare, Inc.

alessandro@cloudflare.com

This document illustrates the risks of using TLS 1.3 early data with DNS over TLS, and specifies behaviors that can be adopted by clients and servers to reduce those risks.

TLS 1.3 defines a mechanism, called 0-RTT session resumption or early data, that allows clients to send data to servers in the first round-trip of a resumed connection without having to wait for the TLS handshake to complete. This can be used to send DNS queries to DNS over TLS servers without incurring in the cost of the additional round-trip required by the TLS handshake. This can provide significant performance improvements in cases where new DNS over TLS connections need to be established often such as on mobile clients where the network might not be stable, or on resolvers where keeping an open connection to many authoritative servers might not be practical. However the use of early data allows an attacker to capture and replay the encrypted DNS queries carried on the TLS connection. This can have unwanted consequences and help in recovering information about those queries. While describes tecniques to reduce the likelihood of a replay attack, they are not perfect and still leave some potential for exploitation.

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 when, and only when, they appear in all capitals, as shown here.

Early data forms a single stream of data along with other application data, meaning that one or more DNS queries can either be partially or fully contained within early data. Once the TLS handshake has completed, the early data is known to not be a replayed copy of that data, but this doesn’t mean that it can’t be replayed, or that it hasn’t already been replayed, in another connection. A server can signal to clients whether it is willing to accept early data in future connections by providing the “early_data” TLS extension as part of a TLS session ticket, as well as limit the amount of early data it is willing to accept using the “max_early_data_size” field of the “early_data” extension. In addition to the mitigation mechanisms mandated in that reduce the ability of an attacker to replay early data, but may not completely eliminate it, a server that decided to offer early data to clients MAY reject early data at the TLS layer, or delay the processing of early data after the handshake is completed. If the server rejects early data at the TLS layer, a client MUST forget information it optmisitically assumed about the onnection when sending early data, such as the negotiated protocol . Any DNS queries sent in early data will need to be sent again, unless the client decides to abandon them. Not all types of DNS messages are safe to be sent as early data, as they might modfify the server’s state, or expose sensitive data, through replay. Clients MUST NOT use early data to send messages that make use of opcodes other than “Query” and RR types not listed in the registry defined in . Servers receiving any of those messages MUST reply with a “FormErr” response code.

By replaying DNS queries that were captured when transmitted over early data, an attacker might be able to expose information about those queries, even if encrypted. For example, it’s a common behavior for DNS servers to statefully rotate the order of RRs when replying to DNS queries for an RRSet that contains multiple RRs. If the order of rotation is predictable, replaying a captured early data DNS query and observing the order of RRs in DNS responses before and after the replayed query, might allow the attacker to confirm whether the query targeted a specific name that was suspected of being queried. When accepting early data, servers SHOULD either use fixed ordering for multiple RRs in the same DNS response or shuffle the RRs at random, but MUST NOT use stateful and deterministic ordering across multiple queries.

Accepting early data exposes a server to potential denial of service through the replay of queries that might be expensive to handle. When under load, a server MAY reject TLS early data such that the client is forced to retry them after the handshake is completed.

This document has no actions for IANA.

This document establishes a registry of DNS RR types that can be used within TLS early data, titled “DNS Resource Record (RR) TYPEs for Use with TLS Early Data”, under the existing “Domain Name System (DNS) Parameters” heading. The entries in the registry are: TYPE Reference A [this document] NS [this document] CNAME [this document] SOA [this document] PTR [this document] MX [this document] TXT [this document] AAAA [this document] SRV [this document] DNAME [this document] DS [this document] DNSKEY [this document] The values in this registry MUST correspond to existing entries in the “Resource Record (RR) TYPEs” registry. Specifically, the value of the “TYPE” column for each entry in this new registry MUST match the value of the “TYPE” column of an entry in the “Resource Record (RR) TYPEs” registry.

This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. Using TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay.

Thanks to Martin Thomson, Mark Nottingham and Willy Tarreau for writing which heavily inspired this document, and to Daniel Kahn Gillmor and Colm MacCárthaigh who also provided important ideas and contributions.