]> Microsoft

tojens.ietf@gmail.com

Microsoft

jess.krynitsky@microsoft.com

Amazon

jdamick@amazon.com

Amazon

mengskow@amazon.com

Cloudflare

jabley@cloudflare.com

DNS encrypted DNS authentication client authentication mTLS Some encrypted DNS clients require anonymity from their encrypted DNS servers to prevent third parties from correlating client DNS queries with other data for surveillance or data mining purposes. However, there are cases where the client and server have a pre-existing relationship and each wants to prove its identity to the other. For example, an encrypted DNS server may only wish to accept queries from encrypted DNS clients that are managed by the same enterprise, and an encrypted DNS client may need to confirm the identity of the encrypted DNS server it is communicating with. This requires mutual authentication. This document discusses the circumstances under which client authentication is appropriate to use with encrypted DNS, the benefits and limitations of doing so, and recommends authentication mechanisms to be used when communicating with TLS-based encrypted DNS protocols.

Introduction There are times when a client needs to authenticate itself before it can be authorised to use a DNS server. One example is when an encrypted DNS server only accepts connections from pre-approved clients, such as an encrypted DNS service provided by an enterprise for its remote employees. Encrypted DNS clients trying to connect to such a server might experience refused connections if they did not provide authentication that allows the enterprise's server to authorise its use. This is different from general use of encrypted DNS by anonymous clients to public DNS resolvers, where it is bad practice for the client to provide any kind of identifying information to the server. For example, Section 8.2 of discourages use of HTTP cookies with DNS-over-HTTPS (DoH). This ensures that clients provide a minimal amount of identifiable or correlatable information to servers that do not need to know anything about the client in order to provide name resolution. Because of the significant difference in these scenarios, it is important to define the situations in which interoperable encrypted DNS clients can use client authentication without compromising the privacy provided by encrypted DNS in the first place. Even then, it is important to recognize what value client authentication provides to encrypted DNS clients versus encrypted DNS servers in the context of both connection management and DNS resolution utility. This document discusses these topics and recommends best practice for authentication.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

Terminology Encrypted DNS server: a recursive DNS resolver that implements one or more encrypted DNS protocols, such as those defined in (DNS-over-TLS, DNS-over-HTTPS, DNS-over-QUIC). Protective DNS server: a policy-implementing, recursive DNS resolver service that filters DNS queries to prevent resolution for known malicious domains and/or IP addresses. Protective DNS servers support DNS technologies including encrypted DNS protocol support (DoH/DoT) and IPv6 resolution. Other terminology related to the DNS is used in this document as defined in .

Benefits of client authentication with encrypted DNS Strong identification of encrypted DNS clients by the encrypted DNS server allows the DNS server to apply client-specific resolution policies in a securely-verifiable way. Today, a common practice is to establish client-specific resolution policies that are applied on behalf of particular clients based on their observed IP address. This is not only an insecure method that cannot account for clients sending requests through middleboxes, but it can only be used when expected IP addresses are known in advance. This is not practical for enterprises with remote employees without introducing a dependency on tunneling DNS traffic to a managed gateway or proxy whose IP address is known. This in turn forces enterprises to choose between running proxy or gateway infrastructure per client (or at least per-client IP address mappings) or losing client identification. Strong identification of encrypted DNS clients by the encrypted DNS server also brings identification up to the application layer, which insulates the mechanism used for identity management from network topology changes and allows the sense of client identity in the server to persist despite client IP address changes.

Drawbacks of client authentication with encrypted DNS While there are benefits in using client authentication with encrypted DNS in limited circumstances, authentication has drawbacks that make it inappropriate in many other cases. For example, client authentication is generally considered to be bad practice in uses of encrypted DNS that are motivated by client anonyminity, since it allows a full history of resolution requests to be associated confidently with the identity of an individual client. This is unacceptable practice. Public DNS servers generally implement allowlists and blocklists at the IP layer as part of a layered defence against abuse; IP-layer access control allows unwanted traffic to be discarded early and helps mitigate unwanted server load. Public encrypted DNS servers with the additional requirement to permit authenticated clients makes it impossible to drop unwanted traffic early based on source IP address, which increases the cost of mitigation and adds complexity that may introduce additional attack vectors.

