4. Usage Profiles
This protocol provides flexibility to accommodate several different use cases. This document defines two usage profiles: (1) opportunistic privacy and (2) out-of-band key-pinned authentication that can be used to obtain stronger privacy guarantees if the client has a trusted relationship with a DNS server supporting TLS. Additional methods of authentication will be defined in a forthcoming document [TLS-DTLS-PROFILES].
4.1 Opportunistic Privacy Profile
For opportunistic privacy, analogous to SMTP opportunistic security [RFC7435], one does not require privacy, but one desires privacy when possible.
With opportunistic privacy, a client might learn of a TLS-enabled recursive DNS resolver from an untrusted source. One possible example flow would be if the client used the DHCP DNS server option [RFC3646] to discover the IP address of a TLS-enabled recursive and then attempted DNS over TLS on port 853. With such a discovered DNS server, the client might or might not validate the resolver. These choices maximize availability and performance, but they leave the client vulnerable to on-path attacks that remove privacy.
Opportunistic privacy can be used by any current client, but it only provides privacy when there are no on-path active attackers.
4.2 Out-of-Band Key-Pinned Privacy Profile
The out-of-band key-pinned privacy profile can be used in environments where an established trust relationship already exists between DNS clients and servers (e.g., stub-to-recursive in enterprise networks, actively maintained contractual service relationships, or mobile applications that are configured to use a particular DNS server). For the purposes of this profile, the term "out-of-band" means a configuration mechanism that is outside the scope of this document.
This privacy profile constrains privacy to one of the following:
-
The client requires the server identity to match a Subject Public Key Info (SPKI) pin set that has been configured out of band for that server.
-
The client requires the server identity to authenticate using a certificate authority that has been configured out of band as a trust anchor for that server.
DNS clients using the out-of-band key-pinned privacy profile establish TLS connections following the procedure given in Section 3, but they MUST also authenticate the server using the pinned key or trust anchor that is configured out of band. Out-of-band key-pinned privacy clients SHOULD be configured with a single key identifier. For SPKI pin sets, implementations MUST support raw public key authentication per [RFC7250].
If the authentication attempt fails, the out-of-band key-pinned privacy client MUST refuse to send any DNS queries over that TLS connection. It MUST NOT fall back to communicating over any cleartext connection. For cases where the client also has other servers (perhaps over cleartext DNS) configured concurrently with the out-of-band key-pinned privacy server, the client MAY fall back to those other servers.
When authenticating using only an out-of-band SPKI pin set, the client MUST use public key pinning as described in [RFC7469]. In such cases, the TLS server's certificate or public key is matched against one or more "known-good" SPKI fingerprints. In constraining the server's identity using only pinned SPKI fingerprints, the client's trust anchor is the SPKI fingerprint itself. The server itself does not send the trust anchor in its certificate chain.
The client can perform proof of possession of the private key of the pinned server key via the handshake. The security of the SPKI pin set privacy profile is predicated on the secrecy and integrity of the preconfigured SPKI values used for authentication. Appendix A provides an example of how SPKI fingerprints can be generated.