Consequences of compromised zone keys in DNSSEC

The Domain Name System is a distributed tree-based database. The DNS protocol is largely used to translate a human readable machine name into an IP address. The DNS security extensions (DNSSEC) has been designed to protect the DNS protocol. DNSSEC uses public key cryptography and digital signatures. A secure DNS zone owns at least a key pair (public/private) to provide two security services: data integrity and authentication. To trust some DNS data, a DNS client has to verify the signature of this data with the right zone key. This verification is based on the establishment of a chain of trust between secure zones. To build this chain of trust, a DNSSEC client needs a secure entry point: a zone key configured as trusted in the client. And then, the client must find a secure path from a secure entry point to the queried DNS resource. Zone keys are critical in DNSSEC and are used in every steps of a name resolution. In this report, we present a study on consequences of a compromised key in DNSSEC. We describe compromised key attacks and we present current defenses. \\ Le sytème de noms de domaine est une base de donnée distribuée basée sur un modèle arborescent. Le protocole DNS est largement utilisé pour effectuer essentiellement la correspondance entre un nom de machine et son adresse IP. Les extensions de sécurité du DNS (DNSSEC) ont été conçues pour protéger ce protocole. Pour cela, DNSSEC utilise la cryptographie à clé publique ainsi que des signatures numériques. Une zone DNSSEC possède au moins une paire de clés (publique/privée) pour signer ses données DNS et fournir ainsi deux services de sécurité essentiels\,: l'intégrité et l'authenticité des données. Pour faire confiance à des données DNS, un client DNSSEC doit en vérifier les signatures numériques avec la clé de zone appropriée. Cette vérification est basée sur l'établissement d'une chaîne de confiance entre des zones sécurisées. Pour construire cette chaîne, le client a besoin d'un point d'entrée sécurisé\,: une clé de zone configurée dans le client comme clé de confiance. Puis, le client doit trouver un chemin sécurisé partant de ce point jusqu'aux données DNS demandées. Les clés de zones sont essentielles au fonctionnement de DNSSEC et sont utilisées dans toutes les étapes d'une résolution de nom. Dans ce papier, nous présentons une étude des conséquences d'une clé compromise sur le protocole DNSSEC. Nous décrivons les attaques pouvant être mener grâce à une clé compromise et nous présentons les défenses possibles

Securing The Root: A Proposal For Distributing Signing Authority

Management of the Domain Name System (DNS) root zone file is a uniquely global policy problem. For the Internet to connect everyone, the root must be coordinated and compatible. While authority over the legacy root zone file has been contentious and divisive at times, everyone agrees that the Internet should be made more secure. A newly standardized protocol, DNS Security Extensions (DNSSEC), would make the Internet's infrastructure more secure. In order to fully implement DNSSEC, the procedures for managing the DNS root must be revised. Therein lies an opportunity. In revising the root zone management procedures, we can develop a new solution that diminishes the impact of the legacy monopoly held by the U.S. government and avoids another contentious debate over unilateral U.S. control. In this paper we describe the outlines of a new system for the management of a DNSSEC-enabled root. Our proposal distributes authority over securing the root, unlike another recently suggested method, while avoiding the risks and pitfalls of an intergovernmental power sharing scheme

User-Relative Names for Globally Connected Personal Devices

Nontechnical users who own increasingly ubiquitous network-enabled personal devices such as laptops, digital cameras, and smart phones need a simple, intuitive, and secure way to share information and services between their devices. User Information Architecture, or UIA, is a novel naming and peer-to-peer connectivity architecture addressing this need. Users assign UIA names by "introducing" devices to each other on a common local-area network, but these names remain securely bound to their target as devices migrate. Multiple devices owned by the same user, once introduced, automatically merge their namespaces to form a distributed "personal cluster" that the owner can access or modify from any of his devices. Instead of requiring users to allocate globally unique names from a central authority, UIA enables users to assign their own "user-relative" names both to their own devices and to other users. With UIA, for example, Alice can always access her iPod from any of her own personal devices at any location via the name "ipod", and her friend Bob can access her iPod via a relative name like "ipod.Alice".Comment: 7 pages, 1 figure, 1 tabl