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.
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 it 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.
