Internet security
protocols
Key management
Application layer
Domain Name System
Internet Layer

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain 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.

DANE solves similar problems as:

Certificate Transparency
Ensuring that rogue CAs cannot issue certificates without the permission of the domain holder without being detected
DNS Certification Authority Authorization
Limiting which CAs can issue certificates for a given domain

However, unlike DANE, those technologies have wide support from browsers.

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] Consequently, most email that is delivered over TLS uses only opportunistic encryption.[4] Since DNSSEC provides authenticated denial of existence (allows a resolver to validate that a certain domain name does not exist), 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]

Additionally, RFC 8162 exists for applying DANE to S/MIME,[5] and RFC 7929 standardises bindings for OpenPGP.[6]

Support

Applications

Servers

Services

Libraries

TLSA RR

The TLSA RR (Resource Record) for a service is located at a DNS name that specifies certificate constraints should be applied for the services at a certain TCP or UDP port. At least one of the TLSA RRs must provide a validation (path) for the certificate offered by the service at the specified address.

Not all protocols handle Common Name matching the same way. HTTP requires that the Common Name in the X.509 certificate provided by the service matches regardless of the TLSA asserting its validity. SMTP does not require the Common Name matches, if the certificate usage value is 3 (DANE-EE), but otherwise does require a Common Name match. It is important to verify if there are specific instructions for the protocol being used.

RR data fields

The RR itself has 4 fields of data, describing which level of validation the domain owner provides.

E.g. _25._tcp.somehost.example.com. TLSA 3 1 1 0123456789ABCDEF

Certificate usage

Certificate usage value
PKIX path
validation 		Target of RR
Trust anchor End entity
Required 0 1
Not required 2 3

The first field after the TLSA text in the DNS RR, specifies how to verify the certificate.

Selector

When connecting to the service and a certificate is received, the selector field specifies which parts of it should be checked.

Matching type

Certificate association data

The actual data to be matched given the settings of the other fields. This is a long "text string" of hexadecimal data.

Examples

The TLSA record for www.ietf.org specifies to check the SHA-256 hash of the public key of the certificate provided, ignoring any CA. 

_443._tcp.www.ietf.org. TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6

Their mail service has the same exact certificate and TLSA. 

ietf.org. MX 0 mail.ietf.org.
_25._tcp.mail.ietf.org. TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6

Finally, the following example, does the same as the others, but does the hash calculation over the entire certificate. 

_25._tcp.mail.alice.example. TLSA 3 0 1 AB9BEB9919729F3239AF08214C1EF6CCA52D2DBAE788BB5BE834C13911292ED9

Standards

See also

Notes

  1. ^ An uncommon example where this could be useful would be if you don't trust the root-CA completely, but many applications do still use it, and you do trust a specific of the intermediate CAs, so you list the intermediate and still get full trust path verification.

References

  1. ^ Samad, Muhammad Alif Adha Bin (October 6, 2011). "DANE: Taking TLS Authentication to the Next Level Using DNSSEC". IETF Journal. Retrieved August 5, 2018.
  2. ^ "Postfix TLS Support - Secure server certificate verification". Postfix.org. Retrieved 2015-12-30.
  3. ^ a b Dukhovni; Hardaker (2013-07-28). DANE for SMTP (PDF). IETF 87 Proceedings. IETF.
  4. ^ Filippo Valsorda (2015-03-31). "The sad state of SMTP encryption". Retrieved 2015-12-30.
  5. ^ Hoffman, P. (May 2017). Using Secure DNS to Associate Certificates with Domain Names For S/MIME. IETF. doi:10.17487/RFC8162. RFC 8162. Retrieved 2022-03-30.
  6. ^ Wouters, P. (August 2016). DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP. IETF. doi:10.17487/RFC7929. RFC 7929. Retrieved 2016-09-14.
  7. ^ Langley, Adam (2015-01-17). "ImperialViolet - Why not DANE in browsers". www.imperialviolet.org. Retrieved 2017-03-24.[self-published source]
  8. ^ Duane Wessels, Verisign (2016-05-16). "Increasing the Strength Zone Signing Key for the Root Zone". Verisign.com. Retrieved 2016-12-29.
  9. ^ "Bind9 DNSSEC Guide". bind9.readthedocs.io. Retrieved 2021-08-22.
  10. ^ Adam Langley (2012-10-20). "DANE stapled certificates". ImperialViolet. Retrieved 2014-04-16.[self-published source]
  11. ^ Adam Langley (2011-06-16). "DNSSEC authenticated HTTPS in Chrome". ImperialViolet. Retrieved 2014-04-16.[self-published source]
  12. ^ How To Add DNSSEC Support To Google Chrome
  13. ^ https://bugzilla.mozilla.org/show_bug.cgi?id=672600
  14. ^ https://bugzilla.mozilla.org/show_bug.cgi?id=1479423
  15. ^ https://addons.mozilla.org/en-US/firefox/addon/dnssec-dane-validator/
  16. ^ "GnuPG - Release Notes". gnupg.org. 12 June 2021. Retrieved 2021-08-27.[self-published source]
  17. ^ "cheogram-android 2.13.0-1". Retrieved 2021-02-11.
  18. ^ "Postfix TLS Support - DANE". Postfix.org. Retrieved 2014-04-16.
  19. ^ "PowerMTA 5.0 Release". SparkPost.com. Retrieved 2020-04-26.
  20. ^ "Exim 4.91 spec: Encrypted SMTP connections using TLS/SSL / 15. DANE". exim.org. Retrieved 2018-07-05.
  21. ^ "mod_s2s_auth_dane_in". prosody.im. Retrieved 2024-02-11.
  22. ^ Scaturro, Michael (2014-08-24). "Protect your email the German way". The Guardian. Retrieved 2018-04-29. ... Last May, [Posteo] became the world's first email provider to adopt DNS-based Authentication of Named Entities (Dane) on its servers. ...
  23. ^ DANE Everywhere?! Let's Make the Internet a Private Place Again, tutanota.de, retrieved 2015-12-17[self-published source]
  24. ^ Richard Levitte (2016-01-07). "DANE CHANGES". GitHub. Retrieved 2016-01-13.[self-published source]
  25. ^ "Verifying a certificate using DANE (DNSSEC)". Gnu.org.[self-published source]
  26. ^ Osterweil, Eric; Wiley, Glen; Okubo, Tomofumi; Lavu, Ramana; Mohaisen, Aziz (6 July 2015). "Opportunistic Encryption with DANE Semantics and IPsec: IPSECA". Internet Engineering Task Force.

External links

TLS and SSL
Categories