It would be one of the ironies of global technology development that the West has effectively so far followed a Jugaad principle of “good enough” innovation for DNS security, whereas India could well embrace all the latest advances in DNS security as its Internet economy grows.

Like most other protocols from the early Internet, the DNS protocol was not designed with security built in. For those protocols, security services were typically either implemented at a different layer of the protocol stack, or were added on later. The arrangement worked fine for DNS security in the early days when there were few attacks and not much to protect.

As security threats grew, operators adapted to address them, also benefiting DNS deployments. For instance, server operators hardened their servers to prevent attackers from manipulating data stored at the server, and as a result DNS records stored at authoritative name servers were better. Network operators likewise hardened their networks to prevent attackers from modifying data transmitted between servers. As a consequence, DNS records transmitted from authoritative name servers to recursive name servers were more secure.

In parallel to these operational countermeasures, DNSSEC, a cryptographic protection for DNS records, was also developed. By adding digital signatures to DNS records, DNSSEC provides end-to-end security of the actual records. Any changes to the records—whether in storage or in transmission—can be detected by a relying party because the digital signature will no longer match. As Vint Cerf observed in his recent Verisign Labs Distinguished Speaker lecture, detection is the next line of defense when prevention fails.

Although the first draft standards for DNSSEC were available as early as 1994, it wasn’t until 2010 that DNSSEC signatures were added to the root zone, an essential step for enabling DNSSEC validation throughout the DNS hierarchy. This is where Jugaad comes in: one reason it may have taken so long for DNSSEC to be deployed was that DNS security was already “good enough” for many applications. (A similar argument can be made about IPv6 deployment.) In particular, even the one threat that most appeared to compel DNSSEC, Kaminsky’s cache-poisoning attack announced in 2008, had reasonable operational countermeasures for typical DNS deployments. If a wagon with a makeshift engine gets the job done, why buy a regular truck?

The answer, of course, is that there are some things a regular truck can do that a wagon with an engine can’t. A truck can carry more weight, it can travel faster; it’s just that much safer on the highway. Indeed, one of the interesting aspects of commercial transport is the level of standardization of shipping containers, which can be moved by ship, rail, and truck, and not easily by wagon. The key to Jugaad is not to assume that just because a truck works for many purposes, it has to work for every purpose. But that principle applies in the other direction as well.

As network communications moves to a more peer-to-peer, distributed fabric, transferable evidence of authentic DNS responses will become more important. For instance, both of last year’s Verisign Internet Infrastructure Grant projects consider partially connected environments where mobile users have high-speed connections only occasionally, or where they can sometimes connect to one another’s devices but not globally. In such situations, without an ongoing relationship with a name server, relying parties may well need independent, cryptographic evidence that a DNS response is correct. A standard, secure “shipping container” for DNS records, as provided by DNSSEC, could therefore become quite important.

The possibility that some users will be partially connected—which, as the grant recipients argue, may be the case for more rural users as the next billion users, in India and elsewhere, join the Internet—is a good motivation for deploying DNSSEC. However, there may be an even better one, and this was the focus of my recent talk at the World Hosting Days conference in Mumbai.

Web security protocols were originally developed well before DNSSEC was widely deployed. Consequently, they did not assume any special role of DNS in providing assurance that a Web server was associated with a particular key. Indeed, lacking a global directory of public keys (such as originally envisioned for the classic ITU-T X.509 standard, which, one must remember, was developed for directory authentication), early Web security implementations adopted the Web server distribution model. Rather than the client looking up a Web server’s public key in a directory, the client obtained the key from the Web server itself as part of a digital certificate, along with a chain of certificates leading back to a root public key trusted by the client.

The problem with the Web server distribution model was that it led to too much of a good thing. One root might not be enough—there are good reasons to have some diversity in the set of trusted roots a Web server can choose to work with. But a hundred or more roots, as is the case today, is clearly too many, given that clients are willing to accept certificate chains that lead to any of the roots. As described in a Verisign Labs technical report that Eric Osterweil, Matt Larson, Danny McPherson, and I published last year (a version of which appeared at SATIN 2012), the Web server distribution model is only as strong as its weakest root. An adversary who compromises any one of the roots (or in current terminology, one of the certificate authorities) can then impersonate any Web server via a “man-in-the-middle” attack. The adversary, having gained control of the network connection from the client at some point, presents a valid certificate chain including the adversary’s choice of public key and the targeted Web server’s name. The client, making no distinction about one root versus another, then accepts the connection with the adversary as authentic.

If certificates were distributed in DNS, this attack would be much more difficult because instead of it being sufficient for the adversary to compromise any certificate authority, the adversary would need to compromise the particular certificate associated with the Web server and recover the Web server’s private key. Even if only the name of the Web server’s certificate authority were published in DNS (as a record associated with the Web server), the adversary would still need to compromise the particular certificate authority chosen by the Web server. The attack surface is thus significantly reduced: from any certificate authority to a particular certificate authority and even to a particular certificate. DNS thus provides a check-and-balance: the client still requires a certificate, but it verifies more than just the certificate chain provided by the (alleged) Web server. It also verifies the check values published by the Web server in DNS.

The foregoing approach is being standardized as the TLSA record in the DANE protocol, an application of DNSSEC. TLSA is a new DNS record type defined for publishing certificates and related information associated with a domain name. The TLSA record, following DANE, is signed with the DNSSEC zone signing key, similar to other records in DNSSEC. Consequently, a client can verify that the TLSA record has not been changed, evidence that doesn’t depend on operational countermeasures.

It may well be the case that DANE/TLSA becomes the “killer application” for DNSSEC. Because Web security was initially deployed before DNSSEC, it made sense to use the Web server distribution model. However, in new deployments it makes more sense to use the latest tools, which now include DNSSEC and DANE/TLS. Of particular relevance to WHD India, is McKinsey’s projection that between 2011 and 2015, India will nearly triple its Internet user population to between 330 and 370 million—an increase representing more than half the new Internet users in the world. If this is the case, then India surely has the greatest opportunity to innovate with DNSSEC—if there indeed are good applications for it.

Another such application is the emerging DANE/SMIMEA, where DNS serves as a distribution point and a check and balance for user certificates, in particular those used in secure email. This is a major paradigm shift because in general only information about servers is published in DNS. It is especially important that information about users is well protected, making DNSSEC essential for this application.

The best opportunity, however, is likely something that hasn’t yet been conceived. With this in mind, I left the WHD audience with the challenge: What innovative uses of DNS security could enable new value as India grows its Internet presence?

Countries that built out most of their Internet presence already have adopted more of a Jugaad-style approach to DNS security and web security, using the tools available at the time. With more parts available to build with, it might be possible to build something more like a truck and less like a wagon with an engine.

Thus the challenge remains: What else would be useful to build with DNSSEC?