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.
Burt Kaliski | Mar 04, 2014
Burt Kaliski | Feb 26, 2014
The Mitigating the Risk of DNS Namespace Collisions report, just published by JAS Global Advisors, under contract to ICANN, centers on the technique of “controlled interruption,” initially described in a public preview shared by Jeff Schmidt last month.
With that technique, domain names that are currently on one of ICANN’s second-level domain (SLD) block lists can be registered and delegated for regular use, provided that they first go through a trial period where they’re mapped to a designated “test” address. The staged introduction of new SLDs is intended to provide operators of installed systems the opportunity to assess the potential impact of an impending name collision on their own, before any external operators have an opportunity to exploit it.
The new technique is subject to a public comment period before being adopted (including discussion at the upcoming Name Collisions Workshop). However, if this technique (or any other) were adopted, it would stand to reason the staged introduction would need to be monitored carefully. Someone would need to check that SLDs on the block lists actually did go through the trial period, and were not put into regular use without the appropriate opportunity for assessment by operators of installed systems.
(Note that Verisign isn’t endorsing the technique; we are reviewing the just-published Mitigating the Risk of DNS Namespace Collisions report, and we’ve already expressed reservations about the statistical invalidity of SLD block lists as an indicator of name collision risk. That being said, the point still remains that if such a technique were adopted, it would need to be monitored to ensure correct implementation.)
Given the anticipation of “controlled” interruption, it’s ironic that while ICANN specifically precludes the delegation of domain names on the SLD block lists, dozens of them were actually registered and delegated!
That fact was recently duly noted by one of Verisign’s researchers who has been analyzing the daily progress of new gTLDs. As it turns out, nearly all delegated SLDs that should have been blocked were cancelled over the past weekend after independent reports citing the existence of inappropriate delegations began to circulate.
That the delegations of SLDs on the block lists could have caused name collisions with installed systems is not our primary concern. (And, as noted above, we don’t consider the block lists – which are based solely on query frequency at specific points in time – to be the final word on which delegations might or might not cause name collisions. As our chief security officer Danny McPherson has well explained in one of his blog posts, “Query frequency data without query context isn’t enough.”)
Our concern, rather, is that domain names on the SLD block lists were delegated at all, given ICANN’s clear direction to the contrary. As Pat Kane and I have noted in a broader-ranging letter to NTIA on operational miscues in the new gTLD delegation process, a policy that’s unenforced is worse than no policy at all.
If this is the state of affairs when the answer is “no” – effectively, a state of “uncontrolled interruption” – what happens when the answer changes to “wait 120 days”?