DNS-based Authentication of Named Entities

"DANE" redirects here. For the Colombian department of statistics, see National Administrative Department of Statistics.

DNS-based Authentication of Named Entities (DANE) is a protocol to allow X.509 certificates, commonly used for Transport Layer Security (TLS), to be bound to DNS names using Domain Name System Security Extensions (DNSSEC).^[1]

It is proposed in RFC 6698 as a way to authenticate TLS client and server entities without a certificate authority (CA). It is updated with operational and deployment guidance in RFC 7671. Application specific usage of DANE is defined in RFC 7672 for SMTP and RFC 7673 for using DANE with Service (SRV) records.

Rationale

TLS/SSL encryption is currently based on certificates issued by certificate authorities (CAs). Within the last few years, a number of CA providers suffered serious security breaches, allowing the issuance of certificates for well-known domains to those who don't own those domains. Trusting a large number of CAs might be a problem because any breached CA could issue a certificate for any domain name. DANE enables the administrator of a domain name to certify the keys used in that domain's TLS clients or servers by storing them in the Domain Name System (DNS). DANE needs the DNS records to be signed with DNSSEC for its security model to work.

Additionally DANE allows a domain owner to specify which CA is allowed to issue certificates for a particular resource, which solves the problem of any CA being able to issue certificates for any domain.

Email encryption

Until recently, there has been no widely implemented standard for encrypted email transfer.^[2] Sending an email is security agnostic; there is no URI scheme to designate secure SMTP.^[3] As a result, most email that is delivered over TLS uses only opportunistic encryption.^[4] Since DNSSEC provides authenticated denial of existence, DANE enables an incremental transition to verified, encrypted SMTP without any other external mechanisms, as described by RFC 7672. A DANE record indicates that the sender must use TLS.^[3]

Additional drafts exist for S/MIME^[5] and Pretty Good Privacy (PGP).^[6]

Support

Applications

Google Chrome does not support DANE, as Google Chrome wishes to eliminate the use of 1024-bit RSA within the browser (DNSSEC uses a 1024-bit RSA signed root, and many zones are signed with 1024-bit RSA). According to Adam Langley, the code was written,^[7] but it is not in Chrome today.^[8] However it is available using an add-on.^[9]^[10]
Mozilla Firefox has support via an add-on^[11]
Irssi^[12]
GNU Privacy Guard Allows fetching keys via OpenPGP DANE (--auto-key-locate). New option --print-dane-records. (version 2.1.9)^[13]

Servers

Postfix^[14]
Halon^[15]^[16]

Services

Posteo^[17]
mailbox.org^[18]
Dotplex^[19]
mail.de^[20]
Tutanota.de^[21]

Libraries

OpenSSL^[22]
GnuTLS^[23]
Net::DNS^[24]
Net_DNS2^[25]
libsmaug^[26]

Standards

RFC 6394 Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)
RFC 6698 The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
RFC 7218 Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)
RFC 7671 The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance
RFC 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)
RFC 7673 Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records