RFC 7671

The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance

📅 published October 2015, from ietf

RFC 7671: The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance 🎀

Okay bestie, this one is RFC 7671 💖, and it's all about DANE. It was written by V. Dukhovni (Two Sigma) and W. Hardaker (Parsons) 👑 and published in October 2015 🦋. It's a Standards Track document (ISSN 2070-1721), and it updates RFC 6698. The header doesn't list anything it obsoletes, so it's only updating 6698, not replacing it ✨.

Abstract 🌸

Okay so this doc clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA spec (RFC 6698) 🔥, based on what people learned from actually implementing it. It also has guidance for implementers, operators, and protocol developers who want to use DANE records 💅.

Status of This Memo 🎀

This is an Internet Standards Track document 🌈.

This document is a product of the Internet Engineering Task Force (IETF) 🫶. It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) ✨. If you want more on Internet Standards, check out Section 2 of RFC 5741 💜.

For info on the current status of this doc, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7671 🦋.

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved 🌸.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication 📜. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🍓.

Table of Contents 🧚

   1. Introduction ....................................................3
      1.1. Terminology ................................................4
   2. DANE TLSA Record Overview .......................................5
      2.1. Example TLSA Record ........................................6
   3. DANE TLS Requirements ...........................................6
   4. DANE Certificate Usage Selection Guidelines .....................7
      4.1. Opportunistic Security and PKIX Usages .....................7
      4.2. Interaction with Certificate Transparency ..................8
      4.3. Switching from/to PKIX-TA/EE to/from DANE-TA/EE ............9
   5. Certificate-Usage-Specific DANE Updates and Guidelines ..........9
      5.1. Certificate Usage DANE-EE(3) ...............................9
      5.2. Certificate Usage DANE-TA(2) ..............................11
      5.3. Certificate Usage PKIX-EE(1) ..............................15
      5.4. Certificate Usage PKIX-TA(0) ..............................15
   6. Service Provider and TLSA Publisher Synchronization ............16
   7. TLSA Base Domain and CNAMEs ....................................18
   8. TLSA Publisher Requirements ....................................19
      8.1. Key Rollover with Fixed TLSA Parameters ...................20
      8.2. Switching to DANE-TA(2) from DANE-EE(3) ...................21
      8.3. Switching to New TLSA Parameters ..........................22
      8.4. TLSA Publisher Requirements: Summary ......................23
   9. Digest Algorithm Agility .......................................23
   10. General DANE Guidelines .......................................25
      10.1. DANE DNS Record Size Guidelines ..........................25
      10.2. Certificate Name Check Conventions .......................26
      10.3. Design Considerations for Protocols Using DANE ...........27
   11. Note on DNSSEC Security .......................................28
   12. Summary of Updates to RFC 6698 ................................29
   13. Operational Considerations ....................................29
   14. Security Considerations .......................................30
   15. References ....................................................30
      15.1. Normative References .....................................30
      15.2. Informative References ...................................32
   Acknowledgements ..................................................33
   Authors' Addresses ................................................33

1. Introduction ✨

Okay so the DANE spec [RFC6698] introduces the DNS "TLSA" resource record (RR) type. ("TLSA" is not an acronym, bestie 🙈.) TLSA records tie a certificate, or a public key, of an end-entity or a trusted issuing authority to the matching Transport Layer Security (TLS) [RFC5246] or Datagram Transport Layer Security (DTLS) [RFC6347] transport endpoint 🦋. DANE leans on the DNS Security Extensions (DNSSEC) [RFC4033]. TLSA records that DNSSEC validates can be used to augment or replace trusting the public Certification Authorities (CAs) 💜.

TLS and DTLS give you secured TCP and UDP communication over IP, respectively 🌸. For this doc, channel security is assumed to come from TLS or DTLS. By convention we just say "TLS", but unless something says otherwise, the text works the same for DTLS over UDP 🫶. Without authentication, TLS only protects you from eavesdropping, thanks to its encryption 👀. With authentication, TLS also protects the transport against man-in-the-middle (MITM) attacks 🔥.

[RFC6698] defines three TLSA record fields: the first has four possible values, the second has two, and the third has three 🧮. Those give you 24 distinct combinations of TLSA record types 🌈. This document recommends a smaller set of best-practice combinations of these fields, to keep protocol design, implementation, and deployment simple 💅.

This doc also explains and recommends DANE-specific strategies to make "virtual hosting" easier, which is when a single Service Provider transport endpoint supports multiple hosted Customer Domains at once 👑.

Other related docs that build on [RFC6698] are [RFC7673] and [RFC7672] 🎀.

Section 12 summarizes the normative updates this document makes to [RFC6698] 📜.

1.1. Terminology 🫶

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 [RFC2119] ⭐.

These terms get used all through this document 💜:

  • Web PKI: The Public Key Infrastructure (PKI) model browsers use to authenticate web servers 🌐. It relies on a set of trusted public CAs to vouch for the authenticity of public keys tied to a particular party (the subject).
  • Service Provider: A company or organization that offers to host a service on behalf of the owner of a Customer Domain 🏠. The original domain name for the service often stays under the customer's control. Connecting applications may be sent to the Service Provider through a redirection RR. Example redirection records include MX, SRV, and CNAME 🦋. A Service Provider often serves lots of customers, so it needs to make sure the TLS credentials it presents to connecting applications authenticate it as a valid server for the requested domain 🔥.
  • Customer Domain: As described above, a TLS client might be talking to a service hosted by a third party 💅. This document calls the domain name used to find the service (before any redirection) the "Customer Domain" 🎀.
  • TLSA Publisher: The entity responsible for publishing a TLSA record within a DNS zone 📮. This zone is assumed to be DNSSEC-signed and validatable to a trust anchor (TA), unless otherwise specified 🔐. If the Customer Domain isn't outsourcing its DNS service, the TLSA Publisher is the customer itself 🙋. Otherwise, the TLSA Publisher may be the operator of the outsourced DNS service 🧚.
  • Public key: "Public key" is shorthand for the subjectPublicKeyInfo component of a PKIX [RFC5280] certificate 🔑.
  • SNI: The Server Name Indication (SNI) TLS protocol extension lets a TLS client ask for a connection to a particular service name on a TLS server ([RFC6066], Section 3) 🌸. Without this extension, a TLS server has no choice but to offer a certificate with a default list of server names. That makes it hard to host multiple Customer Domains at the same IP-address-based TLS service endpoint (i.e., provide "secure virtual hosting") 😭.
  • TLSA parameters: In [RFC6698], the TLSA record is defined to have four fields 🧩. The first three are numeric parameters that specify what the data in the fourth and final field means. This document calls those first three fields "TLSA parameters", or sometimes just "parameters" when the context makes it obvious ✨.
  • TLSA base domain: Per Section 3 of [RFC6698], TLSA records are stored at a DNS domain name made from a port and protocol prefix plus a "base domain" 🗺️. In [RFC6698], the "base domain" is the fully qualified domain name of the TLS server. This document changes the TLSA record lookup strategy to prefer the fully CNAME-expanded name of the TLS server, as long as the expansion is "secure" (DNSSEC validated) at each stage and TLSA records are published for that fully expanded name 🦋. So the "TLSA base domain" is either the fully CNAME-expanded TLS server name, or otherwise the initial fully qualified TLS server name. Whichever one you pair with a port and protocol prefix to get the TLSA RRset is the one that counts 💖.

