Home / Blogs

How DANE Strengthens Security for TLS, S/SMIME and Other Applications

The Domain Name System (DNS) offers ways to significantly strengthen the security of Internet applications via a new protocol called the DNS-based Authentication of Named Entities (DANE). One problem it helps to solve is how to easily find keys for end users and systems in a secure and scalable manner. It can also help to address well-known vulnerabilities in the public Certification Authority (CA) model. Applications today need to trust a large number of global CAs. There are no scoping or naming constraints for these CAs—each one can issue certificates for any server or client on the Internet, so the weakest CA can compromise the security of the whole system. As described later in this article, DANE can address this vulnerability.

Dane is Built on DNSSEC

DANE is built on the foundation provided by the DNS Security Extensions (DNSSEC). DNSSEC is a cryptographic system to verify the authenticity of data in the DNS. Domain owners digitally sign data in their DNS zones, and DNS resolvers authenticate these signatures as they lookup DNS records. This provides protection against well-known attacks, such as DNS cache poisoning and DNS spoofing.

Validating with DNSSEC

In effect, DNSSEC transforms the DNS into an authenticated directory of information associated with domain names, and as a result some natural follow-on benefits appear. DNSSEC can be used to securely store and retrieve cryptographic keying material, such as public keys, X.509 certificates, etc. in the DNS. These can in turn be used to significantly strengthen the security of Internet applications, and address a variety of vulnerabilities that exist in today’s deployed systems.

Security for TLS Using DANE

The “TLSA” DNS record type defined in the DANE protocol describes how to associate Transport Layer Security (TLS) certificates with the domain names of servers. These can then be used to secure TLS applications, such as Web (HTTPS), email transport (Simple Mail Transport Protocol (SMTP) over TLS), instant messaging (XMPP over TLS) and many more.

Security for TLS using DANE

SMTP over TLS is one application where DANE is seeing growing production scale deployment on email servers with large numbers of users. The appearance of DANE for SMTP transport security is particularly timely. SMTP over TLS has traditionally been used in an opportunistic manner—it is used only if both sides of the SMTP connection support it. However, a man-in-the-middle attacker can easily subvert the security by stripping away the TLS capability indication and downgrade the connection to be unencrypted. With DANE, SMTP servers use the presence of a signed TLSA record in the DNS to (a) confirm the intent to secure the session with TLS, preventing downgrade attacks, and (b) authenticate the connection with DANE.

Additional DANE record types are currently in development to accommodate more applications.

Security for Email Using DANE

The upcoming OPENPGPKEY and SMIMEA records will allow use of the DNS to store and retrieve PGP (Pretty Good Privacy) public keys and S/MIME certificates for end users. PGP and S/MIME are commonly used for secure end-to-end messaging (i.e. encryption and digital signing). DANE provides a new way to authenticate these keys and certificates in addition to or in place of the current ways that users do this. In addition the DNS provides an always available, globally distributed mechanism to find these keys, solving a crucial problem of easily locating keys for inter-organizational email. The end-to-end messaging scenario is discussed in detail in a recent Verisign blog post.

Security for email using DANE

Emerging projects, such as the US National Cybersecurity Center of Excellence’s (NCCoE) Secure Email initiative, are already exploring ways to use such mechanisms. With the advent of DNSSEC and DANE, it is now possible to deploy inter-organizational secure email in a truly scalable and manageable way.

More Security Use Cases For DANE

The proposed Payment Association (PMTA) record associates payment information (such as account numbers, Bitcoin wallets and other forms of electronic currency) with easier to use domain names typically corresponding to users. Companies like Armory and Netki are already integrating DANE PMTA support in their Bitcoin wallet implementations.

There is a proposal to enhance the TLSA record to allow the use of TLS client certificates. This fills a gap in the current specification, which only works with TLS server certificates. With this enhancement, many applications that employ client certificates will be able to use DANE to authenticate them. In particular, some design patterns from the Internet of things are already planning to use this mechanism, where large networks of physical objects identified by domain names may authenticate themselves using TLS to centralized device management and control platforms.

Another proposal in progress involves a DANE and DNSSEC authentication chain extension for the TLS protocol. This mechanism allows a TLS server, when prompted by a compatible client, to deliver the TLSA record corresponding to its server certificate along with the complete chain of DNSSEC records needed to authenticate it. The TLS client gains a performance advantage by not needing to do all these DNS queries itself. It can also help in situations where the client finds itself behind a middlebox that impedes its ability to successfully issue DANE- and DNSSEC-enabled queries. These things are important preconditions for applications like Web browsers and Web servers to adopt DANE.

What is takes for DANE to work

In short, DANE provides the ability to use DNSSEC to perform the critically important function of secure key learning and verification. It can use the DNS directly to distribute and authenticate certificates and keys for endpoints. It can also work in conjunction with today’s public CA system by applying additional constraints about which CAs are authorized to issue certificates for specific services or users—thereby significantly reducing risks in the currently deployed CA system. A recent paper from Verisign Labs explores this topic in more detail.

For more information, visit the Verisign Labs page on DANE.

By Shumon Huque, Principal Research Scientist at Verisign Labs

Filed Under

Comments

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

VINTON CERF
Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Related

Topics

Brand Protection

Sponsored byCSC

IPv4 Markets

Sponsored byIPv4.Global

New TLDs

Sponsored byRadix

DNS

Sponsored byDNIB.com

Domain Names

Sponsored byVerisign

Cybersecurity

Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API