When to use client authentication with encrypted DNS Encrypted DNS servers that provide resolution using transport protocols that incorporate TLS or dTLS such as DoH , DoT , and DoQ SHOULD NOT provide client authentication except in the limited situations described in this section. Encrypted DNS servers that use other transport protocols are not in scope for this document.

When servers should require client authentication Encrypted DNS servers MUST NOT challenge clients for authentication unless they need to restrict connections to a set of clients they have a pre-existing relationship with as defined in {restrict-clients}, regardless of whether or not the requirements in {per-client} apply. Encrypted DNS servers also MUST NOT challenge clients for authentication when it knows its identity cannot be securely verified. Examples of this include using self-signed certificates or making itself discoverable using DDR's Discovery Using Resolver IP Addresses mechanism described in . Encrypted DNS servers that meet the requirements in {restrict-clients} MAY challenge clients to authenticate to avoid achieving the same goal of identifying clients through other, less secure means (such as IP address or data in the DNS query payload).

Restricting connections to allowed clients An encrypted DNS server that provides resolution to a specific set of clients and refuses service to all other clients MAY require clients to authenticate. For example, an encrypted DNS server owned by an enterprise that only allows connections from devices managed by that same enterprise might require clients to authenticate. Note that this does not apply to scenarios where the owner of the encrypted DNS server and the device using the encrypted DNS client, such as an ISP and its customers. While this is a scenario where the ISP may wish to restrict access to its encrypted DNS resolver to only its customers, client authentication of DNS traffic is not necessary to achieve that.

Resolving names differently per client An encrypted DNS server that provides client-specific resolution behaviour MAY require clients to authenticate in circumstances where the appropriate policy for particular clients is specified by the operator of the encrypted DNS server. For example, an encrypted DNS server that is configured to allow some clients to resolve certain names while other clients are not allowed needs to identify the client so that the resolution behaviour for those names can be implemented accurately. Encrypted DNS servers SHOULD NOT attempt to authenticate clients to identify the appropriate resolution policy to use when the difference in resolution behavior between them is not imposed by the operator of the server but instead is chosen by the client. For example, some public encrypted DNS services provide clients with the option of blocking resolution requests for particular categories of domain names, such as names associated with malware distribution, adult content or advertisers, and makes servers with particular resolution policies available on different IP addresses. A client who wishes to opt-in to a server with a particular resolution policy can do so by sending queries to the corresponding IP address, and no client identification is required.

When clients should attempt to authenticate An encrypted DNS client MUST NOT offer authentication to any encrypted DNS server unless it was specifically configured to expect that server to require authentication, independent of the mechanism by which the client chose or discovered the encrypted DNS server to use. In other words, encrypted DNS client authentication MUST require administrator action typical of enterprise managed devices rather than being out of the box default behavior for an application or operating system. An encrypted DNS client MUST NOT offer authentication when the server connection was established using , even if the IP address of the original DNS server was specifically configured for the encrypted DNS client as one that might require authentication. This is because in that circumstance there is not a pre-existing relationship with the encrypted DNS server (or else DDR bootstrapping into encrypted DNS would not have been necessary). An encrypted DNS client MAY choose to present authentication to a server that requests it, but is not required to do so; for example, a client MAY choose instead not to use the server. If a client does present an identity to a server, the identity SHOULD be unique to that server, or unique to servers provided by the same provider when the client has that information, to reduce the risk of a client's resolution history on multiple colluding providers being correlated.

Recommendations for authentication mechanisms This section enumerates recommended considerations for selecting a client authentication mechanism and recommends solutions to guide implementors who wish to maximize chances of interoperability wherever other implementations hold the same considerations. The following requirements were considered when formulating the recommended authentication mechanism for encrypted DNS clients. it is RECOMMENDED that authentication mechanisms:

1. be per-connection, not per-query, e.g. to avoid unnecessary payload overheads
2. use open, standard mechanisms where possible, e.g. to avoid vendor lock-in and specialized cryptography
3. be reusable across multiple encrypted DNS protocols, e.g. to avoid protocol preference
4. not require human user interaction to complete authentication
5. be resistant to replay attacks