2. DANE TLSA Record Overview 🎀

okay so DANE TLSA [RFC6698] is the protocol for publishing TLS server certificate associations through DNSSEC [RFC4033] [RFC4034] [RFC4035] 🔐✨ A TLSA record has four fields. The first three together decide what kind of record it is, and this doc calls them the "TLSA parameters" so they're easy to tell apart from the fourth one. Their numbers got symbolic names in [RFC7218], so you'll see names like PKIX-TA instead of just 0 💅

  • The Certificate Usage field: Section 2.1.1 of [RFC6698] lists four values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-EE(3). There's also a private-use value, PrivCert(255). Since it's private, it shall not be considered further in this document 🙈 Every other value is reserved for future specs.
  • The Selector field: Section 2.1.2 of [RFC6698] lists two values: Cert(0) and SPKI(1). There's a private-use value, PrivSel(255), and all other values are reserved for future specs 🦋
  • The Matching Type field: Section 2.1.3 of [RFC6698] lists three values: Full(0), SHA2-256(1), and SHA2-512(2). There's a private-use value, PrivMatch(255), and all other values are reserved for future specs 🌸
  • The Certificate Association Data field: See Section 2.1.4 of [RFC6698]. This field holds either the full value or the digest of the certificate or subject public key, depending on the matching type and selector 🍓

Now the digest situation, which is kind of a big deal 👑 Of the two digest algorithms, SHA2-256(1) and SHA2-512(2), only SHA2-256(1) is mandatory to implement as of this writing. Clients SHOULD implement SHA2-512(2), but servers SHOULD NOT publish only SHA2-512(2) digests. The digest algorithm agility protocol in Section 9 SHOULD be used by clients to decide how to handle TLSA RRsets that use multiple digest algorithms. And server operators MUST publish TLSA RRsets that are compatible with digest algorithm agility (see Section 8 and Section 9) 🫶

2.1. Example TLSA Record

In this example, the TLSA certificate usage is DANE-TA(2), the selector is Cert(0), and the matching type is SHA2-256(1). The last field is the Certificate Association Data field, which here holds the SHA2-256 digest of the server certificate 💜

   _25._tcp.mail.example.com. IN TLSA 2 0 1 (
                              E8B54E0B4BAA815B06D3462D65FBC7C0
                              CF556ECCF9F5303EBFBB77D022F834C0 )

3. DANE TLS Requirements 🧚

[RFC6698] doesn't say which TLS versions you need when you're using DANE records, so this doc fills that gap ✨ TLS clients that support DANE/TLSA MUST support at least TLS 1.0 and SHOULD support TLS 1.2 or later. Lowkey important! 💖

TLS clients using DANE MUST support the SNI extension of TLS [RFC6066]. Servers MAY support SNI and respond with a matching certificate chain, but they MAY also ignore SNI and respond with a default certificate chain. Now, if a server supports SNI but doesn't have a certificate chain that exactly matches the client's SNI extension, the server SHOULD respond with another certificate chain (a default or closest match). Why? Clients might support more than one server name, but they can only put a single name in the SNI extension 🥹

4. DANE Certificate Usage Selection Guidelines 💅

As mentioned in Section 2, the TLSA Certificate Usage field takes one of four possible values. With PKIX-TA(0) and PKIX-EE(1), validating peer certificate chains needs extra preconfigured CA TAs that both the TLS server operators and the client operators mutually trust. With DANE-TA(2) and DANE-EE(3), no preconfigured CA TAs are needed, and the published DANE TLSA records are enough to verify the peer's certificate chain 🔥

Application protocols that use DANE TLSA can give more specific guidance than [RFC6698] or this document, and those app-specific standards need to think carefully about which set of DANE certificate usages to support. Simultaneous support for all four usages is NOT RECOMMENDED for DANE clients 🙅‍♀️ Here's the tea: when all four are supported, an attacker who can compromise the integrity of DNSSEC only needs to swap the server's TLSA RRset for one listing a suitable DANE-EE(3) or DANE-TA(2) record. That bypasses any extra verification from public CAs, so PKIX-TA(0) and PKIX-EE(1) offer only illusory incremental security over DANE-TA(2) and DANE-EE(3) 💀

Designs where clients support just DANE-TA(2) and DANE-EE(3) are RECOMMENDED 👑 With those two, clients don't have to track a big, constantly changing list of X.509 TAs just to authenticate servers whose certificates come from a brand new or not-widely-trusted CA 🌈

The DNSSEC TLSA records for servers MAY include both sets of usages if the server needs to support a mix of clients, where some support one pair and some support the other 🦋

4.1. Opportunistic Security and PKIX Usages

When a client's protocol design is based on "Opportunistic Security" (OS) [RFC7435] and authentication depends on whether server TLSA records are present, it's especially important to avoid the PKIX-EE(1) and PKIX-TA(0) certificate usages 🙈

When authenticated TLS is used opportunistically based on whether DANE TLSA records exist, and no secure TLSA records are present, unauthenticated TLS is used if possible. If TLS isn't possible, it might even fall back to cleartext 😭 But if usable secure TLSA records are published, then authentication MUST succeed. Also, outside the browser space there's no preordained canon of trusted CAs, and there's no security advantage to using PKIX-TA(0) or PKIX-EE(1) when DANE-TA(2) and DANE-EE(3) are also supported. An attacker who can compromise DNS can just replace the former with the latter 🫠

Authentication via PKIX-TA(0) and PKIX-EE(1) is way more brittle. The client and server need to happen to agree on a mutually trusted CA, and with OS the client is only trying to protect the channel because the server asked, and would otherwise be happy with cleartext or unauthenticated TLS 🌸 Fragile mechanisms, like public CA authentication for some unspecified set of trusted CAs, aren't reliable enough for an OS client to honor the server's request for authentication. OS needs to be non-intrusive and needs few, if any, workarounds for valid but mismatched peers ✨

So PKIX-TA(0) and PKIX-EE(1) offer no extra security and fail more often, which makes them a poor fit for OS, and they SHOULD NOT be used in that context 🚫

4.2. Interaction with Certificate Transparency

Certificate Transparency (CT) [RFC6962] is an experimental approach that could help reduce the risk of rogue or compromised public CAs issuing unauthorized certificates. This section explains how the experimental CT and DANE interact. It may need to be revised in light of any future Standards Track version of CT 🧐

When a server is authenticated via a DANE TLSA RR with TLSA certificate usage DANE-EE(3), the domain owner has directly specified the certificate for that service without involving any public CA. So when a TLS client authenticates the TLS server via a TLSA record with usage DANE-EE(3), CT checks SHOULD NOT be performed 🙌 Publishing the server certificate or public key digest in a TLSA record inside a DNSSEC-signed zone is how the domain owner assures the TLS client that the certificate isn't an unauthorized one issued by a rogue CA without the domain owner's consent 🔐

