Network Working Group P. Hoffman
Internet-Draft ICANN
Intended status: Standards Track P. Sood
Expires: March 14, 2021 Google
September 10, 2020
Recursive to Authoritative DNS with Opportunistic Encryption
draft-pp-recursive-authoritative-opportunistic-00
Abstract
This document describes a method for a DNS recursive resolver to use
opportunistic encryption when communicating with authoritative
servers. The method here is optional for both the recursive resolver
and the authoritative server. A motivating use case for this method
is that more encryption on the Internet is better, and opportunistic
encryption is better than no encryption at all. Nothing in this
method prevents use cases that require better encryption.
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 March 14, 2021.
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
Hoffman & Sood Expires March 14, 2021 [Page 1]
Internet-Draft Opportunistic Recursive to Authoritative September 2020
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
1.1. Use Case . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use of Opportunistic Encryption . . . . . . . . . . . . . . . 3
3. Transport Caches . . . . . . . . . . . . . . . . . . . . . . 4
4. Using AUTHINFO Responses for Filling the Transport Cache . . 5
4.1. Contacting This Resolver Using DoT . . . . . . . . . . . 5
4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5.1. Registration for dot-ports in the IANA DNS Authoritative
Server Information Registry . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
A recursive resolver using traditional DNS over port 53 may wish
instead to use encrypted communication with authoritative servers in
order to prevent passive snooping of its DNS traffic. The recursive
resolver can use opportunistic encryption (defined in [RFC7435] to
achieve this goal.
This document describes a method for recursive resolvers to use
opportunistic encryption using TLS-based DNS transport such as DNS-
over-TLS (DoT, [RFC7858]) with authoritative servers in an efficient
manner. It also defines a way for recursive resolvers to get
information from authoritative servers about their features and
capabilities.
1.1. Use Case
The use case for the method in this document is recursive resolver
operators who are happy to use TLS [RFC8446] encryption with
authoritative servers if doing so doesn't significantly slow down
getting answers, and authoritative server operators that are happy to
use encryption with recursive resolvers if it doesn't cost much.
Both parties understand that using encryption costs something, but
are willing to absorb the costs for the benefit of more Internet
Hoffman & Sood Expires March 14, 2021 [Page 2]
Internet-Draft Opportunistic Recursive to Authoritative September 2020
traffic being encrypted. The extra costs (compared to using
traditional DNS on port 53) include:
o Extra round trips to establish TCP for every session
o Extra round trips for TLS establishment
o Greater CPU use for TLS establishment
o Greater CPU use for encryption after TLS establishment
o Greater memory use for holding TLS state
1.2. Definitions
The terms "recursive resolver" and "authoritative server" are defined
in [RFC8499].
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.
2. Use of Opportunistic Encryption
[RFC7435] defines opportunistic encryption. In this document, the
only difference between normal TLS session establishment and
opportunistic encryption is that the the TLS client (the recursive
resolver) optionally authenticate the server. In normal TLS, the
client is required to authenticate the server and the TLS connection
fails if the authentication is not successful.
In the opportunistic encryption described here, there is no need for
the recursive resolver to authenticate the authoritative server
because any authentication failure MUST be ignored. If it is easier
programmatically for the recursive resolver to authenticate the
authoritative server and then ignore the result than to just not
authenticate, the recursive resolver MAY do that.
Note that different protocols for encrypted resolver-to-authoritative
communication might to require normal TLS authentication. Because of
this, authoritative servers SHOULD use TLS certificates that can be
used in normal TLS authentication, such as those issued by trusted
third parties or self-issued certificates that can be authenticated
in other ways, such as with DANE [RFC6698] records. However, if an
authoritative server does not care about the use cases for such
Hoffman & Sood Expires March 14, 2021 [Page 3]
Internet-Draft Opportunistic Recursive to Authoritative September 2020
future protocols, it MAY use self-issued certificates that cannot be
authenticated.
3. Transport Caches
A recursive resolver that attempted to use encrypted transport every
time it connected to any authoritative server would inherently be
slower than one that did not. Similarly, a recursive resolver that
made an external lookup of what secure transports every authoritative
server supports each time it connected would also inherently be
slower than one that did not. Recursive resolver operators desire to
give answers to stub resolvers as quickly as possible, so neither of
these two strategies would make sense.
Instead, recursive resolvers following the method described in this
document MUST keep a cache of what they know about the secure
transports supported by authoritative servers. This is called a
"transport cache" in this document.
The recursive resolver MUST look in its transport cache before
sending DNS queries to an authoritative server. If there is no entry
for an authoritative server in its transport cache, the recursive
resolver MUST use plain, unencrypted DNS over port 53.
This document explicitly does not mandate the contents of the
transport cache. Different recursive resolver implementers are
likely to have different cache structures based on many factors, such
as research results, active measurements, and customer feedback,
There will likely be different strategies for the time-to-live for
parts of the transport cache, such as how often to refresh the data
in the cache, how often to refresh negative data, whether to
prioritize refreshing certain zones or types of zones, and so on.
This document also explicitly doesn't mandate how the strategy for
filling transport caches. Some strategies might include one or more
of "try to send a refresh query over DoT", "use external data",
"trust a third-party service for filling the transport cache", and so
on.
There are no interoperability issues with different implementors
making different choices for the contents and fill strategies of
their transport caches, and having many different options available
will likely cause the cache designs to get better over time.
Hoffman & Sood Expires March 14, 2021 [Page 4]
Internet-Draft Opportunistic Recursive to Authoritative September 2020
4. Using AUTHINFO Responses for Filling the Transport Cache
As described above, one of the mechanisms that a recursive resolver
might use to fill its transport cache is to use external data that
might give the resolver relevant data about possible transports.
This section defines how to use AUTHINFO RRtypes (defined in
[I-D.pp-dnsop-authinfo]) for that purpose. This document defines two
entries for the IANA DNS Authoritative Server Information Registry
that is defined in [I-D.pp-dnsop-authinfo].
4.1. Contacting This Resolver Using DoT
The "dot-ports" name is used to specify the port(s) that can be used
by the recursive resolver for DoT queries. The value MUST be an
array of port numbers. Each element of the array in the value is a
JSON number.
The value of "dot-ports" is an array of numbers instead of just one
number because an authoritative server might support DoT on more than
one port. The order of the elements in the array has no meaning;
that is, the array could instead be considered a set.
The array in the value can be empty, which indicates that the
authoritative server does not offer DoT service. An empty array and
the absence of a name/value pair for "dot-ports" have identical
meanings.
4.2. Examples
An authoritative server can be reached at "ns32.example.com" and the
IP address 192.0.2.222. It offers offers DoT service on the default
port. It's response to the AUTHINFO query might be:
{ "dot-ports": [ 853 ] }
5. IANA Considerations
5.1. Registration for dot-ports in the IANA DNS Authoritative Server
Information Registry
Name: dot-ports
Value type: Array of numbers
Specification: This document, Section 4.1
Hoffman & Sood Expires March 14, 2021 [Page 5]
Internet-Draft Opportunistic Recursive to Authoritative September 2020
6. Security Considerations
The method described in this document explicitly allows a stub to
perform DNS communications over traditional unencrypted,
unauthenticated DNS on port 53.
The method described in this document explicitly allows a stub to
choose to allow unauthenticated TLS. In this case, the resulting
communication will be susceptible to obvious and well-understood
attacks from an attacker in the path of the communications.
7. References
7.1. Normative References
[I-D.pp-dnsop-authinfo]
Hoffman, P. and P. Sood, "Reporting Information from DNS
Authoritative Servers", draft-pp-dnsop-authinfo-00 (work
in progress), September 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
Hoffman & Sood Expires March 14, 2021 [Page 6]
Internet-Draft Opportunistic Recursive to Authoritative September 2020
7.2. Informative References
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>.
Authors' Addresses
Paul Hoffman
ICANN
Email: paul.hoffman@icann.org
Puneet Sood
Google
Email: puneets@google.com
Hoffman & Sood Expires March 14, 2021 [Page 7]