DNS-based authentication of named entities

from Wikipedia, the free encyclopedia

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):

  1. CPS ( English certificate usage )
  2. Selector ( English selector )
  3. Allocation type ( English matching type )
  4. 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:

Norms and standards

Web links

Individual evidence

  1. ↑ a b RFC 6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
  2. ↑ RFC 7671 - The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance
  3. ↑ [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. @1@ 2Template: Webachiv / IABot / svn.irssi.org
  4. ↑ Posteo supports DANE / TLSA. posteo.de, accessed on May 15, 2014 .
  5. ↑ 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. @1@ 2Template: Webachiv / IABot / mailbox.org
  6. ↑ Secure hosting with DANE / TLSA. dotplex.de, accessed on June 21, 2014 .
  7. ↑ mail.de supports DANE / TLSA - No membership in the "E-Mail made in Germany" network. mail.de, accessed on June 22, 2014 .
  8. ↑ DANE Everywhere ?! Let's Make the Internet a Private Place Again. tutanota.com, accessed February 18, 2016 .
  9. ↑ Encryption for All Emails: Tutanota Uses DANE on Top of SSL and PFS for Maximum Security. Retrieved March 4, 2019 .
  10. ↑ DANE TLS authentication. , Postfix Documentation
  11. ↑ github.com , since version 4.85 EXPERIMENTAL_DANE
  12. ↑ Verifying a certificate using DANE (DNSSEC). Gnu.org, accessed May 15, 2014 .
  13. ↑ Bug # 77327 for Net-DNS: DANE TLSA support. rt.cpan.org, accessed May 15, 2014 .