This document concludes that the best current mechanism available to recommend for enabling interoperable encrypted DNS client authentication is mTLS for the following reasons:

1. mTLS identifies and authenticates clients, not users, per-connection
2. mTLS is an existing standard and is often readily available for TLS clients
3. X.509 certificates used for TLS client authentication allow a server to include other attributes in an authentication decision, such as the client's organization via PKI hieracrchy
4. mTLS is reusable across multiple encrypted DNS protocols
5. mTLS allows session resumption
6. mTLS does not require user interaction or apaplication layer input for authentication

Encrypted DNS clients and servers that support offering or requesting client authentication SHOULD support at least the use of mTLS with TLS 1.3 in addition to whatever other mechanism they wish to support. Client authentication using PKI certificates is RECOMMENDED, but pre-shared keys MAY also be used to meet the requirements listed above for recommendable practices, provided (EC)DHE key exchange is used to maintain perfect forward secrecy . Versions of TLS lower than 1.3 lack some security features that new protocols (as of this writing) are taking for granted or making recommended behavior. When TLS 1.3 is discouraged in favor of future versions of TLS or its future replacement, that guidance supercedes this paragraph. Encrypted DNS clients and servers SHOULD prefer long-lived connections when using client authentication to minimize the cost over time of doing repeated TLS handshakes and identity verification.

Why these requirements were chosen

Per-connection scope Any data added to each DNS message will have greater bandwidth and processing costs than presenting authentication once per connection. This is especially true in this case because the drawback of having long-running encrypted DNS connections is the decreased privacy through increased volume of directly correlatable queries. However, this privacy threat does not apply to this situation because the client's queries can already be correlated by the identity it presents. Therefore, per-connection bandwidth and data processing overhead is expected to be much lower than per-query because there is no incentive for clients and servers to not have long-running encrypted DNS connections. This is not expected to create excessive cost for server operators because supporting encrypted DNS without client authentication already requires per-connection state management.

Reusable open standards Reusing open standards ensures wide interoperability between vendors that choose to implement client authentication in their encrypted DNS stacks.

Reusable across protocols If a client authentication method for encrypted DNS were defined or recommended that would only be usable by some TLS-encrypted DNS protocols, it would encourage the development of a second or even third solution later.

Does not require human interaction Humans using devices that use encrypted DNS, when given any kind of prompt or login relating to establishing encrypted DNS connectivity, are unlikely to understand what is happening and why. This will inevitably lead to click-through behavior. Because the scope of scenarios where client authentication for encrypted DNS is limited to pre-existing relationships between the client and server, there should be no need for at-run-time intervention by a human user.

Resistance to replay attacks Today, there are some attempts to identify clients that involve use of client- specific DoH templates or DoT hostnames, addition of magic strings to requests, and other mechanisms to enable proprietary experiences. It is important that recommendations for client authentication are restricted to mechanisms that protect their secrets or keys from replay attacks or compromise by unprivileged processes.

Why alternatives are not recommended

Web tokens OAuth or JSON web tokens alone require HTTP to validate, so would not be a solution for encrypted DNS protocols other than DoH. Web access tokens can be used as certificate-bound access tokens in combination with mTLS if they are needed to prove identity with another authorization server, as described in .

HTTP authentication HTTP authentication as defined in provides a basic authentication scheme for the HTTP protocol. Unless it is used with TLS, i.e. over HTTPS, the credentials are encoded but not encrypted which is insecure. As TLS is already used by the encrypted DNS protocols in this document's scope, it is simpler to handle client authentication and authorization at the TLS layer. Additionally, mTLS is more broadly-adopted than HTTP authentication. HTTP authentication would only be a viable option for DoH, and not extensible to other encrypted DNS solutions.

FIDO Web Authentication (WebAuthN) and the FIDO2 Client to Authenticator Protocol (CTAP) use CBOR Object Signing and Encryption (COSE), described in . FIDO and WebAuthN are passkey solutions designed to replace passwords for user authentication for online services, and they are not typically used for general client authentication. Passkeys are unique for each online service and require user input for registration, and would require DNS servers to support the WebAuthN protocol. Additionally, each sign-in requires user input for local verification, using biometric, local PIN, or a FIDO security key.

