Using DANE for Authentication of Internet Services

For many years, numerous cryptographically enhanced protocols have existed. Standards and suites like Secure/ Multipurpose Internet Mail Extensions (S/MIME), Transport Layer Security (TLS), IP Security (IPSec), Open Pretty Good Privacy (OpenPGP) and many others have offered a range of protections and have been implemented by a wealth of code. Based on these protections, many assume that ecommerce transactions, point-to-point phone calls, and Virtual Private Networks (VPN) that let us remotely connect to our internal enterprise networks, etc. are all secure. However, the reality is that Internet security protocols have all excluded a very important step from their security analyses; secure key learning.

Before data can be encrypted or signatures verified, cryptographic keys need to be looked up (or learned securely). Until recently, the security protections from these protocols have been prefaced with techniques like Out of Band (OOB) key learning (learning keys in an unspecified way) or Trust on First Use (ToFU) key learning (just accepting whatever keys are found first). Each protocol performs these techniques separately and potentially in unique ways because the

protocols used for protections have not formally specified a standardized way to securely bootstrap protocols, or understand the cryptographic keys needed before encryption and verification.

Take encrypted email for example – a necessity today as people commonly share sensitive personal and business-related information over email. Standard email messages are sent in plain text, so it’s possible for someone else to access them and use that sensitive information for nefarious acts, but encrypting emails makes the messages unreadable to anyone who doesn’t possess a decryption key. It’s like locking a message in a safe, then shipping that safe. Without the key, the information stays locked inside.

Common email protocols, like S/MIME and OpenPGP, do not include automatic mechanisms to securely learn the key(s) of remote users. Therefore, without a standard, accepted mechanism, many users accomplish this today by using OOB key delivery, such as having in-person meetings and vetting the key/identity mapping before the need to send encrypted email. An example is to carry a key on an USB stick between parties. Once a key has been securely learned for a recipient out of band, encrypted email can be sent at any time but only the holder of that public key’s private portion will be able to decrypt it.

Recently, however, a simple observation has sparked a flurry of innovation. For those protocols that use the Domain Name System (DNS), secure key learning can be accomplished from DNS itself and verified by the DNS Security Extensions (DNSSEC). The Internet Engineering Task Force (IETF) has started standardizing a suite of protocols called DNS-based Authentication of Named Entities (DANE) to do secure key learning in a general way for Internet services. DANE is a relevant security solution for deployment in today’s Internet and it is ready for use. DNSSEC has now become operationally viable and is already being used to verify DNS zone contents. Putting DANE into DNS zones lets authorities extend authentication from DNSSEC data to DNS-reliant services (like S/MIME, TLS, IPSec, etc.). As DNSSEC evolves, all DANE-reliant protocols automatically gain secure key learning and rely on DNSSEC for bootstrapping.

Recall that there currently is no standard protocol that would allow a user to send encrypted email without per-user OOB key learning. Revisiting this example, by using DANE, encrypted email can be sent between any parties without prior key exchange because of the previously non-existent secure key learning. In this case, the value proposition for DANE is not just about its reduced attack surface, but rather more about the new conveniences it enables.

Why is DANE a Good Idea?

DANE is particularly timely because it is being deployed by forward thinking and security conscious operators today.

It isn’t a ground-up/green-field design that requires new infrastructure, new logic, new trusted authorities or other leaps of faith. Rather, it uses time-tested infrastructure, it simplifies what could be a complicated key learning process and many of the services that would use it are already reliant on the same substrate: DNS. DNS is a 30+ year operationally vetted technology that underlies almost all Internet activities. DNSSEC has been operationally deployed for more than 10 years, has been deployed in the DNS root for five and is used by the majority of TLDs today. This means that domain owners can deploy DNSSEC or purchase managed services for DNSSEC in their zones today. In some recent work, Verisign Labs has shown that DANE actually measurably reduces the attack surface of legacy approaches like the WebPKI and can even enhance the usefulness and utility of Certification Authorities (CAs). What this means: Internet users can rely on DNSSEC for strong authentication that builds on what we all already use.

As an architectural substrate for secure key learning in the Internet, DANE is poised to plug security holes that have existed in many protocols for many years, to enable broad federated deployment of existing protections and to seed innovation for future protections. The beauty is that the substrate for DANE has already been deployed and run for decades so it can be used right now in the following ways: DANE+TLS for Postfix; a browser add-on for Internet Explorer, Firefox Chrome, Opera, Safari and an S/MIME plugin for Mozilla’s Thunderbird, and emerging projects, such as the US National Cybersecurity Center of Excellence’s (NCCoE) Secure Email initiative, are exploring ways to use DANE enhanced protocols for secure key learning.

Throughout the Internet, we have sufficed with protocols that vary from insecure, to partially secure, to occasionally/ optionally secure. Part of this situation has derived from end-users’ inability to directly deploy their own security precautions. DANE gives everyone a way to address this – developers, enterprises and end-users just have to take advantage of it. This means pushing for DNSSEC deployment in networks (a requirement of DANE), to embrace DANE in end systems (mail clients, browsers, etc.) and in systems deployments, and to spread the word!