Draft: draft-add-requirements

Commentary: Authors , please comment . 
 I ’m not sure adding authenticated here is something the group has consensus on as yet . I know this is still in early draft mode , so while I do n’t object to including it , we should mark is as an item to be discussed . If we do include it , then some words should be somewhere in the draft about what “ authenticated ” in such a context is being proposed to mean as that ’s what will be a key discussion item in determining if it get consensus . 
  I merged " authenticated " before I read this comment . I it because it made sense to me ; without authentication any encryption is highly weakened . But I take your point that it needs explaining . 
 Ok , perhaps it can be in the next rev . Basically I ’m suggesting that the aspect of “ authenticated ” be expanded , discussed , and explained as it does potentially have different notions in different readers perspectives . For example some may say doing a DNSSEC validation of some sort is what is needed , or perhaps some form of PKI , or is it a TLS certificate validation , or mutual exchange ? It might even be something as basic as asking special DNS queries and validating the answers received against expectations . Another slice would be authenticating the actual resolver chosen or is it authenticated at the more abstract “ service ” provided by the operator of the resolver ? There is also the consideration of does the authentication means / level vary depending on different environmental threat levels ? The bottom line is there is a lot of meanings behind “ authentication ” and what is being authenticated to declare and discuss as a requirement . 
 Several possible ways of authenticating the encrypted DNS server are already discussed in our spec I do n't think the requirements draft should discuss the possible modes of authenticating the server . 
 How does the client learn the encrypted and unencrypted DNS servers are operated by the same administrative domain ? The client can authenticate the encrypted DNS servers but can not authenticate the unencrypted DNS server ! Originally posted by in 
 If it is genuinely impossible to prove association between two resolvers when one resolver is unencrypted , then perhaps we should not have the concept at all . But I 'm hoping it is not impossible . 
 draft - pauly - add - deer-00 does this ( at least in some circumstances ) , so it 's not impossible .
