191 research outputs found
NSEC5, DNSSEC authenticated denial of existence
The Domain Name System Security Extensions (DNSSEC) introduced two
resource records (RR) for authenticated denial of existence: the NSEC
RR and the NSEC3 RR. This document introduces NSEC5 as an
alternative mechanism for DNSSEC authenticated denial of existence.
NSEC5 uses verifiable random functions (VRFs) to prevent offline
enumeration of zone contents. NSEC5 also protects the integrity of
the zone contents even if an adversary compromises one of the
authoritative servers for the zone. Integrity is preserved because
NSEC5 does not require private zone-signing keys to be present on all
authoritative servers for the zone, in contrast to DNSSEC online
signing schemes like NSEC3 White Lies.https://datatracker.ietf.org/doc/draft-vcelak-nsec5/First author draf
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
Can NSEC5 be practical for DNSSEC deployments?
NSEC5 is proposed modification to DNSSEC that simultaneously guarantees two security properties: (1) privacy against offline zone enumeration, and (2) integrity of zone contents, even if an adversary compromises the authoritative nameserver responsible for responding to DNS queries for the zone. This paper redesigns NSEC5 to make it both practical and performant. Our NSEC5 redesign features a new fast verifiable random function (VRF) based on elliptic curve cryptography (ECC), along with a cryptographic proof of its security. This VRF is also of independent interest, as it is being standardized by the IETF and being used by several other projects. We show how to integrate NSEC5 using our ECC-based VRF into the DNSSEC protocol, leveraging precomputation to improve performance and DNS protocol-level optimizations to shorten responses. Next, we present the first full-fledged implementation of NSEC5—extending widely-used DNS software to present a nameserver and recursive resolver that support NSEC5—and evaluate their performance under aggressive DNS query loads. Our performance results
indicate that our redesigned NSEC5 can be viable even for high-throughput scenarioshttps://eprint.iacr.org/2017/099.pdfFirst author draf
DSTC: DNS-based Strict TLS Configurations
Most TLS clients such as modern web browsers enforce coarse-grained TLS
security configurations. They support legacy versions of the protocol that have
known design weaknesses, and weak ciphersuites that provide fewer security
guarantees (e.g. non Forward-Secrecy), mainly to provide backward
compatibility. This opens doors to downgrade attacks, as is the case of the
POODLE attack [18], which exploits the client's silent fallback to downgrade
the protocol version to exploit the legacy version's flaws. To achieve a better
balance between security and backward compatibility, we propose a DNS-based
mechanism that enables TLS servers to advertise their support for the latest
version of the protocol and strong ciphersuites (that provide Forward-Secrecy
and Authenticated-Encryption simultaneously). This enables clients to consider
prior knowledge about the servers' TLS configurations to enforce a fine-grained
TLS configurations policy. That is, the client enforces strict TLS
configurations for connections going to the advertising servers, while
enforcing default configurations for the rest of the connections. We implement
and evaluate the proposed mechanism and show that it is feasible, and incurs
minimal overhead. Furthermore, we conduct a TLS scan for the top 10,000 most
visited websites globally, and show that most of the websites can benefit from
our mechanism
A Security Evaluation of DNSSEC with NSEC3
Domain Name System Security Extensions (DNSSEC) and
Hashed Authenticated Denial of Existence (NSEC3) are
slated for adoption by important parts of the DNS hierarchy,
including the root zone, as a solution to vulnerabilities
such as ”cache-poisoning” attacks. We study the security
goals and operation of DNSSEC/NSEC3 using Murphi,
a finite-state enumeration tool, to analyze security properties
that may be relevant to various deployment scenarios.
Our systematic study reveals several subtleties and potential
pitfalls that can be avoided by proper configuration
choices, including resource records that may remain valid
after the expiration of relevant signatures and potential insertion
of forged names into a DNSSEC-enabled domain
via the opt-out option. We demonstrate the exploitability
of DNSSEC opt-out options in an enterprise setting by constructing
a browser cookie-stealing attack on a laboratory
domain. Under recommended configuration settings, further
Murphi model checking finds no vulnerabilities within
our threat model, suggesting that DNSSEC with NSEC3
provides significant security benefits
Library and Tools for Server-Side DNSSEC Implementation
Tato práce se zabĂ˝vá analĂ˝zou souÄŤasnĂ˝ch open source Ĺ™ešenĂ pro zabezpeÄŤenĂ DNS zĂłn pomocĂ technologie DNSSEC. Na základÄ› provedenĂ© rešerše je navrĹľena a implementována nová knihovna pro pouĹľitĂ na autoritativnĂch DNS serverech. CĂlem knihovny je zachovat vĂ˝hody stávajĂcĂch Ĺ™ešenĂ a vyĹ™ešit jejich nedostatky. SoučástĂ návrhu je i sada nástrojĹŻ pro správu politiky a klĂÄŤĹŻ. FunkÄŤnost vytvoĹ™enĂ© knihovny je ukázána na jejĂm pouĹľitĂ v serveru Knot DNS.This thesis deals with currently available open-source solutions for securing DNS zones using the DNSSEC mechanism. Based on the findings, a new DNSSEC library for an authoritative name server is designed and implemented. The aim of the library is to keep the benefits of existing solutions and to eliminate their drawbacks. Also a set of utilities to manage keys and signing policy is proposed. The functionality of the library is demonstrated by it's use in the Knot DNS server.
Understanding the Role of Registrars in DNSSEC Deployment
The Domain Name System (DNS) provides a scalable, flexible name resolution service. Unfortunately, its unauthenticated architecture has become the basis for many security attacks. To address this, DNS Security Extensions (DNSSEC) were introduced in 1997. DNSSEC’s deployment requires support from the top-level domain (TLD) registries and registrars, as well as participation by the organization that serves as the DNS operator. Unfortunately, DNSSEC has seen poor deployment thus far: despite being proposed nearly two decades ago, only 1% of .com, .net, and .org domains are properly signed. In this paper, we investigate the underlying reasons why DNSSEC adoption has been remarkably slow. We focus on registrars, as most TLD registries already support DNSSEC and registrars often serve as DNS operators for their customers. Our study uses large-scale, longitudinal DNS measurements to study DNSSEC adoption, coupled with experiences collected by trying to deploy DNSSEC on domains we purchased from leading domain name registrars and resellers. Overall, we find that a select few registrars are responsible for the (small) DNSSEC deployment today, and that many leading registrars do not support DNSSEC at all, or require customers to take cumbersome steps to deploy DNSSEC. Further frustrating deployment, many of the mechanisms for conveying DNSSEC information to registrars are error-prone or present security vulnerabilities. Finally, we find that using DNSSEC with third-party DNS operators such as Cloudflare requires the domain owner to take a number of steps that 40% of domain owners do not complete. Having identified several operational challenges for full DNSSEC deployment, we make recommendations to improve adoption
- …