When a server is authenticated via a DANE TLSA record with TLSA usage DANE-TA(2) and the server certificate doesn't chain to a known public root CA, CT can't apply, because CT logs only accept chains that start with a known public root 🤷‍♀️ Since TLSA certificate usage DANE-TA(2) is generally meant to support non-public TAs, TLS clients SHOULD NOT perform CT checks with usage DANE-TA(2) 💖

With certificate usages PKIX-TA(0) and PKIX-EE(1), CT applies just like it would without DANE. TLSA records of this type only constrain which CAs are acceptable in PKIX validation. All the checks that apply in the absence of DANE still apply when validating certificate chains with DANE PKIX-TA(0) and PKIX-EE(1) constraints 🎀

4.3. Switching from/to PKIX-TA/EE to/from DANE-TA/EE

Preferred certificate usages may need to change as an application protocol evolves 🦋 When transitioning between PKIX-TA/PKIX-EE and DANE-TA/DANE-EE, clients start enabling support for the new certificate usage values. If the new preferred usages are PKIX-TA/EE, that means installing and managing the right set of CA TAs 🌈 During this time, servers will publish both types of TLSA records. Later on, once the vast majority of servers have published the new preferred TLSA records, clients can stop supporting the legacy usages. Likewise, servers can stop publishing legacy TLSA records once the vast majority of clients support the new certificate usages 🍓

5. Certificate-Usage-Specific DANE Updates and Guidelines 🧚‍♀️

The four certificate usage values from the TLSA record, namely DANE-EE(3), DANE-TA(2), PKIX-EE(1), and PKIX-TA(0), are discussed below 💅✨

5.1. Certificate Usage DANE-EE(3) 💖

okay bestie, so the meaning of DANE-EE(3) gets a glow-up from [RFC6698] 🦋 Now peer identity matching and validity period enforcement are based solely on the TLSA RRset properties ✨ This doc also extends [RFC6698] to cover DANE authentication of raw public keys [RFC7250] using TLSA records with certificate usage DANE-EE(3) and selector SPKI(1) 🔑

Authentication via DANE-EE(3) TLSA records is literally just checking that the server's leaf certificate matches the TLSA record 💅 The binding of the server public key to its name comes entirely from the TLSA record association. The server MUST be considered authenticated even if none of the names in the certificate match the client's reference identity for the server 🙈 This makes life way easier for servers hosting multiple Customer Domains, because one certificate can be linked to several domains without having to match every single reference identifier 🌸

; Multiple Customer Domains hosted by an example.net
; Service Provider:
;
www.example.com.              IN CNAME ex-com.example.net.
www.example.org.              IN CNAME ex-org.example.net.
;
; In the provider's DNS zone, a single certificate and TLSA
; record support multiple Customer Domains, greatly simplifying
; "virtual hosting".
;
ex-com.example.net.           IN A 192.0.2.1
ex-org.example.net.           IN A 192.0.2.1
_443._tcp.ex-com.example.net. IN CNAME tlsa._dane.example.net.
_443._tcp.ex-org.example.net. IN CNAME tlsa._dane.example.net.
tlsa._dane.example.net.       IN TLSA 3 1 1 e3b0c44298fc1c14...

Also, with DANE-EE(3), the expiration date of the server certificate MUST be ignored 🥹 The validity period of the TLSA record key binding is set by the validity period of the TLSA record DNSSEC signatures. So validity gets reaffirmed on an ongoing basis by continuing to publish the TLSA record and signing the zone it lives in, instead of relying on dates "set in stone" in the certificate ⏳ The expiration date just becomes a reminder for the admin that it's probably time to rotate the key, and missing it no longer causes an outage 😭 When keys get rotated (for whatever reason), it's important to follow the procedures in Section 8 📋

If a server uses just DANE-EE(3) TLSA records and all its clients are DANE clients, the server doesn't need SNI. It can ignore the client's SNI message, even when it's known by multiple domain names that would otherwise need separate certificates ✨ It's enough for the TLSA RRsets for all those domain names to match the server's default certificate. For application protocols where the server name is found indirectly through SRV records, MX records, or similar records, the simplest move is to publish a single hostname as the target server name for all the hosted domains 🧚

In organizations where it's practical to make coordinated changes to DNS TLSA records before a server key rotation, it's generally best to publish end-entity DANE-EE(3) certificate associations over the other certificate usage options 👑 DANE-EE(3) TLSA records support multiple server names without SNI, they don't suddenly stop working when a leaf or intermediate certificate expires, and they don't fall apart when a server operator forgets to include all the required issuer certificates in the server certificate chain 💀

Here's the more specific bit: it is RECOMMENDED that at most sites, TLSA records published for DANE servers be "DANE-EE(3) SPKI(1) SHA2-256(1)" records 🍓 SPKI(1) is picked because it's compatible with raw public keys [RFC7250], and the resulting TLSA record doesn't need to change across certificate renewals with the same key 🔁 SHA2-256(1) is picked because all DANE implementations are required to support SHA2-256 ✅ This TLSA record type easily supports hosting setups with a single certificate matching all hosted domains, and it's also the easiest one to implement correctly on the client side 💜

Clients that support raw public keys can use DANE TLSA records with certificate usage DANE-EE(3) and selector SPKI(1) to authenticate servers that negotiate the use of raw public keys 🦋 As long as the server follows the requirements in Section 8, the fact that raw public keys aren't compatible with any other TLSA record types won't get in the way of successful authentication 🫶 Clients that use DANE to authenticate the peer server SHOULD NOT negotiate the use of raw public keys unless the server's TLSA RRset includes "DANE-EE(3) SPKI(1)" TLSA records 🙅

It's technically possible to authenticate raw public keys via "DANE-EE(3) Cert(0) Full(0)" records too, by pulling the public key out of the certificate in DNS 🤓 But extracting just the public key from a "3 0 0" TLSA record needs extra logic on clients, and not every implementation is expected to provide that. So servers that want to support [RFC7250] raw public keys need to publish TLSA records with a certificate usage of DANE-EE(3) and a selector of SPKI(1) 🌈

DANE-EE(3) TLSA records are expected to be by far the most common, as explained in Section 5.2 📈 DANE-TA(2) records are still a valid alternative for sites with lots of DANE services. Just note that virtual hosting is more complex with DANE-TA(2) 😬 Also, with DANE-TA(2), server operators MUST ensure that the server is configured with a sufficiently complete certificate chain, and they need to remember to replace certificates before their expiration dates 📅

5.2. Certificate Usage DANE-TA(2) 🌟

This section updates [RFC6698] by adding a new operational requirement for servers publishing TLSA records with a usage of DANE-TA(2): such servers 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 📜

