8. Security Considerations

The security of the DNS RRtype described in this document relies on the security of DNSSEC to verify that the TLSA record has not been altered.

A rogue DNS administrator who changes the A, AAAA, and/or TLSA records for a domain name can cause the client to go to an unauthorized server that will appear authorized, unless the client performs PKIX certification path validation and rejects the certificate. That administrator could probably get a certificate issued by some CA anyway, so this is not an additional threat.

If the authentication mechanism for adding or changing TLSA data in a zone is weaker than the authentication mechanism for changing the A and/or AAAA records, a man-in-the-middle who can redirect traffic to his site may be able to impersonate the attacked host in TLS if he can use the weaker authentication mechanism. A better design for authenticating DNS would be to have the same level of authentication used for all DNS additions and changes for a particular domain name.

Secure Socket Layer (SSL) proxies can sometimes act as a man-in-the-middle for TLS clients. In these scenarios, the clients add a new trust anchor whose private key is kept on the SSL proxy; the proxy intercepts TLS requests, creates a new TLS session with the intended host, and sets up a TLS session with the client using a certificate that chains to the trust anchor installed in the client by the proxy. In such environments, using TLSA records will prevent the SSL proxy from functioning as expected because the TLS client will get a certificate association from the DNS that will not match the certificate that the SSL proxy uses with the client. The client, seeing the proxy's new certificate for the supposed destination, will not set up a TLS session.

Client treatment of any information included in the trust anchor is a matter of local policy. This specification does not mandate that such information be inspected or validated by the server's domain name administrator.

If a server's certificate is revoked, or if an intermediate CA in a chain between the server and a trust anchor has its certificate revoked, a TLSA record with a certificate usage of 2 that matches the revoked certificate would in essence override the revocation because the client would treat that revoked certificate as a trust anchor and thus not check its revocation status. Because of this, domain administrators need to be responsible for being sure that the keys or certificates used in TLSA records with a certificate usage of 2 are in fact able to be used as reliable trust anchors.

Certificates that are delivered in TLSA with certificate usage 2 fundamentally change the way the TLS server's end entity certificate is evaluated. For example, the server's certificate might chain to an existing CA through an intermediate CA that has certain policy restrictions, and the certificate would not pass those restrictions and thus normally be rejected. That intermediate CA could issue itself a new certificate without the policy restrictions and tell its customers to use that certificate with certificate usage 2. This in essence allows an intermediate CA to become a trust anchor for certificates that the end user might have expected to chain to an existing trust anchor.

If an administrator wishes to stop using a TLSA record, the administrator can simply remove it from the DNS. Normal clients will stop using the TLSA record after the TTL has expired. Replay attacks against the TLSA record are not possible after the expiration date on the RRsig of the TLSA record that was removed.

Generators of TLSA records should be aware that the client's full trust of a certificate association retrieved from a TLSA record may be a matter of local policy. While such trust is limited to the specific domain name, protocol, and port for which the TLSA query was made, local policy may decline to accept the certificate (for reasons such as weak cryptography), as is also the case with PKIX trust anchors.

8.1. Comparing DANE to Public CAs

As stated above, the security of the DNS RRtype described in this document relies on the security of DNSSEC to verify that the TLSA record has not been altered. This section describes where the security of public CAs and the security of TLSA are similar and different. This section applies equally to other security-related DNS RRtypes such as keys for IPsec and SSH.

DNSSEC forms certificates (the binding of an identity to a key) by combining a DNSKEY, DS, or DLV resource record with an associated RRSIG record. These records then form a signing chain extending from the client's trust anchors to the RR of interest.

Although the DNSSEC protocol does not enforce it, DNSKEYs are often marked with a SEP flag indicating whether the key is a Zone Signing Key (ZSK) or a Key Signing Key (KSK). ZSKs protect records in the zone (including DS and DLV records), and KSKs protect ZSK DNSKEY records. This allows KSKs to be stored offline.

The TLSA RRtype allows keys from the DNSSEC PKI hierarchy to authenticate keys wrapped in PKIX certificates for a particular host name, protocol, and port.

With the exception of the DLV RRtype, all of these certificates constrain the keys they identify to names that are within the zone signing the certificate. In order for a domain's DLV resource records to be honored, the domain must be configured as a DLV domain, and the domain's DNSKEYs must be configured as trust anchors or be authentic [RFC5074].

8.1.1. Risk of Key Compromise

The risk that a given certificate that has a valid signing chain is fake is related to the number of keys that can contribute to the validation of the certificate, the quality of protection each private key receives, the value of each key to an attacker, and the value of falsifying the certificate.

DNSSEC allows any set of domains to be configured as trust anchors and/or DLVs, but most clients are likely to use the root zone as their only trust anchor. Also, because a given DNSKEY can only sign resource records for that zone, the number of private keys capable of compromising a given TLSA resource record is limited to the number of zones between the TLSA resource record and the nearest trust anchor, plus any configured DLV domains. Typically, this will be six keys, half of which will be KSKs.

