A Longitudinal and Comprehensive Study of the DANE Ecosystem in Email Hyeonmin Lee∗ Aniketh Girish∗ Roland van Rijswijk-Deij Seoul National University Amrita Vishwa Vidyapeetham University of Twente & NLnet Labs Taekyoung “Ted” Kwon Taejoong Chung Seoul National University Rochester Institute of Technology Abstract 1 Introduction The DNS-based Authentication of Named Entities (DANE) Transport Layer Security (TLS) is responsible for securing In- standard allows clients and servers to establish a TLS connec- ternet traffic in a variety of protocols such as DNS and HTTP. tion without relying on trusted third parties like CAs by pub- Coupled with a Public Key Infrastructure (PKI), TLS relies lishing TLSA records. DANE uses the Domain Name System on certificates to bind entities to their public keys. Certificates Security Extensions (DNSSEC) PKI to achieve integrity and are typically issued by Certificate Authorities (CAs), in a hi- authenticity. However, DANE can only work correctly if each erarchical fashion. At the top level of the hierarchy, there are principal in its PKI properly performs its duty: through their root CAs, who have self-signed certificates since they cannot DNSSEC-aware DNS servers, DANE servers (e.g., SMTP rely on other trusted third parties. servers) must publish their TLSA records, which are consistent However, the current PKI model, discussed above, has been with their certificates. Similarly, DANE clients (e.g., SMTP criticized for its potential vulnerability, since any CA can is- clients) must verify the DANE servers’ TLSA records, which sue certificates for any domain name. Historically, we have are also used to validate the fetched certificates. observed that compromised CAs issued valid-looking but DANE is rapidly gaining popularity in the email ecosystem, fraudulent certificates inappropriately [15, 58, 75]. Since then, to help improve transport security between mail servers. Yet a number of new protocols and extensions [40, 41, 48, 62, 68] its security benefits hinge on deploying DANE correctly. In have been proposed to mitigate these problems. However, this paper we perform a large-scale, longitudinal, and compre- none of these fundamentally solves the problem: the valida- hensive measurement study on how well the DANE standard tion process of a certificate still relies on CAs. and its relevant protocols are deployed and managed. We col- To address this issue, the DNS-based Authentication of lect data for all second-level domains under the .com, .net, Named Entities (DANE) protocol [38] was proposed to sup- .org, .nl, and .se TLDs over a period of 24 months to ana- port TLS without relying on trusted third-parties like CAs. At lyze server-side deployment and management. To analyse the its core, a domain name owner that runs a TLS server such as client-side deployment and management, we investigate 29 HTTPS, or secure email via SMTP+STARTTLS, can publish popular email service providers, and four popular MTA and its certificate information as a DNS record called the TLSA ten DNS software programs. record, which can be used by TLS clients to verify the authen- Our study reveals pervasive mismanagement in the DANE ticity of the certificate in a non-PKI fashion. Furthermore, the ecosystem. For instance, we found that 36% of TLSA records integrity and authenticity of the TLSA records are guaranteed cannot be validated due to missing or incorrect DNSSEC by the DNS Security Extensions (DNSSEC) [16–18]. Thus, a records, and 14.17% of them are inconsistent with their TLS server can easily publish and serve its certificate without certificates. We also found that only four email service relying on CAs, and TLS clients can also verify the certifi- providers support DANE for both outgoing and incoming cate by (1) fetching TLSA records, (2) validating them using emails, but two of them have drawbacks of not checking the DNSSEC signatures, and (3) checking if the TLSA records are Certificate Usage in TLSA records. On the bright side, consistent with the certificate from the TLS server. the administrators of email servers can leverage open source Due to its simple but robust security guarantees, there have MTA and DNS programs to support DANE correctly. been a number of attempts to deploy DANE for the Web PKI (HTTPS). However, DANE has never been adopted due ∗This work was done while the authors did an internship at Rochester to two operational challenges. First, a client (i.e., browser) Institute of Technology. may be behind a middlebox, which is notorious for discarding TLSA or DNSSEC records. Second, the browser needs to make • Second, even though most of the mail servers that pro- additional DNS queries to retrieve the TLSA and DNSSEC vide TLSA records (99.5%) present their certificates through records, which incurs additional latency. Thus, modern web STARTTLS, we find that over 14% of them do not match browsers do not usually support DANE [47]. the presented certificates. Fortunately, many email service providers have begun to • Third, when focusing on 29 popular email providers, we deploy DANE for their SMTP services as users are tolerant find that only four of them support DANE for their outgoing to millisecond-order additional delays in sending and receiv- and incoming emails and one provider only supports DANE ing emails—moreover, DANE can solve security challenges for incoming emails. in SMTP not solved so far, such as STARTTLS downgrade attacks [27] and receiver authentication [37]. • Finally, we tested four popular MTA and ten popular DNS In response to emerging threats in email security [30], the implementations to see if email providers can easily support Dutch and German national governments require DANE sup- DANE; we find that two popular MTAs correctly support port from vendors in public tenders [13, 19] and certain TLD DANE for both incoming and outgoing emails in conjunc- registries (e.g., the .se and .nl registries) have employed tion with four DNS implementations that support TLSA financial incentives for registrars providing email hosting ser- records and DNSSEC. vices to deploy DANE [59]. Finally, popular mail service Overall, our results show that DANE deployment is rare, providers have also begun to deploy DANE; Web.de (one of but steadily increasing (especially in some country-code the largest free webmail providers in Germany) supports out- TLDs). Unfortunately, we also find widespread mismanage- bound DANE since 2016 [29], and Comcast (one of the largest ment of certificates and TLSA records. On the bright side, ISPs in the US) did the same thing [26] in August 2017. however, only a few players can easily make changes in order Like other PKIs, however, DANE can only function to bring the benefits and a greater adoption of DANE to end correctly when all principals fulfill their responsibilities: users, which are mainly large email providers and MTA and TLS servers presenting certificates, DNS servers publishing DNS Software providers. TLSA records, DNS clients validating DNS responses using To allow other researchers and administrators to reproduce TLSA DNSSEC, and TLS clients verifying certificates using and extend our work, we publicly release all of our analysis records. Unfortunately, the complexity of DANE leads to code and data to the research community at many opportunities for mismanagement. For instance, on the server side, TLSA records may have DNSSEC errors such as https://dane-study.github.io expired signatures, or the certificates may be inconsistent with published TLSA records. On the client side, DNS resolvers may not validate TLSA records properly, or buggy TLS appli- 2 Background cations do not bother to check the validity of certificates. In this section, we provide an overview of DNS, DNSSEC, Surprisingly little is known about the practice of the current DANE, and explain how they work together to secure email DANE PKI ecosystem for email services. While there have transport (i.e., SMTP). been some studies of DANE [83], no prior work has studied the DANE PKI in SMTP longitudinally or comprehensively. DNS and DNSSEC DNS maintains the mapping between In this paper, we present a comprehensive study of the domain names and their associated values such as their IPv4 entire DANE ecosystem for SMTP. To study server-side be- addresses (A records) and their mail servers’ domain names havior, our work leverages daily snapshots for 24 months and (MX records). Unfortunately, the original DNS protocol [55] hourly snapshots for 4 months of MX records and TLSA records has serious security problems (e.g., no authentication of DNS for all second level domain names that end with .com, .net, records), making DNS vulnerable to numerous attacks such .org, .nl, or .se. For the MX records present, we retrieve as DNS hijacking and cache poisoning [21, 42, 70]. To pre- the certificates of the corresponding email servers. To study vent such attacks, the DNS Security Extensions (commonly client-side behavior, we investigate how DANE is supported referred to as DNSSEC) were introduced to provide integrity by analyzing (1) the 29 most popular email service providers, and authenticity of DNS records using three new record types: (2) their DNS resolvers, (3) software implementations of pop- ular or DANE-supporting mail transfer agents (MTAs), and • DNSKEY records, which contain public keys used in (4) software implementations of popular DNS programs. DNSSEC. Our analysis reveals many instances of troubling and per- • RRSIG records, which contain the cryptographic signatures sistent mismanagement in the DANE PKI in SMTP: (of DNS records) generated by the private keys; their cor- • First, we find nearly 36% of TLSA records cannot be vali- responding public keys are in DNSKEY records. dated due to missing or incorrect DNSSEC records, e.g., • DS records, which are hashes of DNSKEYs. These records some 19% are signed but lack a secure delegation (i.e., DS must be uploaded to the parent DNS zone to construct a records).