Some domains would rather skip the hassle of publishing unique TLSA RRs for each TLS service 🥱 If the domain uses a common issuing CA for certificates across multiple TLS services, it can be simpler to publish the issuing authority as a TA for the certificate chains of all the relevant services. The TLSA query domain (the TLSA base domain with port and protocol prefix labels) for each service issued by the same TA can then be set to a CNAME alias pointing at a common TLSA RRset that matches the TA 🔗 For example:

; Two servers, each with its own certificate, that share
; a common issuer (TA).
;
www1.example.com.            IN A 192.0.2.1
www2.example.com.            IN A 192.0.2.2
_443._tcp.www1.example.com.  IN CNAME tlsa._dane.example.com.
_443._tcp.www2.example.com.  IN CNAME tlsa._dane.example.com.
tlsa._dane.example.com.      IN TLSA 2 0 1 e3b0c44298fc1c14...

This setup makes server key rotation way simpler 🔄 The servers keep getting new certificates from a CA matched by the shared TLSA record (the target of the CNAMEs), so server certificates can be updated without making any DNS changes. As the list of active issuing CAs changes, the shared TLSA record gets updated, but much less often, by the admins who manage the CAs. Those admins still need to make TLSA record updates with care, as described in Section 8 ⚠️

With usage DANE-TA(2), the server certificates will need names that match one of the client's reference identifiers (see [RFC6125]) 🎯 When hosting multiple unrelated Customer Domains that can't all fit in a single certificate, such a server SHOULD employ SNI to select the right certificate to present to the client 🫧

TLSA records with a matching type of Full(0) are NOT RECOMMENDED 🙅‍♀️ Sure, these could potentially make it unnecessary to send the TA certificate in the TLS server certificate message, but client implementations may not be able to augment the server certificate chain with data obtained from DNS, especially when the TLSA record supplies a bare key (selector SPKI(1)). Since the server has to send the TA certificate in any case, server operators SHOULD publish TLSA records with a matching type other than Full(0), and avoid potential DNS interoperability issues with large TLSA records containing full certificates or keys (see Section 10.1.1) 🧩

TLSA Publishers employing DANE-TA(2) records SHOULD publish records with a selector of Cert(0) ✨ These TLSA records are tied to the whole TA certificate, not just the TA public key. So when authenticating the peer certificate chain via such a TLSA record, the client SHOULD apply any relevant constraints from the TA certificate, such as path length constraints 💅

A selector of SPKI(1) can also be used, but the resulting TLSA record won't specify the full TA certificate content, and elements of the TA certificate other than the public key become mutable 😳 That could, for example, let a subsidiary CA issue a chain that violates the TA's path length or name constraints 🚨

5.2.2. Trust Anchor Digests and Server Certificate Chain 🔍

With DANE-TA(2), things get complicated when the TA certificate is left out of the server's certificate chain, maybe based on Section 7.4.2 of [RFC5246]:

   The sender's certificate MUST come first in the list.  Each
   following certificate MUST directly certify the one preceding it.
   Because certificate validation requires that root keys be
   distributed independently, the self-signed certificate that
   specifies the root certificate authority MAY be omitted from the
   chain, under the assumption that the remote end must already
   possess it in order to validate it in any case.

With TLSA certificate usage DANE-TA(2), there's no expectation that the client is preconfigured with the TA certificate 🤷‍♀️ In fact, client implementations are free to ignore all locally configured TAs when processing usage DANE-TA(2) TLSA records, and they may rely exclusively on the certificates provided in the server's certificate chain. But with a digest in the TLSA record, the TLSA record contains neither the full TA certificate nor the full public key. So if the TLS server's certificate chain doesn't contain the TA certificate, DANE clients won't be able to authenticate the server 💔

TLSA Publishers that publish TLSA certificate usage DANE-TA(2) associations with a selector of SPKI(1), or with a digest-based matching type (not Full(0)), MUST ensure that the corresponding server is configured to also include the TA certificate in its TLS handshake certificate chain 📦 That's true even if the certificate is a self-signed root CA that would have been optional in the context of the existing public CA PKI 🙃

The TA certificate is only optional in the server's TLS certificate message when the server TLSA record includes a "DANE-TA(2) Cert(0) Full(0)" TLSA record containing a full TA certificate 🎀 This is also the only type of DANE-TA(2) record for which the client MUST be able to verify the server's certificate chain even if the TA certificate appears only in DNS and is absent from the TLS handshake server certificate message 🥰

5.2.3. Trust Anchor Public Keys ✨

okay so TLSA records with usage DANE-TA(2), selector SPKI(1), and matching type Full(0) publish the whole public key of a TA right through DNS 🔑. Over in Section 6.1.1 of [RFC5280], a TA is defined as four parts:

  1. the trusted issuer name,
  2. the trusted public key algorithm,
  3. the trusted public key, and
  4. optionally, the trusted public key parameters associated with the public key.

Items 2-4 are exactly what's in the subjectPublicKeyInfo published in the TLSA record. The issuer name is not in the subjectPublicKeyInfo tho 🙈.

With DANE-TA(2), the client might not have the TA certificate, so it generally can't tell whether a particular cert chain is "issued by" the TA in the TLSA record. It's giving mystery 🌫️.

When the server's chain includes a CA cert whose public key matches the TLSA record, the client can match that CA as the intended issuer. Otherwise, the client can only check that the topmost cert in the server's chain is "signed by" the TA's public key from the TLSA record. That check can be annoying to implement, and you can't expect every client to support it 💀.

So servers can't count on a "DANE-TA(2) SPKI(1) Full(0)" record being enough to authenticate chains issued by that key if the TLS certificate message doesn't include a matching cert. Servers using "2 1 0" TLSA records MUST include the corresponding TA certificate in their certificate chain. No skipping this one, bestie 🫶.

If none of the server's chain elements match a public key in a TLSA record, and at least one "DANE-TA(2) SPKI(1) Full(0)" TLSA record is available, it is RECOMMENDED that clients check whether the topmost certificate in the chain is signed by the provided public key and hasn't expired. If that passes, and the rest of the chain validates (including leaf certificate name checks), the client can consider the server authenticated 🎀.

5.3. Certificate Usage PKIX-EE(1) 🌸

This usage is pretty similar to DANE-EE(3), but PKIX verification is required on top of it. So name checks, certificate expiration, CT, and so on all apply just like they would without DANE 💅.

5.4. Certificate Usage PKIX-TA(0) 👑

This section updates [RFC6698] by specifying new client implementation requirements. Clients that trust intermediate certificates MUST be prepared to construct longer PKIX chains than would be required for PKIX alone. Main character chain-building energy 🧚.

PKIX-TA(0) lets a domain publish constraints on which PKIX CAs are trusted to issue certs for its TLS servers. A PKIX-TA(0) TLSA record matches PKIX-verified trust chains that contain an issuer certificate (root or intermediate) matching its Certificate Association Data field (typically a certificate or digest) 📜.

PKIX-TA(0) needs more complicated coordination (than DANE-TA(2) or DANE-EE(3) does) between the Customer Domain and the Service Provider in hosting setups. So this usage is NOT RECOMMENDED when the Service Provider isn't also the TLSA Publisher (at the TLSA base domain reached via CNAMEs, SRV records, or MX records) 🙃.

