The DANE Protocol – DNS-Based Authentication of Named Entities

If you connect to a website using a “secure” connection over TLS/SSL, how do you know you are using the correct TLS/SSL certificate?

You may see the “lock” icon in your web browser, but are you sure that you are connecting all the way to the website using the correct TLS certificate?  It is in fact quite possible – and quite common – for a firewall or other device in your network path to terminate your TLS connection with a website and then re-create a TLS connection from the device to your browser.  You think you have a secure, encrypted connection to your bank, for instance, but in fact your connection has been intercepted and the firewall or other device is able to see, and potentially record, all your interaction with the web site.

With DNSSEC now being deployed, a new protocol has emerged called “DANE” (“DNS-Based Authentication of Named Entities“) that allows you to securely specify exactly which TLS/SSL certificate an application or service should use to connect to your site.  If, for instance, a web browser supporting DANE detects that it is NOT using the specified certificate, it can warn you that your connection is insecure… even though you see a “lock” icon.  Beyond the web, DANE is being used with great success in securing communication over email and over instant messaging protocols such as XMPP (Jabber).  There is also interest in using DANE for SIP (voice-over-IP (VoIP)) and other communication methods.

DANE is defined in RFC 6698 and over time we will be adding more tutorials and document to this site to help you understand both how DANE helps make the Internet more secure and also how you can get started either publishing TLSA records for your domain – or using DANE within your application.

It is important to note that the DANE protocol can work perfectly fine with existing TLS certificates issued by Certificate Authorities (CAs). DANE defines four different modes of operation in the “certificate usage” field of a TLSA record:

  • 0 – CA specification – The TLSA record specifies the Certificate Authority (CA) who will provide TLS certificates for the domain. Essentially, you are able to say that your domain will ONLY use TLS certificates from a specific CA.  If the browser or other application using DANE validation sees a TLS cert from another CA the app should reject that TLS cert as bogus.
  • 1 – Specific TLS certificate – The TLSA record specifies the exact TLS certificate that should be used for the domain. Note that this TLS certificate must be one that is issued by a valid CA.
  • 2 – Trust anchor assertion – The TLSA record specifies the “trust anchor” to be used for validating the TLS certificates for the domain. For example, if a company operated its own CA that was not in the list of CAs typically installed in client applications this usage of DANE could supply the certificate (or fingerprint) for their CA.
  • 3 – Domain-issued certificate – The TLS record specifies the exact TLS certificate that should be used for the domain, BUT, in contrast to usage #1, the TLS certificate does not need to be signed by a valid CA.  This allows for the use of self-signed certificates.

The flexibility of the different usage modes of the DANE protocol means that it can be used to provide a DNSSEC-validated additional layer of trust for regular CA-signed TLS certificates – and it can also be used to add a DNSSEC-validated layer of trust to self-signed certificates.

A good introduction to DANE is an IETF Journal article published in October 2011 titled “DANE: Taking TLS Authentication to the Next Level Using DNSSEC“. In the article, Richard Barnes explains why DANE is needed, outlines how it works, digs into some of the challenges with DANE implementation and provides a good number of links for more information.

For another explanation of the DANE protocol, watch this interview with Warren Kumari, co-chair of the DANE Working Group within the IETF:

Content Providers

If you would like to create a TLSA record for your site, several tools are available to help:

Application Developers

The following libraries are in the process of adding support for the DANE protocol:

  • dnspython – the development version of dnspython found on Github has had support for TLSA records added to the code base. This is not yet available in a formal release.
  • ldns – an upcoming release of ldns will provide support for DANE (this page will be updated when the release occurs).

Other resources for developers:

  • DANE Test Sites – If you are adding DANE support to your application and wish to test out how well it works, the sites on this page are early supporters of the protocol and can be used in your testing.

Getting More Involved

If you would like to get more involved in the development of the DANE protocol and supporting documentation, you can:

October 4th, 2012 by | Posted in DANE, DNSSEC | Tags: | 16 Comments

16 Responses to The DANE Protocol – DNS-Based Authentication of Named Entities

  1. […] The DANE Protocol – DNS-Based Authentication of Named Entities […]

  2. […] Perhaps a new tool that will make it easier to use DNSSEC?  Or perhaps new software that supports the DANE protocol to increase the security of TLS/SSL? A browser plugin?  A program that makes it easier for […]

  3. […] you are looking to get started with the DANE protocol to provide higher security for SSL/TLS certificates, a basic question can be – how do you […]

  4. […] zit niet op haar handen. De IETF heeft recentelijk een nieuw protocol goedgekeurd, genaamd “DANE”. Dit protocol maakt het mogelijk om informatie over certificaten op te slaan in DNS. En aangezien […]

  5. […] is the DANE protocol all about? How does it protect Internet communication? How does it relate to SSL/TLS certificates? […]

  6. […] 89 next week in London is going to be an extremely busy week for those of us interested in DNSSEC, DANE  and DNS security in general. As I explained in a post today, “Rough Guide to IETF 89: […]

  7. […] are many useful resources on DANE that you can read to gain a deeper understanding.  The Internet Society (ISOC) has been advocating the use of DNSSEC and is also providing information on the use of […]

  8. […] on Tuesday afternoon, the working group looking after the DANE protocol will be actively discussing how various other protocols can use DANE / DNSSEC to provide a higher […]

  9. […] When cryptographic gaffes happen it’s very tempting to point to a new protocol like DNSSEC, and claim it does not have this problem. Indeed, I wrote about the new trust models presented by DNSSEC, DANE, and Certificate Transparency earlier this month. I argued that we need to move away from trusting centralized entities such as Certificate Authorities, and instead distribute our trust model using both Certificate Transparency(RFC 6962), and DNSSEC / DANE. […]

  10. […] are many useful resources on DANE that you can read to gain a deeper understanding.  The Internet Society (ISOC) has been advocating the use of DNSSEC and is also providing information on the use of […]

  11. […] available you’ll be able to start playing around with very cool new technologies like the DANE protocol… who knows what you’ll be able to do with […]

  12. […] “TLSA Record (DANE)” hebben. Weer zo’n ding waar ik nog nooit van gehoord had. DANE staat voor “DNS-Based Authentication of Named Entities” en zorgt er voor dat je zeker […]

  13. […] DANE.  At is most basic, DANE is a protocol that links certificate verification to the DNS.  It means […]

  14. […] The above-mentioned attack happens because DNS was not designed with security in mind and as a result, there is no default security mechanism baked into it to authenticate that the request was sent by the rightful owner of the domain. Most probably, this shortcoming will be fixed with the deployment of DNSSEC and DANE. […]

Leave a Reply

Your email address will not be published. Required fields are marked *