Designing a novel solution Designing a novel solution is never recommended when there is an existing standard that meets the requirements. Doing so would make the encrypted DNS solution more difficult and time-consuming to adopt, and most likely would introduce vendor lock-in.

Operational Considerations

Avoiding connectivity deadlocks When deploying encrypted DNS Clients, careful consideration should be made how certificate rollover and revocation will happen. If an encrypted DNS server only allows connections from clients with valid certificates, and the client is configured to only use the encrypted DNS server, then there will be a deadlock when the certificate expires or is revoked such that the client device will not have the connectivity needed to renew or replace its certificate. Encrypted DNS servers that challenge clients for authentication SHOULD have a separate resolution policy for clients that do not have valid credentials that allows them to resolve the subset of names needed to connect to the infrastructure needed to acquire certificates. Alternatively, encrypted DNS clients that are configured to use encrypted DNS servers that will require authentication MAY consider configuring knowledge of certificate issuing infrastructure in advance so that the DNS deadlock can be avoided without introducing less secure DNS servers to their configuration (i.e. hard coding IP addresses and host names for certificate checking).

Security Considerations This document describes when and how encrypted DNS clients can authenticate themselves to an encrypted DNS server. It does not introduce any new security considerations beyond those of TLS and mTLS. This document does not define recommendations for when and how to use encrypted DNS client authentication for encrypted DNS protocols that are not based on TLS or dTLS.

Custom Deployments This document was written to provide guidance to implementors interoperating with third party implementations to maximize the chances of out-of-the-box compatibility. There are certainly many ways of accomplishing client authentication with encrypted DNS not listed as recommended practice here. Implementors are encouraged to use the reasoning in this document explaining its choice in recommendations, but not following this document's recommendations does not imply any violation of protocol compliance for encrypted DNS protocols or whatever authentication mechanism the implementor selects.

Use of DNS for Indicators of Compromise DNS queries can sometimes act as a source of Indicators of Compromise , further placing value on strong client authentication when it is appropriate as discussed in earlier sections. Deployers should weigh the recommendations and reasoning in this document against their threat models to ensure their Protective DNS deployments provide useful Indicators of Compromise in addition to the need for interoperability.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. Cyber defenders frequently rely on Indicators of Compromise (IoCs) to identify, trace, and block malicious activity in networks or on endpoints. This document reviews the fundamentals, opportunities, operational limitations, and recommendations for IoC use. It highlights the need for IoCs to be detectable in implementations of Internet protocols, tools, and technologies -- both for the IoCs' initial discovery and their use in detection -- and provides a foundation for approaches to operational challenges in network security. Informative References This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. This document defines Discovery of Designated Resolvers (DDR), a set of mechanisms for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An Encrypted DNS Resolver discovered in this manner is referred to as a "Designated Resolver". These mechanisms can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. These mechanisms are designed to be limited to cases where Unencrypted DNS Resolvers and their Designated Resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an Encrypted DNS Resolver is known. This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. The W3C Web Authentication (WebAuthn) specification and the FIDO Alliance FIDO2 Client to Authenticator Protocol (CTAP) specification use CBOR Object Signing and Encryption (COSE) algorithm identifiers. This specification registers the following algorithms (which are used by WebAuthn and CTAP implementations) in the IANA "COSE Algorithms" registry: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1; and Elliptic Curve Digital Signature Algorithm (ECDSA) using the secp256k1 curve and SHA-256. It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry. Also, for use with JSON Object Signing and Encryption (JOSE), it registers the algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA "JSON Web Signature and Encryption Algorithms" registry and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry.

Acknowledgments The authors are grateful to the following individuals for their feedback on or contributions to the text, with no implication of endorsement: Andrew S2, Ben Schwartz, Erik Nygren, Jim Reid, Q Misell, Tim Wicinski, Tobias Fiebig, Warren Kumari, Wes Hardaker.