DNS-based authentication of named entities
DNS-based Authentication of Named Entities ( DANE ) is a network protocol that is used to secure data traffic. The protocol extends the widespread SSL / TLS transport route encryption in such a way that the certificates used cannot be changed unnoticed, and thus increases the security of the encrypted transport of e-mails and access to websites.
For this purpose, X.509 certificates are linked to DNS entries and secured using DNS Security Extensions ( DNSSEC ). DANE can also be used by domain owners to issue their own certificates without having to resort to an existing certificate authority ( CA ).
Problem
For example, if a user wants to set up a secure TLS connection to a website, e.g. https://www.example.com/ , using his browser as a client , he wants to ensure that the responding server is also authorized to deliver the desired website. To do this, the client first checks whether the named domain is entered in the certificate offered by the server.
You then have to ensure that the certificate has been issued and authenticated by a trustworthy certification authority (CA). In most cases, the user does not decide which CAs are classified as trustworthy. Rather, the browser automatically accesses a list of trustworthy CAs, which in turn serve as trust anchors (origin of trust) for the certificate hierarchy of the client certificate.
However, numerous serious incidents with CAs initially classified as trustworthy by browser manufacturers raised doubts about the security of this procedure. There are u. a. no restriction as to which CAs may authenticate certificates for certain domains.
This is where DANE comes in: Clients can use it to ask DNS servers which certificates they can classify as trustworthy. This allows the owner of a domain to limit the range of CAs.
TLSA Resource Record
DANE defines a new DNS resource record called "TLSA". This contains a certificate in PKIX format, its fingerprint or public key.
The following example shows the use of DANE for the mail transfer agents of an e-mail domain.
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 )
The port number and the transport protocol used are encoded in the domain name of the TLSA record . The example uses port 25 ( SMTP ) over TCP . There are four parameters in the RDATA field (to the right of the "TLSA" string):
- CPS ( English certificate usage )
- Selector ( English selector )
- Allocation type ( English matching type )
- Certificate data ( English certificate data association )
Certificate usage
The following values are possible for the certificate usage:
- 0: PKIX-TA ( English CA constraint ). The client is requested to use a defined trust anchor to validate the certificate, which must be a trustworthy PKIX certification authority. The server certificate must trace its chain of trust back to this "trust anchor" and pass the certificate check.
- 1: PKIX-EE ( English Service certificate constraint ). The client is requested to trust the server certificate referenced in the TLSA record, which must be issued by a trustworthy PKIX certification authority. The certificate and the entire chain of trust must pass the trustworthiness test.
- 2: DANE-TA ( English Trust anchor assertion ). The client is requested to use a defined trust anchor to validate the certificate. In contrast to PKIX-TA, this does not need to be a PKIX certification authority that is trustworthy for the client. The server certificate must trace its chain of trust back to this "trust anchor".
- 3: DANE-EE ( English Domain-Issued Certificate ). The client is requested to trust the certificate referenced in the TLSA record. A check of the trust hierarchy is not carried out.
In the case of PKIX values (0 and 1), the DANE test takes place in addition to the certificate test that is otherwise common with TLS ; the DANE exam is therefore used to confirm certificates issued by public certification authorities. With DANE values (2 and 3), the domain owner has the option of creating his own, also self-signed, certificates for his TLS-secured services without having to involve a certification authority known to the client. By choosing between “Trust Anchor” (TA) and “End Entity” (EE), the domain owner can decide for himself whether to anchor DANE security on a CA or server certificate.
Selector
The parameter selector takes the following values:
- 0: Full certificate . The TLSA entry refers to the full certificate.
- 1: SubjectPublicKeyInfo . The TLSA entry refers to the public key of a certificate. With this setting, an expiring certificate can be renewed without having to change the associated TLSA entry, provided that the previous key pair continues to be used.
Certificate assignment
The type of assignment parameter controls which type of certificate data is used in the following parameter.
- 0: Full . The client compares a full one-to-one copy of the certificate or public key. With this setting, the DNS response can become very long, so it will likely have to be fragmented.
- 1: SHA-256 . The client compares a SHA-256 hash value of the certificate or public key.
- 2: SHA-512 . The client compares a SHA-512 hash value of the certificate or public key.
The certificate data is entered and output in configuration files and DNS tools as a hexadecimal character string. For hash values (1 and 2), this is the usual representation. With a complete copy (0), this is a rather unusual representation when dealing with certificates.
Implementations
DANE supports the following applications and services, among others:
- Browser: Google Chrome (via add-on) and Mozilla Firefox (via add-on)
- IRC clients : Irssi
- Services: Posteo , mailbox.org , Dotplex, mail.de , Tutanota
- Server: Postfix , Exim ,
- Libraries: GnuTLS and Net :: DNS
Norms and standards
- RFC 6394 Concept, 2011.
- RFC 6698 Main Document, 2012.
- RFC 7218 amendment, 2014.
- RFC 7671 - version for TLS, 2015.
- RFC 7672 - version for SMTP, 2015.
- RFC 7673 - version for TLSA, 2015.
Web links
- Dan York: "The DANE Protocol - DNS-Based Authentication of Named Entities"
- List of websites with which you can test DANE
- "Encrypted mail transport: Posteo is the first provider to use DANE" , Heise News
- Online tool to check domains for DNSSEC and DANE support
- heise.de / ... - "Forced encryption for e-mail transport" (MTA-ST vs. DANE) from September 28, 2018 (accessed October 1, 2018).
Individual evidence
- ↑ a b RFC 6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
- ↑ RFC 7671 - The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance
- ↑ [irssi] Revision 5218. (No longer available online.) In: Svn.irssi.org. Archived from the original on April 16, 2014 ; Retrieved April 16, 2014 . Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.
- ↑ Posteo supports DANE / TLSA. posteo.de, accessed on May 15, 2014 .
- ↑ DANE and DNSsec for secure sending of e-mails at mailbox.org. (No longer available online.) Mailbox.org, archived from the original on August 21, 2014 ; Retrieved May 29, 2014 . Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.
- ↑ Secure hosting with DANE / TLSA. dotplex.de, accessed on June 21, 2014 .
- ↑ mail.de supports DANE / TLSA - No membership in the "E-Mail made in Germany" network. mail.de, accessed on June 22, 2014 .
- ↑ DANE Everywhere ?! Let's Make the Internet a Private Place Again. tutanota.com, accessed February 18, 2016 .
- ↑ Encryption for All Emails: Tutanota Uses DANE on Top of SSL and PFS for Maximum Security. Retrieved March 4, 2019 .
- ↑ DANE TLS authentication. , Postfix Documentation
- ↑ github.com , since version 4.85 EXPERIMENTAL_DANE
- ↑ Verifying a certificate using DANE (DNSSEC). Gnu.org, accessed May 15, 2014 .
- ↑ Bug # 77327 for Net-DNS: DANE TLSA support. rt.cpan.org, accessed May 15, 2014 .