For more than 30 years, the industry has used a service and protocol named WHOIS to access the data associated with domain name and internet address registration activities.
Do you need to find out who has registered a particular domain name? Use WHOIS.
Do you want to see who an Internet Protocol (IP) address has been allocated to? Use WHOIS.
One of the most interesting and important changes to the internet’s domain name system (DNS) has been the introduction of the DNS Security Extensions (DNSSEC). These protocol extensions are designed to provide origin authentication for DNS data. In other words, when DNS data is digitally signed using DNSSEC, authenticity can be validated and any modifications detected.
A major milestone was achieved in mid-2010 when Verisign and the Internet Corporation for Assigned Names and Numbers (ICANN), in cooperation with the U.S. Department of Commerce, successfully deployed DNSSEC for the root zone. Following that point in time, it became possible for DNS resolvers and applications to validate signed DNS records using a single root zone trust anchor.
DNSSEC works by forming a chain-of-trust between the root (i.e., the aforementioned trust anchor) and a leaf node. If every node between the root and the leaf is properly signed, the leaf data is validated. However, as is generally the case with digital (and even physical) security, the chain is only as strong as its weakest link.
To strengthen the chain at the top of the DNS, Verisign is working to increase the strength of the root zone’s Zone Signing Key (ZSK), which is currently 1024-bit RSA, and will sign the root zone with 2048-bit RSA keys beginning Oct. 1, 2016.
One of the longstanding goals of network security design is to be able to prove that a system – any system – is secure.
Designers would like to be able to show that a system, properly implemented and operated, meets its objectives for confidentiality, integrity, availability and other attributes against the variety of threats the system may encounter.
A half century into the computing revolution, this goal remains elusive.
One reason for the shortcoming is theoretical: Computer scientists have made limited progress in proving lower bounds for the difficulty of solving the specific mathematical problems underlying most of today’s cryptography. Although those problems are widely believed to be hard, there’s no assurance that they must be so – and indeed it turns out that some of them may be quite easy to solve given the availability of a full-scale quantum computer.
Another reason is a quite practical one: Even given building blocks that offer a high level of security, designers, as well as implementers, may well put them together in unexpected ways that ultimately undermine the very goals they were supposed to achieve.
In 1905, philosopher George Santayana famously noted, “Those who cannot remember the past are condemned to repeat it.” When past attempts to resolve a challenge have failed, it makes sense to consider different approaches even if they seem controversial or otherwise at odds with maintaining the status quo. Such is the case with the opportunity to make real progress in addressing the many functional issues associated with WHOIS. We need to think differently.
The Domain Name System (DNS) offers ways to significantly strengthen the security of Internet applications via a new protocol called the DNS-based Authentication of Named Entities (DANE). One problem it helps to solve is how to easily find keys for end users and systems in a secure and scalable manner. It can also help to address well-known vulnerabilities in the public Certification Authority (CA) model. Applications today need to trust a large number of global CAs. There are no scoping or naming constraints for these CAs – each one can issue certificates for any server or client on the Internet, so the weakest CA can compromise the security of the whole system. As described later in this article, DANE can address this vulnerability.
Earlier this year, I wrote about a recent enhancement to privacy in the Domain Name System (DNS) called qname-minimization. Following the principle of minimum disclosure, this enhancement reduces the information content of a DNS query to the minimum necessary to get either an authoritative response from a name server, or a referral to another name server. This is some additional text.
In typical DNS deployments, queries sent to an authoritative name server originate at a recursive name server that acts on behalf of a community of users, for instance, employees at a company or subscribers at an Internet Service Provider (ISP). A recursive name server maintains a cache of previous responses, and only sends queries to an authoritative name server when it doesn’t have a recent response in its cache. As a result, DNS query traffic from a recursive name server to an authoritative name server corresponds to samples of a community’s browsing patterns. Therefore, qname-minimization may be an adequate starting point to address privacy concerns for these exchanges, both in terms of information available to outside parties and to the authoritative name server.
vBSDcon, hosted by Verisign, brought more than 100 attendees from the Berkeley Software Distribution (BSD) community together for a series of plenary talks, educational sessions and networking opportunities earlier this month.
“This biennial conference has been particularly special to us because of the grassroots effort within Verisign to be sure we do our part to help advance BSD,” said Verisign CTO Burt Kaliski.
Benjamin Franklin once said, “By failing to prepare, you are preparing to fail.” As we consider how Internet domain and address registration data is managed and accessed in a post-WHOIS era, and given the long history of failure in addressing the shortcomings of WHOIS, it is extremely important to start preparing now for the eventual replacement of WHOIS. This is the fundamental purpose of the next Registration Operations Workshop (ROW) that is scheduled for Sunday, July 19, 2015, in Prague, Czech Republic.
ROW 2015-2 will take place at the Hilton Prague hotel, the same venue as the 93rd meeting of the Internet Engineering Task Force (IETF-93). The workshop will be dedicated to discussion and planning for development and testing deployments of the Registration Data Access Protocol (RDAP), a recent work product of the IETF that is documented in Request For Comments (RFC) documents 7480, 7481, 7482, 7483, and 7484. RDAP was designed from the beginning to address the many shortcomings of WHOIS, but we have very little experience with early-stage implementations that can be used to inform the policy decisions that need to be made. Additional information about WHOIS and RDAP can be found in my “Where Do Old Protocols Go To Die?” blog post published earlier this year. (more…)
Perceptions can be difficult to change. People see the world through the lens of their own experiences and desires, and new ideas can be difficult to assimilate. Such is the case with the registration ecosystem. Today’s operational models exist because of decisions made over time, but the assumptions that were used to support those decisions can (and should) be continuously challenged to ensure that they are addressing today’s realities. Are we ready to challenge assumptions? Can the operators of registration services do things differently?
Do we already have strong security protections for our Internet services? For many years now, we have had numerous cryptographically enhanced protocols. Standards and suites like S/MIME, Transport Layer Security (TLS), IP Security (IPSec), OpenPGP, and many others have been mature for years, have offered us a range of protections and have been implemented by a wealth of code. Indeed, based on these protections, we already count on having “secure” eCommerce transactions, secure point-to-point phone calls that our neighbors can’t listen in on, secure Virtual Private Networks (VPN) that let us remotely connect to our internal enterprise networks, etc. However, our Internet security protocols have all excluded a very important step from their security analyses; none of them describe a crucial step called secure key learning. That is, before we can encrypt data or verify signatures, how does someone bootstrap and learn what cryptographic keys are needed? In lieu of a way to do this, we have traditionally prefaced the security protections from these protocols with techniques like Out of Band (OOB) key learning (learning keys in an unspecified way) or Trust on First Use (ToFU) key learning (just accepting whatever keys are found first), and each protocol must do this separately (and potentially in its own, different, way). This is because the protocols we use for protections have not formally specified a standardized way to securely bootstrap protocols.