TLSA Publishers who publish TLSA records for a particular public root CA will expect clients to only accept chains anchored at that root. It's possible, though, that the client's trusted certificate store includes some intermediate CAs, either with or without the matching root CA. When a client builds a trust chain from a trusted intermediate CA to the server leaf certificate, that "truncated" chain might not contain the trusted root published in the server's TLSA record 🧩.

If the omitted root is also trusted, the client may wrongly reject the server chain if it fails to figure out that the shorter chain it built extends to a longer trusted chain that matches the TLSA record. So when matching a PKIX-TA(0) TLSA record, as long as no matching certificate has been found yet, a client MUST continue extending the chain even after finding a locally trusted certificate. If no TLSA records have matched any element of the chain, and the trusted certificate found is not self-issued, the client MUST attempt to build a longer chain in case a certificate closer to the root matches the server's TLSA record. Don't stop early, babe 🔥.

6. Service Provider and TLSA Publisher Synchronization 🔄

Whenever possible, the TLSA Publisher and the Service Provider should be the same entity. Otherwise, they need to coordinate changes so the TLSA records published by the TLSA Publisher don't fall out of sync with the server certificate used by the Service Provider. That coordination is hard, and service outages happen when it fails 😭.

Publishing the TLSA record in the Service Provider's zone skips the mess of bilateral coordination over server certificate configuration and TLSA record management ✨. Even when the TLSA RRset has to live in the Customer Domain's DNS zone (maybe the client app doesn't "chase" CNAMEs to the TLSA base domain), you can still use CNAME records to delegate the contents of the TLSA RRset to a domain run by the Service Provider 🦋.

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 have to get certificates in the name of the Customer Domain from a suitable public CA (basically securely impersonating the customer), or the customer would have to provision the relevant private keys and certificates on the Service Provider's systems 🫠.

Certificate Usage DANE-EE(3): In this case, the Service Provider can publish a single TLSA RRset that matches the server certificate or public key digest. The same RRset works for all Customer Domains, because name checks don't apply to DANE-EE(3) TLSA records (see Section 5.1). A Customer Domain can create a CNAME record pointing to the TLSA RRset published by the Service Provider 💖.

Certificate Usage DANE-TA(2): When the Service Provider operates a private CA, the Service Provider is free to issue a certificate bearing any customer's domain name. Without DANE, a certificate like that wouldn't pass trust verification, but with DANE, the customer's TLSA RRset (aliased to the provider's TLSA RRset) can delegate authority to the provider's CA for the corresponding service. The Service Provider can generate appropriate certificates for each customer and use the SNI information provided by clients to pick the right certificate chain to present to each one 🌈.

Below are example DNS records (assumed "secure" and shown without the associated DNSSEC information, such as record signatures) that illustrate both of the above models for an HTTPS service whose clients all support DANE TLS. These examples work even with clients that don't "chase" CNAMEs when constructing the TLSA base domain (see Section 7 below) 🍓.

   ; The hosted web service is redirected via a CNAME alias.
   ; The associated TLSA RRset is also redirected via a CNAME alias.
   ;
   ; Certificate usage DANE-EE(3) makes it possible to deploy
   ; a single provider certificate for all Customer Domains.
   ;
   www1.example.com.            IN CNAME w1.example.net.
   _443._tcp.www1.example.com.  IN CNAME _443._tcp.w1.example.net.
   _443._tcp.w1.example.net.    IN TLSA 3 1 1 (
                                   8A9A70596E869BED72C69D97A8895DFA
                                   D86F300A343FECEFF19E89C27C896BC9 )

   ;
   ; A CA at the provider can also issue certificates for each Customer
   ; Domain and employ the DANE-TA(2) certificate usage to
   ; designate the provider's CA as a TA.
   ;
   www2.example.com.            IN CNAME w2.example.net.
   _443._tcp.www2.example.com.  IN CNAME _443._tcp.w2.example.net.
   _443._tcp.w2.example.net.    IN TLSA 2 0 1 (
                                   C164B2C3F36D068D42A6138E446152F5
                                   68615F28C69BD96A73E354CAC88ED00C )

With protocols that support explicit transport redirection via DNS MX records, SRV records, or other similar records, the TLSA base domain is based on the redirected transport endpoint rather than the origin domain. With SMTP, for example, when an email service is hosted by a Service Provider, the Customer Domain's MX hostnames will point at the Service Provider's SMTP hosts. When the Customer Domain's DNS zone is signed, the MX hostnames can be securely used as the base domains for TLSA records that are published and managed by the Service Provider. For example (without the required DNSSEC information, such as record signatures) 📬:

   ; Hosted SMTP service.
   ;
   example.com.               IN MX 0 mx1.example.net.
   example.com.               IN MX 0 mx2.example.net.
   _25._tcp.mx1.example.net.  IN TLSA 3 1 1 (
                                 8A9A70596E869BED72C69D97A8895DFA
                                 D86F300A343FECEFF19E89C27C896BC9 )
   _25._tcp.mx2.example.net.  IN TLSA 3 1 1 (
                                 C164B2C3F36D068D42A6138E446152F5
                                 68615F28C69BD96A73E354CAC88ED00C )

If redirecting to the Service Provider's domain (via MX records, SRV records, or any similar mechanism) isn't possible, and aliasing the TLSA record isn't an option, then the Customer Domain and Service Provider need more complex coordination. Either the Customer Domain periodically gives the provider private keys and a matching certificate chain (after making the right changes in its TLSA records), or the Service Provider periodically generates the keys and certificates and has to wait for matching TLSA records to be published by its Customer Domains before deploying the new keys and certificate chains 😩. Section 7 below describes an approach that uses CNAME "chasing" to dodge the headaches of coordinating key management across organizational boundaries 🧠.

For more on combining DANE and SRV, check out [RFC7673] 🦋.

7. TLSA Base Domain and CNAMEs ✨

okay so when the application protocol doesn't support service location indirection via MX, SRV, or similar DNS records, the service can be redirected with a CNAME 💅. honestly, a CNAME is kinda the blunt instrument of the bunch, because unlike an MX or SRV record it remaps the entire origin domain to the target domain for all protocols 🙈

the key management drama gets way simpler when the DANE TLSA records live in the Service Provider's domain, which is what we covered in Section 6 🫶. so 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 host (noting at each step whether or not the CNAME is DNSSEC validated) 🔥. if every stage of the CNAME expansion has DNSSEC validation status "secure", then the final target name SHOULD be the preferred base domain for TLSA lookups 👑.

if an implementation can't find a TLSA record using the final target of a CNAME expansion as the base name, it SHOULD issue a TLSA query using the original destination name 🧚. so the preferred TLSA base domain SHOULD be derived from the fully expanded name and, if that fails, SHOULD be the initial domain name 💜.

when the TLSA base domain comes from "secure" CNAME expansion, the resulting domain name MUST be used as the HostName in the client's SNI extension, and it MUST be the primary reference identifier for peer certificate matching with certificate usages other than DANE-EE(3) 🎀. main character energy for that domain name, no cap ✨.

