1. Introduction
1.1. Background and Motivation
Applications that communicate over the Internet often need to prevent eavesdropping, tampering, or forgery of their communications. The Transport Layer Security (TLS) protocol provides this kind of communications security over the Internet, using channel encryption.
The security properties of encryption systems depend strongly on the keys that they use. If secret keys are revealed, or if public keys can be replaced by fake keys (that is, a key not corresponding to the entity identified in the certificate), these systems provide little or no security.
TLS uses certificates to bind keys and names. A certificate combines a published key with other information such as the name of the service that uses the key, and this combination is digitally signed by another key. Having a key in a certificate is only helpful if one trusts the other key that signed the certificate. If that other key was itself revealed or substituted, then its signature is worthless in proving anything about the first key.
On the Internet, this problem has been solved for years by entities called "Certification Authorities" (CAs). CAs protect their secret key vigorously, while supplying their public key to the software vendors who build TLS clients. They then sign certificates, and supply those to TLS servers. TLS client software uses a set of these CA keys as "trust anchors" to validate the signatures on certificates that the client receives from TLS servers. Client software typically allows any CA to usefully sign any other certificate.
The public CA model upon which TLS has depended is fundamentally vulnerable because it allows any of these CAs to issue a certificate for any domain name. A single trusted CA that betrays its trust, either voluntarily or by providing less-than-vigorous protection for its secrets and capabilities, can undermine the security offered by any certificates employed with TLS. This problem arises because a compromised CA can issue a replacement certificate that contains a fake key. Recent experiences with compromises of CAs or their trusted partners have led to very serious security problems, such as the governments of multiple countries attempting to wiretap and/or subvert major TLS-protected web sites trusted by millions of users.
The DNS Security Extensions (DNSSEC) provide a similar model that involves trusted keys signing the information for untrusted keys. However, DNSSEC provides three significant improvements. Keys are tied to names in the Domain Name System (DNS), rather than to arbitrary identifying strings; this is more convenient for Internet protocols. Signed keys for any domain are accessible online through a straightforward query using the standard DNSSEC protocol, so there is no problem distributing the signed keys. Most significantly, the keys associated with a domain name can only be signed by a key associated with the parent of that domain name; for example, the keys for "example.com" can only be signed by the keys for "com", and the keys for "com" can only be signed by the DNS root. This prevents an untrustworthy signer from compromising anyone's keys except those in their own subdomains. Like TLS, DNSSEC relies on public keys that come built into the DNSSEC client software, but these keys come only from a single root domain rather than from a multiplicity of CAs.
DNS-Based Authentication of Named Entities (DANE) offers the option to use the DNSSEC infrastructure to store and sign keys and certificates that are used by TLS. DANE is envisioned as a preferable basis for binding public keys to DNS names, because the entities that vouch for the binding of public key data to DNS names are the same entities responsible for managing the DNS names in question. While the resulting system still has residual security vulnerabilities, it restricts the scope of assertions that can be made by any entity, consistent with the naming scope imposed by the DNS hierarchy. As a result, DANE embodies the security "principle of least privilege" that is lacking in the current public CA model.
1.2. Securing the Association of a Domain Name with a Server's Certificate
A TLS client begins a connection by exchanging messages with a TLS server. For many application protocols, it looks up the server's name using the DNS to get an Internet Protocol (IP) address associated with the name. It then begins a connection to a particular port at that address, and sends an initial message there. However, the client does not yet know whether an adversary is intercepting and/or altering its communication before it reaches the TLS server. It does not even know whether the real TLS server associated with that domain name has ever received its initial messages.
The first response from the server in TLS may contain a certificate. In order for the TLS client to authenticate that it is talking to the expected TLS server, the client must validate that this certificate is associated with the domain name used by the client to get to the server. Currently, the client must extract the domain name from the certificate and must successfully validate the certificate, including chaining to a trust anchor.
There is a different way to authenticate the association of the server's certificate with the intended domain name without trusting an external CA. Given that the DNS administrator for a domain name is authorized to give identifying information about the zone, it makes sense to allow that administrator to also make an authoritative binding between the domain name and a certificate that might be used by a host at that domain name. The easiest way to do this is to use the DNS, securing the binding with DNSSEC.
There are many use cases for such functionality. [RFC6394] lists the ones to which the DNS RRtype in this document apply. [RFC6394] also lists many requirements, most of which this document is believed to meet. Section 5 covers the applicability of this document to the use cases in detail. The protocol in this document can generally be referred to as the "DANE TLSA" protocol. ("TLSA" does not stand for anything; it is just the name of the RRtype.)
This document applies to both TLS [RFC5246] and Datagram TLS (DTLS) [RFC6347]. In order to make the document more readable, it mostly only talks about "TLS", but in all cases, it means "TLS or DTLS". Although the references in this paragraph are to TLS and DTLS version 1.2, the DANE TLSA protocol can also be used with earlier versions of TLS and DTLS.
This document only relates to securely associating certificates for TLS and DTLS with host names; retrieving certificates from DNS for other protocols is handled in other documents. For example, keys for IPsec are covered in [RFC4025], and keys for Secure SHell (SSH) are covered in [RFC4255].
1.3. Method for Securing Certificate Associations
A certificate association is formed from a piece of information identifying a certificate and the domain name where the server application runs. The combination of a trust anchor and a domain name can also be a certificate association.
A DNS query can return multiple certificate associations, such as in the case of a server that is changing from one certificate to another (described in more detail in Appendix A.4).
This document only applies to PKIX [RFC5280] certificates, not certificates of other formats.
This document defines a secure method to associate the certificate that is obtained from the TLS server with a domain name using DNS; the DNS information needs to be protected by DNSSEC. Because the certificate association was retrieved based on a DNS query, the domain name in the query is by definition associated with the certificate. Note that this document does not cover how to associate certificates with domain names for application protocols that depend on SRV, NAPTR, and similar DNS resource records. It is expected that future documents will cover methods for making those associations, and those documents may or may not need to update this one.
DNSSEC, which is defined in [RFC4033], [RFC4034], and [RFC4035], uses cryptographic keys and digital signatures to provide authentication of DNS data. Information that is retrieved from the DNS and that is validated using DNSSEC is thereby proved to be the authoritative data. The DNSSEC signature needs to be validated on all responses that use DNSSEC in order to assure the proof of origin of the data.
This document does not specify how DNSSEC validation occurs because there are many different proposals for how a client might get validated DNSSEC results, such as from a DNSSEC-aware resolver that is coded in the application, from a trusted DNSSEC resolver on the machine on which the application is running, or from a trusted DNSSEC resolver with which the application is communicating over an authenticated and integrity-protected channel or network. This is described in more detail in Section 7 of [RFC4033].
This document only relates to getting the DNS information for the certificate association securely using DNSSEC; other secure DNS mechanisms are out of scope.
1.4. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
This document also makes use of standard PKIX, DNSSEC, TLS, and DNS terminology. See [RFC5280], [RFC4033], [RFC5246], and STD 13 [RFC1034] [RFC1035], respectively, for these terms. In addition, terms related to TLS-protected application services and DNS names are taken from [RFC6125].