USENIX Security 2020

A Longitudinal and Comprehensive Study of the DANE Ecosystem in Email

Hyeonmin Lee^†, Aniketh Girish^*, Roland van Rijswijk-Deij^‡,
Taekyoung "Ted" Kwon^†, Taejoong "Tijay" Chung^§,

^†Seoul National University, ^*Amrita Vishwa Vidyapeetham,
^‡NLNetLabs and University of Twente, ^§Virginia Tech

About This Study

The DNS-based Authentication of Named Entities (DANE) standard allows clients and servers to establish a TLS connection without relying on trusted third parties like CAs by publishing Transport Layer Security Authentication (TLSA) records. DANE uses the Domain Name System’s Security Extensions (DNSSEC) PKI to achieve the integrity and authenticity. However, DANE can only work correctly if each of the principals in its PKI properly performs its duty: through their DNSSEC-aware DNS servers, DANE servers (e.g., SMTP servers) must publish their TLSA records, which are consistent with their certificates. Similarly, DANE clients (e.g., SMTP clients) must verify the DANE servers’ TLSA records, which are also used to validate the fetched certificates. This paper performs a large-scale, longitudinal, and comprehensive measurement study on how well the DANE standard and its relevant protocols are deployed and managed. We collect the dataset from all the second-level domains under .com, .org, .net, .nl, and .se TLDs over a period of 24 months to analyze the server-side deployment and management. For the client-side deployment and management analysis, we investigated 30 popular email service providers, and four popular MTA and 10 DNS software programs. Our study reveals the prevalent mismanagement in the DANE ecosystem. For instance, we found that 36% of TLSA records cannot be validated due to missing or incorrect DNSSEC records, and 14.17% of them are inconsistent with their certificates. We also found that only four email service providers support DANE for both outgoing and incoming emails, but two of them have drawbacks of not checking Certificate Usage in TLSA records. On the bright side, the administrators of email servers can leverage open source MTA and DNS programs to support DANE correctly.

About the Artifacts

The artifacts are largely composed of the two parts:

Server-side artifacts, which focus on (1) how we collect the data (i.e., measurement codes), (2) how we analyze the collected data (i.e., analysis codes) — Section 4 and 5 in the paper.
Client-side artifacts, which focus on (1) how we infer the mail server provider’s DANE policy. — Section 6 in the paper.

This paper has been published at USENIX Security'20 and has passed the artifact evaluation process. The paper has been updated and is available here.

About Criticism

After the paper was published, we have received many feedback from the DANE community; especially, the two authors of RFC7671, Viktor Dukhovni and Wes Hardaker, helped us a lot improve the quality of the paper. Our response is available here.