The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance
updates
- rfc-6698 — The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
Extracted elements (30)
DANE-EE(3) SPKI(1) SHA2-256(1) is recommended as the preferred TLSA record type because SPKI(1) is compatible with raw public keys, the record survives certificate renewals with the same key, SHA2-256 is universally required, and it simplifies virtual hosting with a single certificate for all domains.
PKIX-TA(0) and PKIX-EE(1) SHOULD NOT be used in opportunistic security contexts because they require agreement on a mutually trusted CA, which is fragile and creates connection failures when valid peers don't share a common CA, undermining the non-intrusive nature of opportunistic security.
Supporting all four TLSA certificate usages simultaneously is not recommended because an attacker who can compromise DNSSEC needs only to replace PKIX-type records with DANE-type records, meaning PKIX-TA(0) and PKIX-EE(1) provide only illusory incremental security when DANE-TA(2) and DANE-EE(3) are also supported.
The digest algorithm agility protocol (Section 9) was defined because RFC 6698 specifies multiple digest algorithms but provides no protocol for clients and TLSA publishers to negotiate the strongest shared algorithm, leaving clients exposed to deprecated weak algorithms published for backward compatibility.
Only certificate usages DANE-EE(3) and DANE-TA(2) work well with TLSA CNAMEs across organizational boundaries. With PKIX-TA(0) or PKIX-EE(1), the Service Provider would need to obtain certificates in the name of the Customer Domain or the customer would need to provision private keys at the provider.
When a DANE-TA(2) TLSA record is a digest (not Full(0)), the TA certificate must be present in the TLS certificate chain because clients may ignore locally configured TAs and rely exclusively on certificates in the server's chain; without the TA certificate, authentication fails.
When a server is authenticated via DANE-EE(3), CT checks SHOULD NOT be performed, as the domain owner has directly specified the certificate association without reference to any public CA. With DANE-TA(2) for non-public TAs, CT also SHOULD NOT be applied.
Clients SHOULD use digest algorithm agility when processing DANE TLSA records: after discarding unusable/malformed records, for each usage and selector process only Full(0) records plus records whose digest algorithm is considered strongest among usable records with that usage and selector.
DANE clients MUST send the SNI extension with a HostName value of the base domain of the TLSA RRset. Except for DANE-EE(3), DANE clients MUST verify the server name is listed in the server certificate's SAN or CN.
DANE TLS clients connecting to a server whose domain name is a CNAME alias SHOULD follow the CNAME hop-by-hop to its ultimate target. If DNSSEC validation is secure at each step, the final target name SHOULD be the preferred base domain for TLSA lookups.
Designs in which clients support just the DANE-TA(2) and DANE-EE(3) certificate usages are RECOMMENDED, as they don't require maintaining a large list of X.509 trust anchors.
It is RECOMMENDED that TLSA records published for DANE servers be 'DANE-EE(3) SPKI(1) SHA2-256(1)' records, as SPKI(1) is compatible with raw public keys and the record need not change across certificate renewals with the same key.
Servers employing '2 1 0' (DANE-TA(2) SPKI(1) Full(0)) TLSA records MUST include the corresponding TA certificate in their certificate chain, because without the full certificate a client cannot verify the chain from only a public key.
Servers publishing TLSA records MUST be configured to allow correctly configured clients to successfully authenticate their TLS certificate chains. When all TLSA records are unusable and authenticated TLS is mandatory, the client MUST NOT connect to the server.
Servers publishing TLSA records with DANE-TA(2) usage MUST include the TA certificate in their TLS server certificate message, unless all such TLSA records are '2 0 0' records that publish the server certificate in full.
Simultaneous support for all four TLSA certificate usages (PKIX-TA(0), PKIX-EE(1), DANE-TA(2), DANE-EE(3)) is NOT RECOMMENDED, as an attacker who can compromise DNSSEC integrity can replace PKIX records with DANE records, making PKIX usages offer only illusory security.
The TLSA Publisher MUST ensure that each combination of certificate usage, selector, and matching type in the server's TLSA RRset includes at least one record that matches the server's current certificate chain at all times.
TLS clients that support DANE/TLSA MUST support at least TLS 1.0 and SHOULD support TLS 1.2 or later.
TLS clients using DANE MUST support the SNI extension of TLS (RFC 6698). Servers MAY support SNI but are not required to; when a server supports SNI but lacks an exact certificate match, it SHOULD respond with another certificate chain.
TLSA Publishers employing DANE-TA(2) SHOULD publish records with a selector of Cert(0), as such records encode the whole TA certificate and allow clients to apply path length and name constraints from the TA certificate.
When matching a usage PKIX-TA(0) TLSA record, a client MUST continue extending the chain even after finding a locally trusted certificate, and if that certificate is not self-issued, MUST attempt to build a longer chain in case a certificate closer to the root matches the TLSA record.
When the TLSA base domain is the result of 'secure' CNAME expansion, the resulting domain name MUST be used as the HostName in the client's SNI extension and MUST be the primary reference identifier for peer certificate matching (except DANE-EE(3)).
With DANE-EE(3), the server MUST be considered authenticated even if none of the names in the certificate match the client's reference identity. Additionally, the expiration date of the server certificate MUST be ignored; validity is determined solely by the TLSA record's DNSSEC signatures.
The TLSA base domain is either the fully CNAME-expanded TLS server name (when each expansion step is DNSSEC-secure and TLSA records are published there) or otherwise the initial fully qualified TLS server name, combined with port and protocol prefix.
TLSA records consist of four fields: Certificate Usage (PKIX-TA(0), PKIX-EE(1), DANE-TA(2), DANE-EE(3)), Selector (Cert(0), SPKI(1)), Matching Type (Full(0), SHA2-256(1), SHA2-512(2)), and Certificate Association Data.
DNS TTLs for TLSA records must be chosen carefully: TTLs that are too long limit the ability to respond to compromised or lost keys by forcing clients to cache stale TLSA records, potentially causing authentication failures after an emergency key rotation.
DNSSEC-signed RRsets cannot be securely revoked before they expire, so operators must use short DNSSEC signature lifetimes (a few days for high-value keys, a few weeks for less critical data) and re-sign zones frequently. Short signature lifetimes require tight synchronization of primary and secondary nameservers.
When TLSA records are used with opportunistic protocols where PKIX-TA(0) and PKIX-EE(1) don't apply, servers SHOULD NOT publish such TLSA records. Clients that receive only PKIX-type TLSA records in this context treat them as unusable and fall back to unauthenticated TLS, which is still stronger than cleartext.
Server operators SHOULD NOT publish TLSA records using both selector Cert(0) and matching type Full(0), as a single full certificate is generally too large to deliver reliably via DNS over UDP; two full certificates during rollover exacerbate this.
TLSA records using a matching type of Full(0) are NOT RECOMMENDED because even a single certificate is generally too large for reliable DNS UDP delivery; digest-based matching types such as SHA2-256(1) SHOULD be used instead.