protocol-specific TLSA specifications may add extra guidance or restrictions when following CNAME expansions 🌈.

okay, plot twist 😭. CNAMEs are illegal on the right-hand side of most indirection records, like MX and SRV records, but some implementations support them anyway. for example, if the MX or SRV host is a CNAME alias, some implementations may "chase" the CNAME. if they do, they SHOULD use the target hostname as the preferred TLSA base domain as described above (and, if the TLSA records are found there, also use the CNAME-expanded domain in SNI and certificate name checks) 🦋.

8. TLSA Publisher Requirements 💅

this section updates [RFC6698] by saying that 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 🔐. TLSA records for recently retired or not-yet-deployed certificate chains will show up during key rollover, and those past or future records MUST NOT at any time be the only records published for any given combination of usage, selector, and matching type 😭. the TLSA record update process below makes sure this requirement is met ✨.

a server counts as authenticated when any of the published TLSA records matches its certificate chain 🫶. the catch is that not all clients support every combination of TLSA record parameters 🙈. some clients may not support certain digest algorithms, and others may not support the PKIX certificate usages, or may only support them 💀. some clients may prefer to negotiate [RFC7250] raw public keys, which only work with TLSA records whose certificate usage is DANE-EE(3) and selector is SPKI(1) 🧊. the only other TLSA record type that could work with raw public keys is "DANE-EE(3) Cert(0) Full(0)", but raw public key support for that record type isn't expected to be widely implemented 🥀.

because we can't know which TLSA parameters a given client supports, servers need to make sure that every single parameter combination in the TLSA RRset is, on its own, enough to match the server's current certificate chain 💖. this is especially important when deploying new keys or new parameter combinations: you don't want to create combinations that only match past or future certificate chains (or raw public keys) 😬. the rest of this section explains how to update the TLSA RRset so this requirement stays satisfied 🌸.

8.1. Key Rollover with Fixed TLSA Parameters

the simplest case is key rollover while keeping the same set of published parameter combinations 🍓. first, TLSA records matching the existing server certificate chain (or raw public keys) get augmented with matching records for the future keys, at least two Times to Live (TTLs) or longer before the new chain is deployed 🕰️. this lets the obsolete RRset age out of client caches before the new chain shows up in TLS handshakes 🧹. once enough time has passed and all clients doing DNS lookups are retrieving the updated TLSA records, the server administrator can deploy the new certificate chain, verify that it works, and then remove any obsolete records matching the chain that's no longer active ✅:

; Initial TLSA RRset.
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...

; Transitional TLSA RRset published at least two TTLs before
; the actual key change.
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...

; Final TLSA RRset after the key change.
;
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...

the next case is adding or switching to a new combination of TLSA parameters 🦋. here, you publish the new parameter combinations for the server's existing certificate chain first, and only then deploy new keys if you want to:

; Initial TLSA RRset.
;
_443._tcp.www.example.org. IN TLSA 1 1 1 01d09d19c2139a46...

; New TLSA RRset, same key re-published as DANE-EE(3).
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...

8.2. Switching to DANE-TA(2) from DANE-EE(3)

this section explains how to migrate to a new certificate chain and TLSA record with usage DANE-TA(2), starting from a self-signed server certificate and a "DANE-EE(3) SPKI(1) SHA2-256(1)" TLSA record 🧁. this example assumes a new private key gets generated as part of switching to a new certificate issued by the desired TA 🔑.

the original "3 1 1" TLSA record supports [RFC7250] raw public keys, and clients may choose to negotiate their use 🫧. using raw public keys rules out certificate chain verification 🙅‍♀️. so the transitional TLSA record for the planned DANE-TA(2) certificate chain is a "3 1 1" record that still works when raw public keys are used 💅. the TLSA RRset only gets updated to use DANE-TA(2) after the new chain is deployed and the "3 1 1" record matching the original key has been dropped 🗑️.

this process follows the requirement that each combination of parameters in the RRset is always enough to validate the server 🫶. it avoids publishing a transitional TLSA RRset where "3 1 1" matches only the current key and "2 0 1" matches only the future certificate chain, because those might not work reliably during the initial deployment of the new keys 😵‍💫.

; Initial TLSA RRset.
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...

; Transitional TLSA RRset, published at least two TTLs before the
; actual key change.  The new keys are issued by a DANE-TA(2) CA
; but are initially specified via a DANE-EE(3) association.
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...

; The final TLSA RRset after the key change.  Now that the old
; self-signed EE key is out of the picture, publish the issuing
; TA of the new chain.
;
_443._tcp.www.example.org. IN TLSA 2 0 1 c57bce38455d9e3d...

8.3. Switching to New TLSA Parameters

when you add a new digest algorithm to the TLSA RRset, administrators SHOULD publish it with each combination of certificate usage and selector for each associated key or chain that's used with any other digest algorithm 🧩. this is what keeps things compatible with the digest algorithm agility described in Section 9 below 🌷. when removing an algorithm, remove it entirely 🧹. each digest algorithm in use SHOULD match the same set of chains (or raw public keys) ✨.

; Initial TLSA RRset with "DANE-EE(3) SHA2-256(1)" associations
; for two keys.
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...

; New TLSA RRset, also with SHA2-512(2) associations
; for each key.
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 2 d9947c35089310bc...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
_443._tcp.www.example.org. IN TLSA 3 1 2 89a7486a4b6ae714...

8.4. TLSA Publisher Requirements: Summary

tl;dr server operators updating TLSA records should make one change at a time 🌈. the individual safe changes go like this:

  • Pre-publish new certificate associations that use the same TLSA parameters (usage, selector, and matching type) as existing TLSA records, but match certificate chains that'll be deployed in the near future 🍼.
  • Wait for stale TLSA RRsets to expire from DNS caches before configuring servers to use the new certificate chain ⏳.
  • Remove TLSA records matching any certificate chains that are no longer deployed 🗑️.
  • Publish TLSA RRsets in which all parameter combinations (certificate usage, selector, and matching type) present in the RRset match the same set of current and planned certificate chains 💎.

these steps are meant to make sure that, at all times and for each combination of usage, selector, and matching type, at least one TLSA record corresponds to the server's current certificate chain 🛡️. each combination of certificate usage, selector, and matching type in a server's TLSA RRset SHOULD NOT at any time (including unexpired RRsets in client caches) match only some combination of future or past certificate chains 🙅‍♀️. so no matter which combinations of usage, selector, and matching type a given client supports, they'll be enough to authenticate the server 🎉💜

9. Digest Algorithm Agility ✨

okay so [RFC6698] lets you publish multiple digest algorithms, but it doesn't have a way for the client and the TLSA record publisher to agree on the strongest one they both support 🫶. that's the gap this section fills. the weaker algorithms are only there so older, less capable clients can still connect, and they really SHOULD be avoided when possible 💅

