Using Early Data in DNS over TLS
Cloudflare, Inc.
alessandro@cloudflare.com
DPRIVE
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.
The Transport Layer Security (TLS) Protocol Version 1.3
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.
Specification for DNS over Transport Layer Security (TLS)
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.
Key words for use in RFCs to Indicate Requirement Levels
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.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
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.
Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension
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 Early Data in HTTP
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.