POSTS TAGGED: icann
Blog Moderator | May 06, 2016
Guest Post from Duane Wessels, Principal Research Scientist
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.Read more
Keith Drazek | Jun 25, 2014
The National Telecommunications and Information Administration’s (NTIA) March 14, 2014, announcement proposing the transition of its legacy Internet Assigned Numbers Authority (IANA) stewardship role has presented the Internet Corporation for Assigned Names and Numbers (ICANN) multi-stakeholder community equal amounts of opportunity and responsibility. We have been handed a singular opportunity to define the terms of any stewardship transition and the fundamental responsibility to get it right.
Getting it right means ensuring, through a bottom-up, multi-stakeholder process, the reform of ICANN’s accountability structures to protect the community and the multi-stakeholder model prior to NTIA’s disengagement from its oversight and stewardship role. It also means acting quickly and efficiently so our window of opportunity is not missed.
At ICANN’s 50th meeting taking place in London this week, some have suggested that there are “elements” or “forces” among us who oppose the IANA stewardship transition and that calls for accountability reform are tantamount to delay tactics. I have found the opposite to be true. There is significant community support for NTIA’s announcement. There is significant support for NTIA’s four key principles. There is universal support for initiating a bottom-up, multi-stakeholder process to develop a recommended transition plan for NTIA’s consideration. The community also recognizes our limited time to get the work done and the need to propose concrete and implementable enhancements. And, perhaps most importantly, there’s a rapidly growing and strong consensus that ICANN’s accountability reform is a key dependency for any successful IANA stewardship.
On March 24, 2014, at the 49th ICANN meeting in Singapore, Verisign’s Pat Kane, senior vice president of Naming and Directory Services, made the following statements in support of the NTIA announcement, accountability and the multi-stakeholder process:
- Verisign recognizes that it is probably the right time to transition the IANA functions and stewardship of those functions away from the United States government.
- Verisign further recognizes that the ICANN community is ready to begin the conversation and its multi-stakeholder, bottom‐up structures have matured and will be the means by which a proposed solution for the transition is developed for continued operations of the IANA functions.
- We support ICANN as the convener of this process as we find solutions for the clerical, authorizing, and technical operations of IANA which are all tied to accountability to the community.
- The accountability regime that replaces the NTIA's stewardship should ensure enforceable and auditable transparency and accountability mechanisms. The DNS community and the global business and user communities deserve no less as such mechanisms are critical to the functioning of an open and secure Internet for everyone.
- We look forward to contributing to the process and the proposed solution.
Those comments were made almost exactly three months ago. To eliminate any uncertainty around Verisign’s position on the issues of IANA Stewardship Transition and ICANN Accountability, I will take this opportunity to dispel any question or misinformation and reaffirm our views:
- Verisign supports NTIA’s March 14, 2014, announcement;
- Verisign supports NTIA’s four key principles;
- Verisign supports the bottom-up, multi-stakeholder process now under way;
- Verisign supports the target date of September 2015 for transition;
- PROVIDED the multi-stakeholder community recommendations for ICANN’s accountability reform are accepted by NTIA before the final transition and sufficiently implemented by ICANN subject to measurable deliverables.
Burt Kaliski | May 06, 2014
Recent comments on the name collisions issue in the new gTLD program raise a question about the differences between established and new gTLDs with respect to name collisions, and whether they’re on an even playing field with one another.
Verisign’s latest public comments on ICANN’s “Mitigating the Risk of DNS Namespace Collisions” Phase One Report, in answering the question, suggest that the playing field the industry should be concerned about is actually in a different place. The following points are excerpted from the comments submitted April 21.
In a previous comment, Eric Osterweil summarized key differences between established and new gTLDs as they affect name collision risks. Namespaces associated with established TLDs, he observed, represent “well known and measurable real estate” that system administrators can plan for. In contrast, namespaces associated with applied-for strings including new gTLDs, Osterweil continued, “inherently have no well-known policies and structure” – other than the assumption that they weren’t expected to be delegated in the future foreseeable to system administrators.
Osterweil’s points are important to keep in mind, because they apply just as much to one of the comments in this public review period as they did to comments in the previous period.
A better understanding of the situation starts with clear definitions. A name collision occurs when one system assumes that a name is in one name space, another system assumes that the name is in another name space, and the two systems interact unaware of their difference in assumptions. One of the reasons they may not be aware is that the assumptions of both systems were historically the same, and then the assumptions of one of the systems changed.
ICANN’s Security and Stability Advisory Committee (SSAC) expresses the definition as follows in SAC062:
“The term ‘name collision’ refers to the situation in which a name that is properly defined in one operational domain or naming scope may appear in another domain (in which it is also syntactically valid), where users, software, or other functions in that domain may misinterpret it as if it correctly belonged there.”
With this definition in mind, it’s useful to highlight two situations that are not the same as name collisions.
Burt Kaliski | Apr 16, 2014
Verisign posted preliminary public comments on the "Mitigating the Risk of DNS Namespace Collisions" Phase One Report released by ICANN earlier this month. JAS Global Advisors, authors of the report contracted by ICANN, have done solid work putting together a set of recommendations to address the name collisions problem, which is not an easy one, given the uncertainty for how installed systems actually interact with the global DNS. However, there is still much work to be done.
Below, I have outlined the four main observations from ICANN’s "Mitigating the Risk of DNS Namespace Collisions" Phase One Report discussed in Verisign’s public comment along with recommendations:
Burt Kaliski | Mar 26, 2014
Presentations, papers and video recordings from the name collisions workshop held earlier this month in London are now available at the workshop web site, namecollisions.net.
The goal for the workshop, described in my “colloquium on collisions” post, was that researchers and practitioners would “speak together” to keep name spaces from “striking together.” The program committee put together an excellent set of talks toward this purpose, providing a strong, objective technical foundation for dialogue. I’m grateful to the committee, speakers, attendees and organizers for their contributions to a successful two-day event, which I am hopeful will have benefit toward the security and stability of Internet naming for many days to come.
Keynote speaker, and noted security industry commentator, Bruce Schneier (Co3 Systems ) set the tone for the two days with a discussion on how humans name things and the shortcomings of computers in doing the same. Names require context, he observed, and “computers are really bad at this” because “everything defaults to global.” Referring to the potential that new gTLDs could conflict with internal names in installed systems, he commented, “It would be great if we could go back 20 years and say ‘Don’t do that’,” but concluded that policymakers have to work with DNS the way it is today.
Bruce said he remains optimistic about long-term prospects as name collisions and other naming challenges are resolved: “I truly expect computers to adapt to us as humans,” to provide the same kind of trustworthy interactions that humans have developed in their communications with one another.