Using Early Data in DNS over TLS
draft-ghedini-dprive-early-data-02

Abstract

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.

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 https://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 28, 2020.

Copyright Notice

Copyright (c) 2020 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.

Table of Contents

• 1. Introduction
• 2. Notational Conventions
• 3. Early Data in DNS over TLS
• 4. Security Considerations
• 4.1. Information Exposure
• 4.2. Denial of Service
• 5. IANA Considerations
• 5.1. Registry for DNS Resource Record (RR) TYPEs for TLS Early Data
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Appendix A. Acknowledgments
• Author's Address

1. Introduction

TLS 1.3 [TLS13] 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 [DOT] 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 [TLS13] describes tecniques to reduce the likelihood of a replay attack, they are not perfect and still leave some potential for exploitation.

2. Notational Conventions

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.

3. Early Data in DNS over TLS

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 [TLS13] 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 [ALPN]. 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 Section 5.1. Servers receiving any of those messages MUST reply with a “FormErr” response code.

4. Security Considerations

4.1. Information Exposure

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.

4.2. Denial of Service

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.

5. IANA Considerations

This document has no actions for IANA.

5.1. Registry for DNS Resource Record (RR) TYPEs for TLS Early Data

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:

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.

6. References

6.1. Normative References

6.2. Informative References

Appendix A. Acknowledgments

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

Author's Address