DANE as the basis for secure data transmission of e-mails
August 2019 by Marc Jacob
DANE with DNSSEC ensures that your e-mail arrives safely at the right address. A bad reputation spreads very quickly and it is for this reason that mail order companies, service providers or the banking sector are keen to maintain or optimize their reputation on the Internet. However, a good reputation is quickly lost, especially if customers are victims of a so-called man-in-the-middle attack. In a man-in-the-middle attack, the attacker positions himself between the customer and the supplier and pretends to be the supplier. Such an attack also works in the other direction.
Let’s take the following example as an illustration: Suppose you are an online mail order company and send automated transaction emails such as invoices and order confirmations. These are forwarded to third parties via a "Man in the Middle". The invoice never reaches your customer and you don’t even notice anything amiss. Of course you don’t get any money because the customer has never received an invoice. What happens? You send a reminder. A reminder without a previous invoice causes annoyance and loss of trust from the customer. From a marketing point of view this is a disaster. It could be even worse: In the event of a successful attack, sensitive customer data such as addresses, bank details and shopping habits can fall into unauthorized hands. This is a particular problem in the case of insurance companies, medical coverage, banks and dating platforms, where highly sensitive customer data is on the move.
The protection of your customer data should not only be a top priority for you, but also for the e-mail service provider that sends mails on your behalf. Article 33 of the European Data Protection Regulation (GDPR) explains what happens in case of a personal data breach: the person responsible (in this case the marketing company) must inform the supervisory authority and the persons concerned of the data violation under the conditions of Article 34 GDPR. It’s not just your reputation that’s at risk. You also risk financial consequences. Insofar as responsibility for breaches of personal data protection can be attributed to the person responsible or the processor appointed by him (in this case the e-mail service provider), the supervisory authorities may exercise sanctions, corrective measures and investigations against the person responsible in accordance with Article 58 of the GDPR.
In the worst case scenario, this could even lead to a definitive ban on processing this type of data, which in practice means a ban on business activity. In addition, fines may be imposed. Article 83 of the DGPS provides for substantial fines of up to €20 million or 4% of total annual turnover. The most recent example: the British Data Protection Authority (ICO) imposed a fine of €205 million on British Airways after unknown persons had access to the company’s customer data.
The fact is that it is not enough to secure your own server in the best possible way: a man in the middle uses a weak point to send an e-mail from A to B. In order to meet the requirements of Article 5 paragraph 1 f. GDPR, you should protect sensitive customer data with DNSSEC and DANE.
What are DNSSEC and DANE?
DANE (DNS-based Authentication of Named Entities) is a test method that secures the establishment of an encrypted connection between a client and a server. By means of a certificate comparison (TLSA record), communication partners using DANE fill the conceptual weakness of SSL/TLS, in which a third party could impersonate the "right server" and cause the client to transfer data to the "wrong right address". The prerequisite for the use of DANE is DNSSEC (Domain Name System Security Extensions), which ensures that the test characteristics transmitted via DNS can be verified. Here, too, hackers could introduce false information into the DNS and lead the customer to the wrong address.
And this is how it works:
What does a typical mail sent with DANE look like? Suppose you are an online merchant and you send an email to a customer with an email account on example.de. That is what would happen:
Your mail server determines the mail server responsible for the recipient domain. It also checks whether the DNS server offers the recipient domain DNSSEC.
If the DNS server offers DNSSEC, your mail server checks whether there is a TLSA record for the recipient domain.
Then your mail server establishes a connection to the mail server of the recipient domain. If the recipient domain does not offer STARTTLS to encrypt the connection, your mail server will immediately block the message due to suspicion of a downgrade attack.
If the target server offers STARTTLS, your mail server will start a TLS-encrypted connection. It compares the checksum of the target server’s certificate with the TLSA information received via DNSSEC.
If the sums match, the target server is verified. If there is no match, a DANE customer will immediately cancel the transaction because there is a suspicion of a man-in-the-middle attack. Without these controls, data will eventually be sent to an unreliable address.
In order for DANE to work with DNSSEC, both must be configured on the online merchant’s mail server. If an e-mail service provider is used for sending e-mails, the mail platform must be extended so that DNS queries also check for DNSSEC functionality and use its verification capabilities.
The foundations for this have long been laid. "DNSSEC is a mature process that has been stable for years," says Patrick Koetter (competence group leader of the "Anti-Abuse" and "E-Mail" groups of eco – associations of the internet industry). "Practical experience on large ISP platforms and measurements show that the concerns of some administrators are not tenable from a technical point of view.
Considering the financial consequences and the loss of reputation that a downgrade attack and/or "man in the middle" attack can entail, the effort for activating DANE and DNSSEC is worthwhile. They are the only automated and cost-effective option for truly secure data transmission between email servers.