During the second half of the previous century the number of sensitive business communications and financial transactions increased rapidly. These communications often involved parties from different organizations that had not communicated previously nor had the chance to exchange shared keys for symmetric encryption.

In 1976 Diffie, Hellman and Merkle presented Public Key Cryptography (PKC) [1] as a solution for securing communications between two parties that did not have the chance to exchange shared encryption keys beforehand. A crucial requirement for PKC to work, not properly addressed at the time of invention, is that public keys must be associated with their users in a trusted (i.e. authenticated) manner, for instance by a trusted third-party (e.g. in the form of signed certificates) or in some kind of trusted directory. An infrastructural technology that addresses binding public keys to parties and the distribution of those keys is generally called Public Key Infrastructure (PKI). Although PKC is widely recognized and adopted as key technology for secure communications on the Internet, the key distribution and binding issue described above and other drawbacks, such as summarized in [2], have limited the success of many application or domain-specific PKIs. This paper proposes an alternative approach for public key binding and distribution by leveraging the existing Internet Domain Name System (DNS) and its security extensions (DNSSEC) for creating an infrastructural solution for dynamic trust establishment. Our proposal is not tied to a specific application but can be reused across a variety of applications. It allows for establishment of secure communication channels between peers that have no prior relationship and thus accommodates for the distributed nature of trust management on the Internet. The research questions that our approach addresses can be summarized as: how to address the major shortcomings of traditional PKC/PKIs that use Certificate Authorities and statically configured root certificates, how to support dynamic secure connection setup between peers that do not have a prior relationship, using a trusted directory service, and how to leverage generic and/or existing Internet infrastructural services to implement a directory service that securely binds public keys to parties and that can be used for the distribution of those keys.

Although much related work exists on key authentication and distribution issues, we focus here on approaches that apply directory services to address the problem. The ISO X.500 recommendation [3] was to be a global, distributed database of named entities also known as a global on-line telephone book or directory service. The ISO X.509 recommendation [4] was published as part of X.500, defining X.509 certificates that were used to bind public keys to X.500 path names (called Distinguished Names). The X.500 approach requires a single, global naming discipline and as of today there are too many legacy naming systems in use that can not be simply replaced or united in a single discipline. Therefore the X.500 idea of a single, globally unique name that everyone could use when referring to an entity, is not likely to occur. One notable exception to this rule is the DNS [5] for naming Internet resources as we will focus on in this paper. The X.509 certificates however have become a commodity on the Internet today, binding public keys to names. Jones et al. proposed the Internet Key Service (IKS), which is a distributed architecture for authenticated distribution of public keys, layered on DNSSEC [6]. Clients use DNSSEC to securely discover the identities of the relevant IKS servers, and send key lookup or management requests directly to these servers using a special-purpose protocol. We believe that the suitability and scalability of the DNS itself does not justify the development of a new protocol and system. Moreover our approach also addresses the operational aspects of the system through actual applications rather than focusing on the system itself. IPsec can use opportunistic encryption and rely on DNSSEC as a keying mechanism within the Internet Key Exchange (IKE) protocol [7]. The objective of opportunistic encryption is to allow encryption without having any pre-arrangements in place that are specific to the systems involved. Each system administrator adds public key information to DNS records to support opportunistic encryption and then enables this feature in the nodes’ IPsec stack. Once this is done, any two such nodes can communicate securely by retrieving a KEY Resource Record (RR) from DNSSEC to be used for communicating with the host or identity associated with the name. This is similar to the solution that we propose in this paper, but we use DNSSEC for building opportunistic TLS channels. Le and Guyennet propose a solution to grid applications’ specific needs in data transport security in [8]. To address the key management part, the solution secures the local DNS server with the DNSSEC extensions, making it become a local certification authority. This design choice solves a dual problem: secret key distribution and scalability of the solution. The authors have strictly focused on setting up SSH sessions. They have developed an implementation of their proposal by modifying an SSH client. There are no formal specification of the protocol or architecture and no evaluation against other approaches. Thus the results cannot be generalized easily. Schlyter et al. describe the use of the DNS as a certificate store and its implication for path validation in an X.509 PKI [9]. This proposal resembles the approach followed in this paper with the exception that DNS is used without the DNSSEC extensions. Therefore the resolved certificate must be checked against a local certificate store instead of relying on a shared trusted infrastructure provided by DNSSEC. In [10] Schlyter and Griffin present a proposal for securing SSH by using DNS lookups. As described in the previous paragraph, the main difference with our approach is that trust is verified explicitly on-request by the user instead of relying on a mandatory trusted DNSSEC infrastructure. Moreover this approach concentrates on the SSH application only. In [11] Josefsson describes how to use the DNS as a certificate directory. This approach resembles the one we follow in this paper but offers a less generic perspective. Its focus is on the machinery of storing and resolving certificates and how to use those certificates for electronic messaging.


Please enter your comment!
Please enter your name here