PKIX only describes how to validate a certificate based on a client-chosen set of trust anchors, but says nothing about how many trust anchors to use or how they should be constrained. As currently deployed, most PKIX clients use a large number of trust anchors provided with the client or operating system software. These trust anchors are selected carefully, but with a desire for broad interoperability. The trust anchors and CA certificates for public CAs rarely have name constraints applied.

A combination of technical protections, process controls, and personnel experience contribute to the quality of security that keys receive.

• The security surrounding DNSSEC DNSKEYs varies significantly. The KSK/ZSK split allows the KSK to be stored offline and protected more carefully than the ZSK, but not all domains do so. The security applied to a zone's DNSKEYs should be proportional to the value of the domain, but that is difficult to estimate. For example, the root DNSKEY has protections and controls comparable to or exceeding those of public CAs. On the other end of the spectrum, small domains might provide no more protection to their keys than they do to their other data.

• The security surrounding public CAs also varies. However, due to financial incentives and standards imposed by clients for acceptance into their trust anchor stores, CAs generally employ security experts and protect their keys carefully, though highly public compromises have occurred.

8.1.2. Impact of Key Compromise

The impact of a key compromise differs significantly between the two models.

• DNSKEYs are inherently limited in what they can sign, so a compromise of the DNSKEY for "example.com" provides no avenue of attack against "example.org". Even the impact of a compromise of .com's DNSKEY, while considerable, would be limited to .com domains. Only the compromise of the root DNSKEY would have the equivalent impact of an unconstrained public CA.

• Public CAs are not typically constrained in what names they can sign, and therefore a compromise of even one CA allows the attacker to generate a certificate for any name in the DNS. A domain holder can get a certificate from any willing CA, or even multiple CAs simultaneously, making it impossible for a client to determine whether the certificate it is validating is legitimate or fraudulent.

Because a TLSA certificate association is constrained to its associated name, protocol, and port, the PKIX certificate is similarly constrained, even if its public CAs signing the certificate (if any) are not.

8.1.3. Detection of Key Compromise

If a key is compromised, rapid and reliable detection is important in order to limit the impact of the compromise. In this regard, neither model prevents an attacker from near-invisibly attacking their victim, provided that the necessary keys are compromised.

If a public CA is compromised, only the victim will see the fraudulent certificate, as there is typically no publicly accessible directory of all the certificates issued by a CA that can be inspected. DNS resource records are typically published publicly. However, the attacker could also allow the uncompromised records to be published to the Internet as usual but provide a compromised DNS view to the victim to achieve the same effect.

8.1.4. Spoofing Hostnames

Some CAs implement technical controls to ensure that certificates are not issued to domains with names similar to domains that are popular and prone to attack. Of course, an attacker can attempt to circumvent this restriction by finding a CA willing to issue the certificate anyway. However, by using DNSSEC and TLSA, the attacker can circumvent this check completely.

8.2. DNS Caching

Implementations of this protocol rely heavily on the DNS, and are thus prone to security attacks based on the deliberate mis-association of TLSA records and DNS names. Implementations need to be cautious in assuming the continuing validity of an association between a TLSA record and a DNS name.

In particular, implementations SHOULD rely on their DNS resolver for confirmation of an association between a TLSA record and a DNS name, rather than caching the result of previous domain name lookups. Many platforms already can cache domain name lookups locally when appropriate, and they SHOULD be configured to do so. It is proper for these lookups to be cached, however, only when the TTL (Time To Live) information reported by the DNS makes it likely that the cached information will remain useful.

If implementations cache the results of domain name lookups in order to achieve a performance improvement, they MUST observe the TTL information reported by DNS. Implementations that fail to follow this rule could be spoofed or have access denied when a previously accessed server's TLSA record changes, such as during a certificate rollover.

8.3. External DNSSEC Validators

Due to a lack of DNSSEC support in the most commonly deployed stub resolvers today, some ISPs have begun checking DNSSEC in the recursive resolvers they provide to their customers, setting the Authentic Data (AD) flag as appropriate. DNSSEC-aware clients could use that data, ignoring the fact that the DNSSEC data has been validated externally. Because there is typically no authentication of the recursive resolver or integrity protection of the data and AD flag between the client and the recursive resolver, this can be trivially spoofed by an attacker.

However, even with secure communications between a host and the external validating resolver, there is a risk that the external validator could become compromised. Nothing prevents a compromised external DNSSEC validator from claiming that all the records it provides are secure, even if the data is falsified, unless the client checks the DNSSEC data itself (rendering the external validator unnecessary).

For this reason, DNSSEC validation is best performed on-host, even when a secure path to an external validator is available.