• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Red Sift Blog

Red Sift Blog
  • redsift.com
  • Featured
  • Who are we?
  • Get in touch
You are here: Home / Email / DMARC / Boosting your online security using DANE

Boosting your online security using DANE

by Ivan Kovachev
September 29, 2020August 30, 2022Filed under:
  • DMARC

DNS-Based Authentication of Named Entities or DANE is a new way of associating a certificate to a domain name without having to rely on external third parties. Published under RFC 7671, it introduces a new Internet standard for setting up TLS (Transport Layer Security) communication between a client and a server, without having to rely on trusted Certificate Authorities (CAs).

The traditional CA model, upon which TLS has depended so far, has the inherent problem of “too many CAs” which allows any of these CAs to issue a certificate for any domain. Instead, DANE relies on the DNSSEC infrastructure (Domain Name System Security Extensions) to bind a domain name to a certificate.

Why was DANE developed?

There are two main reasons:

  • Improper use of trusted third-party CAs – Attackers can sometimes successfully impersonate a person or service and obtain a rogue certificate. Although this certificate is valid and issued by a trusted third party, it is not designated to the intended person. Other mis-issuance of certificates can be found here.
  • Eliminating the possibility of MITM (Man-In-The-Middle) attacks – MITM is when an attacker intercepts the conversation between a client and server by inserting themselves into the middle of the conversation, tricking both parties to think that they are talking to each other. This can lead to TLS session downgrade or cache poisoning. Often, when a client tries to connect to a server, the server has no way of knowing in advance that the server on the other side supports TLS or that it is talking to the correct server.

What is needed to deploy DANE?

  • Security-aware resolver that can query and validate DNSSEC and TLSA records
  • DNSSEC signed zone and RRsets

Can DANE be used by any application?

As long as the application uses TLS to connect to services identified by domain names, DANE is universal. It is backwards compatible, so if DANE is not supported by a mail server, the client can fall back to using STARTTLS or even clear text. It was developed to be deployed gradually while interoperating with the existing email backbone. As DANE adoption grows, it will promote the use of DNSSEC and vice versa. We will have a look at the adoption rate of DANE a bit later. 

So, can it be used to secure email?

Yes, as hinted in the previous section, one of the main applications that can make use of DANE is, indeed, email.

Existing protocols are not sufficient to protect your email from being intercepted along the way or from landing in the wrong hands. 

DANE is, in fact, the only protocol so far that can protect your email by enabling your client to know in advance, whether or not the server on the other side supports TLS, that the data it receives is coming from an authenticated server, and hasn’t been modified in transit. If a malicious party tries to intercept the traffic or modify it in transit, DANE will detect that, abort the connection and either try another server or delay the message until a secure channel can be established.

How does DANE achieve the above?

DANE makes use of the already existing DNSSEC protocol, to make sure the data it receives is authentic and has not been tampered with. DANE also introduces a new DNS RR type called TLSA which helps to signal to the client that a server supports TLS. 

A TLSA record needs to be set up for each application that makes use of TLS. Each one of those applications will run on different ports and based on the port number, a TLSA record can exist. 

Here is an example of a left-most label of a TLSA record for an SMTP service running TLS, for the domain “example.com”: “_25._tcp.mail.example.com”

To retrieve the TLSA record, a client would construct a DNS query that would look like this:  “_25._tcp.mail.example.com”. 

To request a TLSA resource record for a HTTP server running TLS on port 443 at “www.example.com“, the query would look like this: “_443._tcp.www.example.com”.

But I thought that DMARC protects my email, why do I need DANE now?

Both technologies can be easily confused and while both DANE and DMARC involve some form of authentication, they are fundamentally different and protect different parts of the communication. 

DMARC authenticates the sending FROM domain and prevents it from being spoofed so that a recipient can be sure the email has come from the rightful owner of the domain. You can find out more information about DMARC here.

DANE on the other hand provides a secure channel between the sender and recipient, ensuring that the sender is talking to the right recipient while preventing MITM from intercepting or modifying the email in transit.  

Although both technologies complement each other, they are not a replacement for one another.

What is the adoption rate of DANE?

The adoption of DANE and DNSSEC, as one of the prerequisites for DANE, seems to have grown considerably over the last few years, with some areas reporting an increase in adoption of up to 300%.

What are some of the recommended protocols to implement for more secure email communication?

Sending and receiving email does not just involve the use of POP, IMAP or SMTP, it heavily relies on the DNS infrastructure. Inherently, all of those technologies are insecure and require other protocols to be involved in order to secure different parts of the communication. 

The main protocols to implement on your domain / mail server are:

  1. SPF, DKIM, DMARC – to prevent your domain from being used in spoofing attacks against your clients/partners. 
  2. DNSSEC – to protect yourself from DNS cache poisoning, and to make sure that the answers you get from DNS are valid and authentic.
  3. DANE – to protect your client-server communication with TLS and prevent MITM attacks.

By configuring the above protocols, you will not only protect yourself and your clients but also contribute towards a safer online email environment.

If you’d like to educate yourself further about DANE or test your current configuration, take a look at our further reading sources below:

  • DANE Documents: https://greatdane.io/resources/
  • DANE – How to: https://github.com/internetstandards/toolbox-wiki/blob/master/DANE-for-SMTP-how-to.md 
  • RFC related documents: https://datatracker.ietf.org/wg/dane/documents/ 
  • Addressing MITM attacks: https://www.m3aawg.org/sites/default/files/M3AAWG-Man-in-the-Middle-Recommendations2015-07.pdf 
  • Generate DANE TLSA record: https://www.huque.com/bin/gen_tlsa 
  • To test your domain for DANE use: https://dane.sys4.de

For more information about security protocols and email configuration, feel free to get in touch.

Get in touch

Share this:

  • Click to share on Twitter (Opens in new window)
  • Click to share on LinkedIn (Opens in new window)

Related

Tagged:
  • DMARC
  • email security
  • tls

Post navigation

Previous Post What is an email bounce and how does it affect deliverability?
Next Post Red Sift and the Royal Marines: A Radical Idea?

Primary Sidebar

Subscribe to our blog and be the first to get updates!

Categories

  • AI
  • BEC
  • BIMI
  • Brand Protection
  • Coronavirus
  • Cybersecurity
  • Deliverability
  • DMARC
  • DORA
  • Email
  • Finance
  • Labs
  • News
  • OnINBOX
  • Partner Program
  • Red Sift Tools
  • Work at Red Sift
  • March 2023
  • February 2023
  • January 2023
  • December 2022
  • November 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • July 2021
  • June 2021
  • May 2021
  • April 2021
  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • March 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • July 2019
  • June 2019
  • May 2019
  • April 2019
  • March 2019
  • February 2019
  • January 2019
  • December 2018
  • November 2018
  • October 2018
  • September 2018
  • August 2018
  • July 2018
  • June 2018
  • May 2018
  • April 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • September 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • October 2016

Copyright © 2023 · Red Sift