Adaptive DNS Discovery is chartered to define mechanisms that allow
clients to discover and select encrypted DNS resolvers.  This
document seeks to provide a set of use cases and requirements that
proposed mechanisms should address.
The Adaptive DNS Discovery (ADD) Working Group is chartered to define
mechanisms that allow clients to discover and select encrypted DNS
resolvers in a wide variety of network environments.  This document
seeks to provide a set of use cases and requirements that proposed
mechanisms should address.  They can do this either by providing a
solution, or by explicitly stating why it is not in scope.
Use cases are described between first-usecase and last-usecase.  Each
use case contains a narrative and a set of requirements that apply in
that case.  Each is identified as "Ra.b" where a is the requirement
group number and b is the number within that group.  Both a and b are
integers starting with 1.  A summary of all requirements in listed in
requirements-summary.
Adaptive DNS Discovery is chartered to define mechanisms that allow
clients to discover and select encrypted DNS resolvers.  This
document describes several use cases for discovering DNS resolvers
that support encrypted transports, and lists requirements that any
proposed discovery and selection mechanisms should address.
Several protocols for protecting DNS traffic with encrypted
transports have been defined, such as DNS-over-TLS (DoT) RFC7858 and
DNS-over-HTTPS (DoH) RFC8484.  Encrypted DNS can provide many
security and privacy benefits for network clients.
While it is possible for clients to hard-code encrypted DNS resolvers
to use, dynamic discovery and provisioning of encrypted resolvers can
expand the usefulness and applicability of encrypted DNS to many more
use cases.
The Adaptive DNS Discovery (ADD) Working Group is chartered to define
mechanisms that allow clients to automatically discover and select
encrypted DNS resolvers in a wide variety of network environments.
This document describes several use cases for discovering DNS
resolvers that support encrypted transports, and lists requirements
that any proposed discovery and selection mechanisms should address.
They can do this either by providing a solution, or by explicitly
stating why it is not in scope.
Use cases are described between associated and cdn-content.  Each use
case contains a narrative and a set of requirements that apply in
that case.  There are additional common requirements in priv-sec.
Each requirement is identified as "Ra.b" where a is the group number
and b is the number within that group.  Both a and b are integers
starting with 1.
A summary of all requirements in listed in requirements-summary.
A client may begin with information from the attached networks, and/
or resolvers known from configuration.  This information may be used
to then discover one or more associated or equivalent encrypted
resolvers.  These are expected to be operated by the same entity that
provides the resolver the client started with, but may not have
identical behaviour.  For example one entity may offer a set of
encrypted resolvers with different levels of filtering or proximity.
During network attach, networks frequently announce a resolver that
they recommend clients should use.  This could be through DHCP, RA,
PPP, PCO, or another mechanism.  Historically this is usually a Do53
resolver, declared simply by its IP address.  However it could also
be a richer set of information.
This document makes use of the following terms.
Encrypted DNS: DNS-over-HTTPS RFC8484, DNS-over-TLS RFC7858, or any
other encrypted DNS technology that the IETF may publish, such as
DNS-over-QUIC I-D.ietf-dprive-dnsoquic.
Associated resolver: A resolver operated by the same entity that
provides the resolver the client started with.  See associated.
Equivalent associated resolver: An associated resolver that provides
DNS responses that are identical to the ones served by the original
unencrypted resolver.
Alternative associated resolver: An associated resolver that serves
different responses to some queries; see associated for examples.
A client may begin with information about unencrypted resolvers from
the attached networks (local-network), and/or unencrypted resolvers
known from configuration (client-selected).  This information may be
used to then discover one or more associated encrypted resolvers.
Equivalent - these provide DNS responses that are identical to the
ones served by the unencrypted resolver.
Alternative - these serve different responses to some queries.
For example one entity may offer a set of encrypted resolvers with
different levels of filtering (none, just malware, or malware &
adult content), or different proximity (local or central).
The client may wish to select an equivalent associated resolver, or
select one of the alternatives.
Designs for resolver upgrade mechanisms can either add new parameters
to existing provisioning mechanisms (for example, adding necessary
information to use DoT or DoH to options in DHCP, RAs, or IKEv2) or
else provide a way to communicate with a provisioned unencrypted DNS
resolver and discover the associated encrypted DNS resolvers.
DNS servers are often provisioned by a network as part of DHCP
options RFC2132, IPv6 Router Advertisement (RA) options RFC8106,
Point-to-Point Protocol (PPP) RFC1877, 3GPP Protocol Configuration
Options, or another mechanism.  Historically this is usually one or
more DNS resolver IP addresses, to be used for traditional
unencrypted DNS.  However it could also be a richer set of
information.
Frequently, network-provisioned resolvers are forwarders running on a
local router.  The discovered encrypted resolvers in these cases may
either be local forwarders themselves, or an associated resolver that
is in the network (thus bypassing the router's DNS forwarder).
A client with manual configuration directing it to use a particular
resolver will generally use that resolver.  However if that
communication is unencrypted, it is beneficial for the client to
learn which associated resolvers are offered by the same entity and
provide the same semantics.
Another benefit occurs with IoT devices.  A common usage pattern for
such devices is for it to "call home" to a service that resides on
the public Internet, where that service is referenced through a
domain name (A or AAAA record).  As discussed in Manufacturer Usage
Description Specification RFC8520, because these devices tend to
require access to very few sites, all other access should be
considered suspect.  However, if the query is not accessible for
inspection, it becomes quite difficult for the infrastructure to
suspect anything.
Client devices often allow the device administrator to select a
specific DNS resolver to use on certain networks, or on all networks.
Historically, this selection was specified only with an IP address.
In doing so it is critical that the new resolver is an equivalent
resolver.  Switching to a non-equivalent alternative resolver would
break the expectation of the user who previously selected that
resolver.
Virtual Private Networks (VPNs) also can provision DNS resolvers.  In
addition to being able to use DHCP or RAs, VPNs can provision DNS
information in an explicit configuration message.  For example, IKEv2
can provision DNS servers using Configuration Attributes RFC7296.
VPNs can also configure Split DNS rules to limit the use of the
configured resolvers to specific domain names RFC8598.
Discovering an encrypted resolver that is provisioned by a VPN can
provide the same benefits as doing so for a local network, but
applied to the private network.  When using Split DNS, it becomes
possible to use one encrypted resolver for private domains, and
another for other domains.
Similar to how VPN DNS configurations can use Split DNS for private
names, other network environments can support resolution of names
that are specific to the local environment.  For example, an
enterprise-managed Wi-Fi network might be able to access both the
Internet and a private intranet.  In such a scenario, the private
domains managed by the enterprise might only be resolvable using a
specific DNS resolver.
Discovering an encrypted resolver for a subset of names allows a
client to perform Split DNS while maintaining the benefits of
encrypted DNS.  For example, a client could use a client-selected
encrypted resolver for public domains, but use a different encrypted
resolver for enterprise-private domains.
Such domain-specific resolver discovery mechanisms additionally need
to provide some information about the applicability and capabilities
of encrypted resolvers.  This information can either be provisioned
or can be discovered based on clients actively trying to access
content.
Accessing locally-hosted content can require the use of a specific
resolver.  For example, captive networks or networks with walled-
garden content like media on airplane Wi-Fi networks can rely on
using a resolver hosted on the local network.
The first point can occur in a hybrid deployment, e.g. when the local
resolver is unencrypted but a central one is encrypted.  Clients
choosing the encrypted resolver for most queries will need to be
advised to refer to the local one for some names.
This case also include accessing content specific to a home network.
All security considerations relevant to a particular use case are
described under that section.  Additional consideration common to all
of them are described here.
As stated above, an enterprise-managed Wi-Fi network might be able to
access both the Internet and a private intranet.  The private domains
managed by the enterprise might only be resolvable using a specific
DNS resolver, hence use of that resolver is essential for such
domains.  However it does not necessarily mean that all queries for
all domains have to flow through that resolver.
Only sending the necessary queries through the enterprise resolver,
and not generic Internet queries, has the privacy benefit of only
exposing traffic to the enterprise that fall within a limited set of
domains.
Using encrypted DNS for private names also opens up the possibility
of doing private name resolution outside of the content of a VPN or
managed network.  If the DNS resolver authenticates clients, it can
offer its resolver for private names on a publicly accessible server,
while still limiting the visibility of the DNS traffic.
Content Delivery Networks (CDNs), and content-providers more broadly,
can also provide encrypted DNS resolvers that can be used by clients
over the public Internet.  These resolvers can either allow
resolution of all public names (like normal recursive resolvers), or
be designed to serve a subset of names managed by the content
provider (like an authoritative resolver).  Using these resolvers can
allow the content provider to directly control how DNS answers are
used for load balancing and address selection, which could improve
performance of connections to the content provider.
Clients cannot assume that their network does not have such an
attacker unless given some means of authenticating or otherwise
trusting the communication with their DNS resolver.
Redirect secure DNS traffic to themselves when they would not
otherwise handle DNS traffic.
Override or interfere with the resolver preferences of a user or
administrator.
Cause clients to use a discovered resolver which has no
authenticated delegation from a client-known entity.
Influence automatic discovery mechanisms such that a client uses
one or more resolvers that are not otherwise involved with
providing service to the client, such as: a network provider, a
VPN server, a content provider being accessed, or a server that
the client has manually configured.
Beyond these requirements, standards describing resolver discovery
mechanisms must not place any requirements on clients to select
particular resolvers over others.
When discovering DNS resolvers on a local network, clients have no
mechanism to distinguish between cases where an active attacker with
the above capabilities is interfering with discovery, and situations
wherein the network has no encrypted resolver.  Absent such a
mechanism, an attacker can always succeed in these goals.  Therefore,
in such circumstances, viable solutions for local DNS resolver
discovery should consider weaker attackers, such as those with only
passive eavesdropping capabilities.  It is unknown whether such
relaxations represent a realistic attacker in practice.  Thus, local
discovery solutions designed around this threat model may have
limited value.
Opportunistic encrypted DNS, when the client cannot authenticate the
entity that provides encrypted DNS, does not meet the requirements
laid out here for resolver discovery.  While opportunistic encryption
can provide some benefits, specifically in reducing the ability for
other entities to observe traffic, it is not a viable solution
against an on-path attacker.
Performing opportunistic encrypted DNS does not require specific
discovery mechanisms.  Section 4.1 of RFC7858 already describes how
to use DNS-over-TLS opportunistically.
Even with encrypted DNS resolver discovery in place, clients must be
prepared to handle certain scenarios where encrypted DNS cannot be
used.  In these scenarios, clients must consider if it is appropriate
to fail open by sending the DNS queries without encryption, fail
closed by not doing so, or presenting a choice to a user or
administrator.  The exact behavior is a local client policy decision.
Some networks that use Captive Portals will not allow any Internet
connectivity until a client has interacted with the portal I-D.ietf-
capport-architecture.  If these networks do not use encrypted DNS for
their own resolution, a client will need to perform unencrypted DNS
queries in order to get out of captivity.  Many operating systems
have specific client code responsible for detecting and interacting
with Captive Portals; these system components may be good candidates
for failing open, since they do not generally represent user traffic.
Other networks may not allow any use of encrypted DNS, or any use of
encrypted DNS to resolvers other than a network-provisioned resolver.
Clients should not silently fail open in these cases, but if these
networks are trusted by or administered by the user, the user may
want to specifically follow the network's DNS policy instead of what
the client would do on an unknown or untrusted network.
All security considerations relevant to a particular use case are
described under that section.  Additional considerations common to
all of them are described in priv-sec.