Define what is meant by “authenticated”

[chris-box]

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.

-glenn

Originally posted by @gitnnelg in https://github.com/ietf-wg-add/draft-add-requirements/pull/2#issuecomment-680215555

[chris-box]

Tiru also commented "Several possible ways of authenticating the encrypted DNS server are already discussed in our spec https://tools.ietf.org/html/rfc8310#section-8. I don't think the requirements draft should discuss the possible modes of authenticating the server."

[magicalo]

agree - authentication can include mutual authentication

[JoGSal]

+1 to different means/level depending on environment. I think mandatory should be validation of resolver designation through any of the 4 methods described in draft-pauly-add-resolver-discovery (validation using DNSSEC / PvD file / file on a well-known HTTPS URI based on zone apex / TLS certificates). Then the actual resolver chosen and their ownership over the encrypted services, similar to what's on Google's policy , then client authentication for use-cases like the enterprise network