Draft: draft-add-requirements

Commentary: This PR simplifies further by removing any mention of properties of the encrypted resolvers , or properties of the relationship between the Do53 and the encrypted resolver . It now purely focusses on the ability of an untrusted network or resolver to designate other encrypted resolvers . This is an assertion that the encrypted resolver is safe and appropriate to use , but little else . Clients will of course make their own decisions about whether to use designated resolvers or not . Other drafts will look at trusted networks , and communicating information that can be useful to clients as part of the untrusted decision - making . 
 comments 
 comments on the draft02 
 It was pointed out that this should be limited to IETF - standardised encrypted DNS protocols rather than potentially including DNSCrypt and being very open - ended .
Adaptive DNS Discovery is chartered to define mechanisms that allow
clients to discover and select encrypted DNS resolvers.  This
document describes one common use case, that of discovering the
encrypted DNS resolver that corresponds to the Do53 resolver offered
by a network.  It lists requirements that any proposed discovery
mechanisms should address.
Adaptive DNS Discovery is chartered to define mechanisms that allow
clients to discover and select encrypted DNS resolvers.  This
document describes one common use case, namely that of clients that
connect to a network but where they cannot securely authenticate the
identity of that network.  In such cases the client would like to
learn which encrypted DNS resolvers are designated by that network or
by the Do53 resolver offered by that network.  It lists requirements
that any proposed discovery mechanisms should seek to address.
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 currently focusses on one common use case, that of
discovering the encrypted DNS resolver that corresponds to the Do53
resolver offered by a network.  Additional use cases can be added in
future versions.  As well as describing the use case, it lists
requirements that any proposed discovery mechanisms should address.
They can do this either by providing a solution, or by explicitly
stating why it is not in scope.
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 one common use case, namely that of clients
that connect to a network but where they cannot securely authenticate
that network.  Whether the network required credentials before the
client was permitted to join is irrelevant; the client still cannot
be sure that it has connected to the network it was expecting.
In such cases the client would like to learn which encrypted DNS
resolvers are designated by that network, or by the Do53 resolver
offered by that network.  It lists requirements that any proposed
discovery mechanisms should seek to address.  They can do this either
by providing a solution, or by explicitly stating why it is not in
scope.
Equivalent: See equivalence.
It is often the case that a client possesses no specific
configuration for how to operate DNS, and at some point joins a
network that it has no previous knowledge about.  In such a case the
usual existing behaviour is to dynamically discover the network's
recommended Do53 resolver and use it.  This long-standing practice
works in nearly all networks, but presents a number of privacy and
security risks that were the motivation for the development of
encrypted DNS.
The network's recommended unencrypted resolver may have a number of
properties that differ from a generic resolver.  It may be able to
answer names that are not known globally, it may exclude some names
(for positive or negative reasons), and it may provide address
answers that have improved proximity.  In this use case it is assumed
that the user who chose to join this network would also like to make
use of these properties of the network's unencrypted resolver, at
least some of the time.  However they would like to use an encrypted
DNS protocol rather than Do53.
Designated: See designation.
Designator: The network or resolver that issued the designation.
It is often the case that a client possesses no specific
configuration for how to operate DNS, and at some point joins a
network that it cannot authenticate.  It may have no prior knowledge
of the network, or it may have connected previously to a network that
looked the same.  In either case the usual behaviour, because of lack
of specific configuration, is to dynamically discover the network's
designated Do53 resolver and use it.  This long-standing practice
works in nearly all networks, but presents a number of privacy and
security risks that were the motivation for the development of
encrypted DNS.
The network's designated Do53 resolver may have a number of
properties that differ from a generic resolver.  It may be able to
answer names that are not known globally, it may exclude some names
(for positive or negative reasons), and it may provide address
answers that have improved proximity.  In this use case it is assumed
that the user who chose to join this network would also like to make
use of these properties of the network's unencrypted resolver, at
least some of the time.  However they would like to use an encrypted
DNS protocol rather than Do53.
To meet this case there should be a means by which the client can
learn how to contact an encrypted DNS resolver that provides
equivalent responses as the ones served by the network's recommended
unencrypted resolver.  It is not a requirement that these two
resolvers are the same physical or logical machine.  Often they will
be, but they could equally be separated, perhaps by hundreds of
miles.  However it is deployed, the key is that they are equivalent.
Given two resolvers A and B, equivalence is the claim that A and B
can provide the same upper-layer DNS function to the client.  This
does not include the DNS transport protocol (e.g.  Do53 or DNS-over-
HTTPS) which can differ between equivalent resolvers.  To provide
equivalence it is frequently likely to be the case that A and B are
operated by the same administrative domain, but this document does
not require that.
There are two possible ways to claim equivalence.
The local network can claim that one or more encrypted DNS
resolvers (B, C, etc) are equivalent to the Do53 resolver (A) it
has offered.  This is known as network-identified.
During communication with the (often unencrypted) resolver (A),
this resolver can claim that one or more encrypted DNS resolvers
(B, C, etc) are equivalent.  This is known as resolver-identified.
Network-identified is preferred since it comes from the same source
of information, and removes the need to talk to the Do53 resolver at
all.  However it cannot be the sole mechanism, at least for several
years, since there is a large installed base of local network
equipment that is difficult to upgrade with new features.  Hence the
second mechanism must support being able to announce an equivalent
resolver using only existing widely-deployed DNS features.
To meet this case there should be a means by which the client can
learn how to contact a set of encrypted DNS resolvers that are
designated by the network it has joined.
The designated set could be empty, or it could list the contact
details (such as DoH URI Template) of DNS resolvers that it
recommends.  It is not required that there be any relationship
between the resolvers in the set, simply that all of them are options
that the designator asserts are safe and appropriate for the client
to use without user intervention.
There are two possible sources of designation.
The local network can designate one or more encrypted DNS
resolvers (B, C, etc) in addition to any Do53 resolver (A) it may
offer.  This is known as network-identified.
During communication with the (often unencrypted) resolver (A),
this resolver can designate one or more encrypted DNS resolvers
(B, C, etc).  This is known as resolver-identified.
Network-identified has the advantages that it derives from the same
source of information as the network's Do53 announcement, and removes
the need to talk to the Do53 resolver at all.  However it cannot be
the sole mechanism, at least for several years, since there is a
large installed base of local network equipment that is difficult to
upgrade with new features.  Hence the second mechanism should support
being able to designate resolvers using only existing widely-deployed
DNS features.
After the client receives designation information, it must come to a
decision on whether and when to use any of the designated resolvers.
In the case of resolver-identified designation, it would be
advantageous for a solution to enable the client to validate the
source of the assertion in some way.  For example it may be possible
to verify that the designation comes from an entity who already has
full control of the client's Do53 queries.  Network-identified
designation should not require this, unless the network-identified
resolver in turn initiated a new resolver-identified designation.  It
would be beneficial to extend such a verification process to defend
against attackers that have only transient control of such queries.
Clients may also seek to validate the identity of the designated
resolver, beyond what is required by the relevant protocol.  Authors
of solution specifications should be aware that clients may impose
arbitrary additional requirements and heuristics as they see fit.
A solution is required that enhances the set of information delivered
to include details of one or more equivalent encrypted DNS resolvers,
or states that there are none.
To support cases where the network is unable to identify an encrypted
resolver, it should be possible to learn the details of one or more
equivalent encrypted DNS resolvers by communicating with the network-
recommended unencrypted Do53 resolver.  This should involve an
exchange that uses standard DNS messages that can be handled, or
forwarded, by existing deployed software.
It is frequently the case that Do53 resolvers announced by home
networks are difficult to upgrade to support encrypted operation.  In
such cases it is possible that the only option for encrypted
operation is to refer to a separate globally-addressed encrypted DNS
resolver.
A solution is required that enhances the set of information delivered
to include details of one or more designated encrypted DNS resolvers,
or states that there are none.  Such resolvers could be on the local
network, somewhere upstream, or on the public Internet.
To support cases where the network is unable to identify an encrypted
resolver, it should be possible to learn the details of one or more
designated encrypted DNS resolvers by communicating with the
network's designated Do53 resolver.  This should involve an exchange
that uses standard DNS messages that can be handled, or forwarded, by
existing deployed software.
Each resolver in the set may be at a different network location,
which leads to several subcases for the mapping from Do53 to a
particular designated resolver.
Clients will be aware when the designated resolver has the same IP
address as the Do53 (after looking up its name if required).  They
can use this information in their decision-making as to the level of
trust to place in the designated resolver.  In some networks it will
not be possible to deploy encrypted DNS on the same IP address, e.g.
because of the increased resource requirements of encrypted DNS.
Discovery solutions should work in the presence of a change to a
different local IP address.
It is frequently the case that Do53 resolvers announced by home
networks are difficult to upgrade to support encrypted operation.  In
such cases it is possible that the only option for encrypted
operation is to refer to a separate globally-addressed encrypted DNS
resolver, somewhere upstream.  Other networks may choose deploy their
encrypted DNS resolver away from the local network, for other
reasons.
The use of an upstream resolver can mean the loss of local knowledge,
such as the ability to respond to queries for locally-relevant names.
Solutions should consider how to guide clients when to direct their
queries to the local Do53.  For example this could be through pre-
emptive communication ("if you ever need to query *.example.com, use
your local Do53"), or reactively ("I don't know the answer to that,
but your local Do53 should know").
In cases where the local network has designated a Do53 resolver on
the public Internet, this resolver may designate its own or another
public encrypted DNS service.  Since public IP addresses may appear
in TLS certificates, solutions may use this as one way to validate
that the designated encrypted resolver is legitimately associated
with the original Do53.
In cases where the designation is delivered over an authenticated and
encrypted channel, such as when one encrypted DNS resolver designates
another, one form of attack is removed.  Specifically, clients may be
more confident that the received designation was actually sent by the
designator.  Clients may take this into account when deciding whether
to follow the designation.
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.
Cause clients to use a discovered resolver which has no
designation from a client-known entity.