Change:
Requirements for Adaptive DNS Discovery <del> draft-add-requirements-latest </del> <ins> draft-box-add-requirements-00 </ins> Abstract Adaptive DNS Discovery is chartered to define mechanisms that allow clients to discover and select encrypted DNS resolvers.  This <del> document seeks to provide a set of use cases and requirements that proposed mechanisms should address. </del> <ins> 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. </ins> 1. <ins> 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. </ins> The Adaptive DNS Discovery (ADD) Working Group is chartered to define <del> 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. </del> <ins> 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. </ins> <del> 2. </del> <ins> 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. 1.1. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

Discussion:
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 don’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 added 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.
Glenn I merged "authenticated" before I read this comment. I added 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 added 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 URL I don'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 cannot authenticate the unencrypted DNS server ! Originally posted by NAME in URL
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.