DNSSEC & DANE: no traction yet

This is the twentieth post in the 2016 FastMail Advent Calendar. Stay tuned for another post tomorrow.

---

Back in our 2014 advent series we talked about our DNS hosting infrastructure and our desire to support DNSSEC and DANE at some point in the future. It’s been two years since then, and we still don’t support either of them. What gives?

At this point we don’t have any particular timeline for supporting DNSSEC or DANE. To be clear, these two features are fairly interconnected for us; the main reason for supporting DNSSEC would be to support DANE. DANE provides a way for a domain to specify that it requires an encrypted connection and the SSL/TLS certificate that should be presented, rather than just accepting an opportunistically-encrypted one. This avoids a MITM downgrade attack and/or interception attack. Currently no email servers (that we’re aware of) verify that the domain of a certificate matches the server name they connected to or that the certificate is issued by a known CA (Certificate Authority). This means that currently server-to-server email can be opportunistically-encrypted and thus can’t be read by any intercepting party, but doesn’t protect against an active MITM attack.

Unfortunately uptake of DANE has been very slow, and it appears that most major email providers (e.g. Gmail, Outlook365, Yahoo, and many more) have no interest in supporting it at all. This severely reduces the incentive to implement as it would not improve protection for the majority of email.

Instead, providers appear to be converging on a SMTP MTA Strict Transport Security protocol, analogous to the HTTP Strict Transport Security feature that tells browsers to always use https:// when connecting to a website. It’s likely this will get much greater traction. We’re monitoring progress and intend to implement the standard when it is complete.

Along with a lack of sites supporting DANE, there are also a whole lot of scary implications about running a DNSSEC service. DNSSEC is fragile and easy to get wrong in subtle ways. A single small mistake can completely break DNS for your domain. And worse, in our case, break the DNS for the 10,000’s of domains we host for our customers.

Even some of the biggest players make mistakes. APNIC, the RIR that allocates IP addresses for the entire Asia-Pacific region (so an important and core part of the internet), managed to mess up their DNSSEC for .arpa, meaning reverse DNS lookups for a large number of IP addresses failed for some time!

Not to mention DNSSEC outages at places like nist.gov (National Institute of Standards and Technology) and even opendnssec.org (that makes DNSSEC software and attempts to “drive adoption of Domain Name System Security Extensions (DNSSEC) to further enhance Internet security”) has had multiple failures.

If the people that help run the internet or write the software and encourage the use of DNSSEC can’t get it right, it’s scary to think what non-experts could mess up. The litany of DNSSEC outages is only likely to increase, given the tiny amount of real world uptake it’s had.

We’re all for security and privacy, but part of that is ensuring availability to your email as well. We want to provide real useful benefits to users with low chance of things going wrong. At the moment, the risk trade-off profile for DNSSEC/DANE doesn’t seem right to us.