You may have seen the news this morning that we have joined forces with Juniper Networks to provide a comprehensive, always on, DDoS solution. At Verisign, we focus on protecting companies from increasingly complex cyber threats, and this relationship should only raise the bar higher, as it will provide a different, more integrated approach than what’s used today, to help ensure faster and more efficient detection and mitigation.
I’m delighted to announce that the name collisions workshop this weekend will include Jeff Schmidt, CEO of JAS Global Advisors, presenting the Name Collision Occurrence Management Framework that his firm just released for public review.
Jeff’s presentation is one of several on the program announced by the program committee for the Workshop and Prize on Root Causes and Mitigations of Name Collisions (WPNC).
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.
There may still be a few security practitioners working in the field who didn’t have a copy of Bruce Schneier’s Applied Cryptography on their bookshelf the day they started their careers. Bruce’s practical guide to cryptographic algorithms, key management techniques and security protocols, first published in 1993, was a landmark volume for the newly emerging field, and has been a reference to developers ever since.
Beyond just the popularity of the book, Bruce has also been widely recognized over the past two decades for his insightful commentary on the security issues of the day, featured on his monthly Crypto-Gram newsletter, his blog, “Schneier on Security,” 11 more books including the newly published Carry On, as well as numerous essays, op-eds and interviews.
It’s a genuine privilege therefore that Bruce will be keynoting the upcoming Name Collisions Workshop, to be held on March 8-10, in London.
According to the Online Etymology Dictionary, the verb collide is derived from the Latin verb collidere, which means, literally, “to strike together”: com- “together” + lædere “to strike, injure by striking.”
Combined instead with loquium, or “speaking,” the com- prefix produces the Latin-derived noun colloquy: “a speaking together.”
Researchers and practitioners know well the benefits of the colloquium, the technical conference, a gathering of those speaking together on a topic.
So consider WPNC 14 – the upcoming namecollisions.net workshop – a colloquium on collisions: speaking together to keep name spaces from striking together.
Many years ago on my first trip to London, I encountered for the first time signs that warned pedestrians that vehicles might be approaching in a different direction than they were accustomed to in their home countries, given the left-versus-right-side driving patterns around the world. (I wrote a while back about one notable change from left-to-right, the Swedish “H Day,” as a comment on the IPv6 transition.)
If you’re not sure on which side to expect the vehicles, it’s better to look both ways — and look again — if you want to reduce the risk of a collision.
We recently hosted Dr. Ralph Merkle as a guest speaker for the Verisign Labs Distinguished Speaker Series. His talk, “Quantum Computers and Public-Key Cryptosystems,” was a great presentation on how molecular nanotechnology — the ability to economically manufacture most arrangements of atoms permitted by physical law — could fundamentally alter the world as we know it. Ralph’s and many others’ research on this topic has been groundbreaking and we are grateful he took the time to come and share his knowledge.
ICANN’s second-level domain (SLD) blocking proposal includes a provision that a party may demonstrate that an SLD not in the initial sample set could cause “severe harm,” and that SLD can potentially be blocked for a certain period of time. The extent to which that provision would need to be exercised remains to be determined. However, given the concerns outlined in Part 2 and Part 3 of this series, it seems likely that there could be many additions (and deletions!) from the blocked list given the lack of correlation between the DITL data and actual at-risk queries.
As widely discussed recently, observed within the ICANN community several years ago, and anticipated in the broader technical community even earlier, the introduction of a new generic top-level domain (gTLD) at the global DNS root could result in name collisions with previously installed systems. Such systems sometimes send queries to the global DNS with domain name suffixes that, under reasonable assumptions at the time the systems were designed, may not have been expected to be delegated as gTLDs. The introduction of a new gTLD may conflict with those assumptions, such that the newly delegated gTLD collides with a domain name suffix in use within an internal name space, or one that is appended to a domain name as a result of search-list processing.
As discussed in the several studies on name collisions published to date, determining which queries are at risk, and thus how to mitigate the risk, requires qualitative analysis (New gTLD Security and Stability Considerations; New gTLD Security, Stability, Resiliency Update: Exploratory Consumer Impact Analysis; Name Collisions in the DNS). Blocking a second level domain (SLD) simply on the basis that it was queried for in a past sample set runs a significant risk of false positives. SLDs that could have been delegated safely may be excluded on quantitative evidence alone, limiting the value of the new gTLD until the status of the SLD can be proven otherwise.
Similarly, not blocking an SLD on the basis that it was not queried for in a past sample set runs a comparable risk of false negatives.
A better way to deal with the risk is to treat not the symptoms but the underlying problem: that queries are being made by installed systems (or internal certificates are being employed by them) under the assumption that certain gTLDs won’t be delegated.