During the second half of the previous century the number of sensitive business communications and ﬁnancial transactions increased rapidly. These communications often involved parties from diﬀerent organizations that had not communicated previously nor had the chance to exchange shared keys for symmetric encryption.
In 1976 Diﬃe, Hellman and Merkle presented Public Key Cryptography (PKC)  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 certiﬁcates) 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 , have limited the success of many application or domain-speciﬁc 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 speciﬁc 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 Certiﬁcate Authorities and statically conﬁgured root certiﬁcates, 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  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  was published as part of X.500, deﬁning X.509 certiﬁcates 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  for naming Internet resources as we will focus on in this paper. The X.509 certiﬁcates 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 . 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 . The objective of opportunistic encryption is to allow encryption without having any pre-arrangements in place that are speciﬁc 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’ speciﬁc needs in data transport security in . To address the key management part, the solution secures the local DNS server with the DNSSEC extensions, making it become a local certiﬁcation 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 speciﬁcation 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 certiﬁcate store and its implication for path validation in an X.509 PKI . This proposal resembles the approach followed in this paper with the exception that DNS is used without the DNSSEC extensions. Therefore the resolved certiﬁcate must be checked against a local certiﬁcate store instead of relying on a shared trusted infrastructure provided by DNSSEC. In  Schlyter and Griﬃn present a proposal for securing SSH by using DNS lookups. As described in the previous paragraph, the main diﬀerence with our approach is that trust is veriﬁed 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  Josefsson describes how to use the DNS as a certiﬁcate directory. This approach resembles the one we follow in this paper but oﬀers a less generic perspective. Its focus is on the machinery of storing and resolving certiﬁcates and how to use those certiﬁcates for electronic messaging.