this section defines a protocol for skipping deprecated digest algorithms when they show up in a peer's TLSA RRset next to stronger ones 🦋 quick note: this protocol never skips RRs with a DANE matching type of Full(0), because those don't use a digest algorithm that cryptanalysis could someday weaken 🔐

Client implementations SHOULD implement a default order of digest algorithms by strength 📊 that order SHOULD be configurable by the administrator or user of the client software. if it's possible, there should also be a configurable mapping from numeric DANE TLSA matching types to the digest algorithms the cryptographic library provides 🧚 that way new matching types work with software that came out before they existed. and configurable ordering of digest algorithms SHOULD be extensible to any new digest algorithms 🌈

to make digest algorithm agility possible, all published DANE TLSA RRsets MUST conform to the requirements of Section 8. clients SHOULD use digest algorithm agility when processing the peer's DANE TLSA records 🎀 agility gets applied only after the unusable or malformed records are thrown out first (an unsupported digest algorithm, or an incorrect digest length). then, for each usage and selector, the client SHOULD process only the usable records with a matching type of Full(0), plus the usable records whose digest algorithm the client considers the strongest among usable records with that usage and selector 👑

Example: a client implements digest algorithm agility and prefers SHA2-512(2) over SHA2-256(1), while the server publishes an RRset that uses both digest algorithms as well as a Full(0) record 🍓

_25._tcp.mail.example.com. IN TLSA 3 1 1 (
                              3FE246A848798236DD2AB78D39F0651D
                              6B6E7CA8E2984012EB0A2E1AC8A87B72 )
_25._tcp.mail.example.com. IN TLSA 3 1 2 (
                              D4F5AF015B46C5057B841C7E7BAB759C
                              BF029526D29520C5BE6A32C67475439E
                              54AB3A945D80C743347C9BD4DADC9D8D
                              57FAB78EAA835362F3CA07CCC19A3214 )
_25._tcp.mail.example.com. IN TLSA 3 1 0 (
                              3059301306072A8648CE3D020106082A
                              8648CE3D0301070342000471CB1F504F
                              9E4B33971376C005445DACD33CD79A28
                              81C3DED1981F18E7AAA76609DD0E4EF2
                              8265C82703030AD60C5DBA6FB8A9397A
                              C0FCF06D424C885D484887 )

so in this case, the client SHOULD accept a server public key that matches either the 3 1 0 record or the 3 1 2 record 💖 but it SHOULD NOT accept keys that match only the weaker 3 1 1 record 🙈

10. General DANE Guidelines 🌸

these guidelines are here to help you use or design protocols for DANE 🧚

10.1. DANE DNS Record Size Guidelines

picking a combination of TLSA parameters takes real care 🧐 one big thing to think about is how large the TLSA record ends up being once you've picked your parameters.

10.1.1. UDP and TCP Considerations

deployments SHOULD avoid TLSA record sizes that cause UDP fragmentation 🚫

DNS over TCP would make it easier to move bigger records between clients and servers, but it isn't universally deployed, and some firewalls still block it 😭 clients that ask for records over UDP usually only switch to TCP after they get a truncated response in the DNS response sent over UDP. and just setting the Truncation (TC) bit (Section 4.1.1 of [RFC1035]) won't be enough if the response carrying the TC bit is itself fragmented 💀

10.1.2. Packet Size Considerations for TLSA Parameters

server operators SHOULD NOT publish TLSA records that use both a TLSA selector of Cert(0) and a TLSA matching type of Full(0) 🙅‍♀️ even a single certificate is usually too big to be reliably delivered over DNS over UDP. and two TLSA records containing full certificates have to be published at the same time during a certificate rollover, as covered in Section 8.1.

TLSA records with a TLSA selector of SPKI(1) and a TLSA matching type of Full(0) are way more compact 🦋 these publish the bare public keys, without the overhead of wrapping the keys in an X.509 certificate. still, they're best avoided when they're significantly larger than their digests. instead, servers SHOULD publish digest-based TLSA matching types in their TLSA records 🔥 in that case, the complete corresponding certificate MUST be sent to the client in-band during the TLS handshake. the certificate (or raw public key) is easy to verify using the digest value ✨

so the bottom line: using a TLSA matching type of Full(0) is NOT RECOMMENDED, and a digest-based matching type, such as SHA2-256(1), SHOULD be used instead 💜

10.2. Certificate Name Check Conventions

certificates a TLS server presents will usually have a subjectAltName (SAN) extension or a Common Name (CN) element in the subject Distinguished Name (DN) 🪪 the TLS server's DNS domain name normally goes in these elements, ideally in the SAN extension. (using the CN field for this is deprecated, fyi 🙈)

when a server hosts multiple domains at the same transport endpoint, its ability to respond with the right certificate chain depends on correct SNI information from the client 📡 DANE clients MUST send the SNI extension with a HostName value of the base domain of the TLSA RRset.

