How DANE Strengthens Security for TLS, S/MIME 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.


Blue Folder With Keyhole on digital background

Thinking Ahead on Privacy in the Domain Name System

Earlier this year, I wrote about a recent enhancement to privacy in the Domain Name System (DNS) called qname-minimization. Following the principle of minimum disclosure, this enhancement reduces the information content of a DNS query to the minimum necessary to get either an authoritative response from a name server, or a referral to another name server. This is some additional text.

In typical DNS deployments, queries sent to an authoritative name server originate at a recursive name server that acts on behalf of a community of users, for instance, employees at a company or subscribers at an Internet Service Provider (ISP). A recursive name server maintains a cache of previous responses, and only sends queries to an authoritative name server when it doesn’t have a recent response in its cache. As a result, DNS query traffic from a recursive name server to an authoritative name server corresponds to samples of a community’s browsing patterns. Therefore, qname-minimization may be an adequate starting point to address privacy concerns for these exchanges, both in terms of information available to outside parties and to the authoritative name server.


Blue Folder With Keyhole on digital background

“What’s in a Name?” Using DANE for Authentication of Internet Services

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.


Minimum Disclosure: What Information Does a Name Server Need to Do Its Job?

Two principles in computer security that help bound the impact of a security compromise are the principle of least privilege and the principle of minimum disclosure or need-to-know.

As described by Jerome Saltzer in a July 1974 Communications of the ACM article, Protection and the Control of Information Sharing in Multics, the principle of least privilege states, “Every program and every privileged user should operate using the least amount of privilege necessary to complete the job.”

Need-to-know is the counterpart for sharing information: a system component should be given just enough information to perform its role, and no more. The US Department of Health and Human services adopts this principle in the HIPAA privacy policy, for example, which states: “protected health information should not be used or disclosed when it is not necessary to satisfy a particular purpose or carry out a function.”

There may be tradeoffs, of course, between minimizing the amount of privilege or information given to a component in a system, and other objectives such as performance or simplicity. For instance, a component may be able to do its job more efficiently if given more than the minimum amount.  And it may be easier just to share more than is needed, than to extract out just the minimum required. The minimum amounts of privilege may also be hard to determine exactly, and they might change over time as the system evolves or if it is used in new ways.

Least privilege is well established in DNS through the delegation from one name server to another of just the authority it needs to handle requests within a specific subdomain. The principle of minimum disclosure has come to the forefront recently in the form of a technique called qname-minimization, which aims to improve privacy in the Domain Name System (DNS).


New from Verisign Labs: What’s in your attack surface?

Recently, Verisign Labs researcher Eric Osterweil and Verisign CSO Danny McPherson, along with Lixia Zhang, a professor of computer science at UCLA, received the Best Paper Award at this year’s IEEE Workshop on Secure Network Protocols (NPSec ‘14) for their paper, “The Shape and Size of Threats: Defining a Networked System’s Attack Surface.” Below is a guest post from one of the authors, Eric Osterweil, principal researcher for Verisign Labs, describing the genesis of the research and future plans.


Exploring Future Internet Architectures

UCLA and Washington University in St. Louis recently announced the launch of the Named Data Networking (NDN) Consortium, a new forum for collaboration among university and industry researchers, including Verisign, on one candidate next-generation information-centric architecture for the internet.

Verisign Labs has been collaborating with UCLA Professor Lixia Zhang, one of the consortium’s co-leaders, on this future-directed design as part our university research program for some time. The consortium launch is a natural next step in facilitating this research and its eventual application.

Van Jacobson, an Internet Hall of Fame member and the other co-leader of the NDN Consortium, surveyed developments in this area in his October 2012 talk in the Verisign Labs Distinguished Speaker Series titled, “The Future of the Internet? Content-Centric Networking.

As I stated in my summary of the talk, content-centric networking and related research areas under the heading of information-centric networking and NDN bring internet protocols up to date to match the way many of us already are using the internet. As Van noted, when people want to access content over the internet– for instance the recording of his talk – they typically reference a URL, for instance


Introducing getdns: a Modern, Extensible, Open Source API for the DNS

Verisign is pleased to announce the public introduction of getdns at The Next Web in Amsterdam (TNWEurope) April 23-24, 2014. Verisign Labs and NLNet Labs in collaboration have developed getdns, an open source implementation of the getdns-api application programming interface (api) specification.

At The Next Web, getdns is one of the challenge APIs in a 36-hour Hack Battle. Multiple teams of application coding experts are using getdns to develop innovative applications that leverage the global security infrastructure available through DNS Security Extensions (DNSSEC).