Do we already have strong security protections for our Internet services? For many years now, we have had numerous cryptographically enhanced protocols. Standards and suites like S/MIME, Transport Layer Security (TLS), IP Security (IPSec), OpenPGP, and many others have been mature for years, have offered us a range of protections and have been implemented by a wealth of code. Indeed, based on these protections, we already count on having “secure” eCommerce transactions, secure point-to-point phone calls that our neighbors can’t listen in on, secure Virtual Private Networks (VPN) that let us remotely connect to our internal enterprise networks, etc. However, our Internet security protocols have all excluded a very important step from their security analyses; none of them describe a crucial step called secure key learning. That is, before we can encrypt data or verify signatures, how does someone bootstrap and learn what cryptographic keys are needed? In lieu of a way to do this, we have traditionally prefaced the security protections from these protocols 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), and each protocol must do this separately (and potentially in its own, different, way). This is because the protocols we use for protections have not formally specified a standardized way to securely bootstrap protocols.
For example, consider in Figure 1, a user Alice must have learned the public key of her recipient Bob in advance of sending an encrypted email. Suites like S/MIME and OpenPGP do not include automatic mechanisms to securely learn the key(s) of remote users. So, without a standard, accepted mechanism, many users accomplish this today by having in-person meetings and vetting the key/identity mapping ahead of time. Once a key has been securely learned for a recipient, encrypted email can be sent at any time, and only the holder of that public key’s private portion will be able to decrypt it.
In contrast, if Alice wants to send encrypted email to another user Chuck (whom she has not learned the key for in advance), even if Chuck has a public key, Alice cannot automatically securely learn it and use it. There is no established/standard mechanism to do this across the Internet today. If, for example, Chuck were to send his certificate (containing his public key) along with the email, how would Alice be able to distinguish Chuck’s authentic email+certificate from a forged-email+unauthentic-certificate that Eve might have constructed, which would just purport to belong to Chuck? Here, Eve does not need to intercept any key learning between Alice and Chuck, there simply is no architecture for Alice to securely learn Chuck’s key, and so their email correspondence is not encrypted.
Any security (including OOB and ToFU) that is done without secure key learning is incomplete, and often an insufficient solution.
What’s missing from X.509 and TLS today?
We count on TLS’ use of X.509 today, so how is it not doing secure key learning? Well, TLS accepts X.509 certificates over an unsecured TCP channel. The current protections hinge on the assumption that the received certificates can be verified by any of a list of globally trusted Certification Authorities (CAs) that already exist on the client’s system. This set of CAs is maintained via some form of OOB key learning. A more detailed discussion of this can be found in some of our prior work.[1]
Enter, DANE
Recently, however, a simple observation has sparked a flurry of innovation: for those protocols that use DNS, secure key learning can be accomplished from DNS itself, and verified by the DNS Security Extensions (DNSSEC). The IETF has started standardizing a suite of protocols called DNS-based Authentication of Named Entities (DANE)[2] 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.[3] Putting DANE into Domain Name System (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 Figure 1 illustrated that there currently is no standard protocol that would allow Alice to send encrypted email to Chuck. Revisiting this example using DANE, Figure 2 demonstrates how encrypted email can be sent between any parties without prior key exchange, because of the previously non-existent secure key learning. In these cases, the value proposition for DANE is not just about its reduced attack surface, but rather more about the new facilities it enables.
Why is this such 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 of our Internet activities. Think about it: when was the last time we expected users or applications to rely on hardcoded IP addresses for navigation? DNSSEC has been operationally deployed for almost 10 years, has been deployed in the DNS root for 5 years and has also been in .com and .net for years. This means that domain owners can deploy DNSSEC or purchase managed services for DNSSEC in their zones today. In some recent work,[4] we have even 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.
What DANE is good for
DANE makes security better for some existing services. With DANE, Hypertext Transfer Protocol (HTTPS) wouldn’t need to do OOB key learning, as DANE’s “stapling” [5] makes it easy to authenticate which CA a certificate holder intended to be verified by. In other words, if a website purchases a certificate from a well known CA, then DANE allows client Relying Party (RP) software to unambiguously verify which CA is authorized to vouch for that website. Today, that is not possible, and current ambiguity has been used to launch highly publicized Man-in-the-Middle (MitM) attacks. In this way, DANE actually makes the CA model more secure. CAs offer semantics that DANE does not address (trust, extended validation, etc.), and in specific usage modes, DANE simply disambiguates which CA a service is using. This makes DANE a critical advent that can be used to enhance the role of CAs. DANE also enables Internet services that were previously either not possible or that eluded formal secure key learning analyses. With DANE, for example, inter-organizational email (shown earlier in Figure 1and Figure 2), Opportunistic Encryption (OE) for protocols like TLS and IPSec, and even brand new things like Cryptocurrency, can now be protected by Internet security standards.
One of the innovative uses of DANE and DNSSEC is to offer a way for users to deliver payment instructions via the DNS. Verisign has worked with the team behind the Armory Bitcoin Secure Wallet (one of the most trusted open-source Bitcoin security providers of cold storage and multi-sig) to propose a new resource record in the DNS. Because this record is delivered via a secured chain of trust anchored in the DNS, users can rely on the authenticity of the payment instructions. One way to locate the records in the DNS is to simply use the payee’s email address, the same approach used by other proposed DANE record types. The flexible record offers multiple ways to effect payment including the use of payment scripts, simple addresses and cryptographic proofs that verify that the invoice is authentic and accurate. This is one of the practical examples of leveraging the strong security in well managed, signed top level domains like .com to reduce friction in financial transactions.[6] We plan to continue to work with innovators in various spaces whose applications can be made more secure and usable by publishing authenticated information through DANE.
DANE Has Arrived
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, we’ve already deployed and run the substrate for DANE for decades! So, when can you use DANE? How about right now: DANE+TLS for Postfix, or a browser add-on for Internet Explorer, Firefox, Chrome, Opera and Safari, and stay tuned to Verisign Labs for an upcoming release of an S/MIME plugin for Mozilla’s Thunderbird!
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 (often our service providers are critical to this). Just as in nature, we would like each member of our herd to be strong and resilient. DANE gives us all a way to address this, but it still falls to each of us to deploy and use it. For DANE to provide the Internet with security akin to herd immunity we must each begin doing our part to enable strong security. This means pushing for DNSSEC deployment in our networks (a requirement of DANE), to embrace DANE in our end systems (mail clients, browsers, etc.), in our systems deployments, and to spread the word! Feel free to reach out to us (Verisign) directly with questions, be sure to check out the Verisign blog for future posts on DANE and related topics from our Labs team, and tell others what you have found!
[1] Described here: http://conferences.npl.co.uk/satin/papers/satin2012-Osterweil.pdf or https://www.youtube.com/watch?v=GWpSQZcU3fU
[2] https://datatracker.ietf.org/wg/dane/charter/
[3] http://stats.labs.apnic.net/dnssec
[4] http://blogs.verisigninc.com/blog/tags/npsec
[5] Described here: http://conferences.npl.co.uk/satin/papers/satin2012-Osterweil.pdf or https://www.youtube.com/watch?v=GWpSQZcU3fU
[6] Source code demonstrating the use of DANE to look up payment addresses is available in the git repository: https://github.com/etotheipi/BitcoinArmory/tree/wallet2.0-dns/