the one exception is TLSA certificate usage DANE-EE(3), where name checks don't apply (see Section 5.1). otherwise, DANE clients MUST verify that they reached the correct server by checking that the server name is listed in the server certificate's SAN or CN (when that's still supported) 🔍 the primary server name for this comparison MUST be the TLSA base domain. however, protocol-specific DANE standards can specify additional acceptable names. for example, with SMTP, both the destination domain name and the MX hostname are acceptable names to find in the server certificate (see [RFC7672]) 💌

it's the service operator's job, working together with the TLSA Publisher, to make sure at least one of the TLSA records published for the service matches the server's certificate chain (either the default chain or the certificate picked based on the SNI information the client sent) 🤝

here's an example with DNSSEC-validated DNS records 💻

example.com.               IN MX 0 mail.example.com.
mail.example.com.          IN A 192.0.2.1
_25._tcp.mail.example.com. IN TLSA 2 0 1 (
                              E8B54E0B4BAA815B06D3462D65FBC7C0
                              CF556ECCF9F5303EBFBB77D022F834C0 )

so the TLSA base domain is "mail.example.com" and it's required to be the HostName in the client's SNI extension 📛 the server certificate chain is required to be signed by a TA with the certificate SHA2-256 digest above. and finally, one of the DNS names in the server certificate has to be either "mail.example.com" or "example.com" (that extra name is a concession to compatibility with older practice; see [RFC7672] for the details) 🥹

[RFC6125] specifies how wildcards in server certificates work for various application protocols. DANE doesn't change how any given application treats wildcards 🌿

10.3. Design Considerations for Protocols Using DANE

when a TLS client goes to the trouble of authenticating a certificate chain from a TLS server, it usually won't keep using that server after an authentication failure, or else authentication was pointless 😤 some clients may sometimes run in an "audit" mode, where an authentication failure gets reported to the user or in logs as a potential problem, but the connection goes ahead anyway 👀 even so, servers publishing TLSA records MUST be configured to let correctly configured clients successfully authenticate their TLS certificate chains 🔐

a service with DNSSEC-validated TLSA records is basically promising TLS support 🫣 when all the TLSA records for a service are "unusable" (because of unsupported parameter combinations or malformed certificate association data), DANE clients can't authenticate the service certificate chain. when authenticated TLS is mandatory, the client MUST NOT connect to the associated server.

if instead TLS and DANE are "opportunistic" [RFC7435], then when all TLSA records are unusable, the client SHOULD connect to the server over an unauthenticated TLS connection. and if TLS encryption can't be established, the client MUST NOT connect to the server 🫶

other standards for opportunistic DANE TLS that are specific to a particular application protocol may modify the requirements above 🎀 the key question is whether mandating (unauthenticated) TLS even when TLSA records are unusable is asking for more security than anyone can realistically expect 🤔 if expecting TLS support when unusable TLSA records are published is realistic for the application in question, then the application MUST avoid cleartext. if it isn't realistic, then mandating TLS would make clients run into problems with various peers that don't interoperate "securely enough" (even with no active attacks at all) 😩 that would create strong incentives to just turn off Opportunistic Security and stick with cleartext 💔

11. Note on DNSSEC Security 🔐

okay so the whole DANE TLSA PKI is only as trustworthy as the DNSSEC infrastructure underneath it 💀 this doc isn't a full DNSSEC security guide, but there are a few comments that are super helpful for TLSA implementers 🫶

With the existing public CA Web PKI, name constraints are rarely used, and a public root CA can issue certificates for any domain it wants 😬 With DNSSEC, under the Registry/Registrar/Registrant model, it's a different story: only the registrar of record can update a domain's DS record [RFC4034] in the registry parent zone (in some cases, though, the registry is the sole registrar 🙃). With lots of gTLDs where multiple registrars compete to provide domains in a single registry, it's really important to make sure rogue registrars can't easily start an unauthorized domain transfer and take over DNSSEC for the domain 🚨 DNS operators are advised to set a registrar lock on their domains to help guard against this 🔒

When the registrar is also the DNS operator for the domain, you need to think about whether the registrar will allow an orderly migration of the domain to another registrar or DNS operator in a way that keeps DNSSEC integrity intact 🧐 TLSA Publishers are advised to look for a DNS hosting registrar that makes it possible to transfer domains to another hosting provider without disabling DNSSEC ✨

DNSSEC-signed RRsets cannot be securely revoked before they expire, so operators need to plan ahead and not generate signatures with excessively long durations ⏳ For domains publishing high-value keys, a signature lifetime (the length of the "signature validity period" described in Section 8.1 of [RFC4033]) of a few days is reasonable, and the zone can be re-signed daily. For domains with less critical data, a reasonable signature lifetime is a couple of weeks to a month, and the zone can be re-signed weekly 📅

Short signature lifetimes need tighter synchronization between primary and secondary nameservers, so secondary servers never serve records with expired signatures 😰 They also limit the maximum time a primary server that signs the zone can be down. So short signature lifetimes are more appropriate for sites with dedicated operations staff who can restore service quickly if something goes wrong 🦸

Monitoring is important 👀 If a DNS zone isn't re-signed in a timely manner, a major outage is likely, because the entire domain and all its sub-domains become "bogus" 💀

12. Summary of Updates to RFC 6698 📝

  • Section 3 updates [RFC6698] to specify a requirement for clients to support at least TLS 1.0 and to support SNI 💅
  • Section 4 explains that application support for all four certificate usages is NOT RECOMMENDED 🙅‍♀️ The recommended design is to support just DANE-EE(3) and DANE-TA(2) 👑
  • Section 5.1 updates [RFC6698] to specify that peer identity matching and validity period enforcement are based solely on the TLSA RRset properties. It also specifies DANE authentication of raw public keys [RFC7250] via TLSA records with certificate usage DANE-EE(3) and selector SPKI(1) 🔑
  • Section 5.2 updates [RFC6698] to require that servers publishing digest TLSA records with a usage of DANE-TA(2) MUST include the TA certificate in their TLS server certificate message. This extends to the case of "2 1 0" TLSA records that publish a full public key 📜
  • Section 5.4 observes that with usage PKIX-TA(0), clients may need to process extended trust chains beyond the first trusted issuer when that issuer is not self-signed 🔗
  • Section 7 recommends that DANE application protocols specify that, when possible, securely CNAME-expanded names be used to derive the TLSA base domain 🧭
  • Section 8 specifies a strategy for managing TLSA records that interoperates with DANE clients regardless of what subset of the possible TLSA record types (combinations of TLSA parameters) is supported by the client 🤝
  • Section 9 specifies a digest algorithm agility protocol 🔄
  • Section 10.1 recommends against the use of Full(0) TLSA records, as digest records are generally much more compact 📦

13. Operational Considerations ⚙️

The DNS TTL of TLSA records needs to be chosen with care ⏰ When an unplanned change in the server's certificate chain and TLSA RRset is required, such as when keys are compromised or lost, clients that cache stale TLSA records will fail to validate the certificate chain of the updated server 😱 So publish TLSA RRsets with TTLs that are short enough to limit unplanned service disruption to an acceptable duration.

The signature lifetime (length of the signature validity period) for TLSA records SHOULD NOT be too long 🙅 Signed DNSSEC records can be replayed by a MITM attacker, as long as the signatures haven't expired yet 👿 Shorter signature validity periods allow for faster invalidation of compromised keys ⚡ Zone refresh and expiration times for secondary nameservers often imply a lower bound on the signature validity period (Section 11). See Section 4.4.1 of [RFC6781].

14. Security Considerations 🚨

Application protocols that cannot use the existing public CA Web PKI may choose to not implement certain TLSA record types defined in [RFC6698]. If such records are published despite not being supported by the application protocol, they are treated as "unusable" 🫥 When TLS is opportunistic, the client MAY proceed to use the server with mandatory unauthenticated TLS. This is stronger than opportunistic TLS without DANE, since in that case the client may also proceed with a cleartext connection 🛡️

When TLS is not opportunistic, the client MUST NOT connect to the server. No exceptions, no "just this once" 🙅‍♀️

Thus, when TLSA records are used with opportunistic protocols where PKIX-TA(0) and PKIX-EE(1) do not apply, the recommended protocol design is for servers to not publish such TLSA records, and for opportunistic TLS clients to use them only to enforce the use of (albeit unauthenticated) TLS but otherwise treat them as unusable 🧠 Of course, when PKIX-TA(0) and PKIX-EE(1) are supported by the application protocol, clients MUST implement these certificate usages as described in [RFC6698] and this document 💖

15. References 📚

15.1. Normative References

15.2. Informative References

Acknowledgements 🫶

The authors would like to thank Phil Pennock for his comments and advice on this document 🙌

Acknowledgements from Viktor: Thanks to Tony Finch, who finally prodded me into participating in DANE working group discussions 😂 Thanks to Paul Hoffman, who motivated me to produce this document and provided feedback on early draft versions of it 💜 Thanks also to Samuel Dukhovni for editorial assistance 🌸

Authors' Addresses 🖊️

Viktor Dukhovni
Two Sigma

Email: ietf-dane@dukhovni.org


Wes Hardaker
Parsons
P.O. Box 382
Davis, CA  95617
United States

Email: ietf@hardakers.net
📦 where this page comes from