Do you recall when you were a kid and you experienced for the first time an unnatural event where some other kid “stole” your name and their parents were now calling their child by your name, causing much confusion for all on the playground? And how this all made things even more complicated—or at least unnecessarily complex when you and that kid shared a classroom and teacher, or street, or coach and team, and just perhaps that kid even had the same surname as you, amplifying the issue! What you were experiencing was a naming collision (in meatspace).

Simply because two different families (administrative entities), in different households (unique name spaces), selected the name du jour and forever labeled their offspring accordingly, you now have to suffer. It didn’t occur to them at the time (or perhaps it did) that it may well be the most popular name of the day and ripe for collisions throughout your life, or it may have been the least desirable name, or perhaps because of uniqueness or spelling, or because of known or yet unrealized historical artifacts, or perhaps it simply possess some other attribute that only later in life would make it problematic or even more endearing.

Naming collisions happen all the time. When uniqueness within a name space is preserved, for example within a household among siblings, or jersey numbers on a ball team, it’s not a problem. But when you begin to merge name spaces or not preserve uniqueness, e.g., multiple households have like-named kids that attend a communal school, or father and son share the same given name, collisions may occur and it can be really problematic if not handled accordingly. In order to regain uniqueness you typically add prefixes to the names (e.g,. Big John Smith and Lil’ John Smith and Mrs. John Smith), or append suffixes (e.g., John Smith Sr. and John Smith Jr.), these new labels serve as discriminators in the namespace.

Enter the Internet, a new kind of space, aka. cyberspace, a global network of loosely interconnected networks where billions of users and devices coexist. Absent some mechanism to preserve uniqueness of names across the space one might want to transact with [Big] John Smith and find themselves talking to his son or wife instead. As discussed in a previous post, for the global Internet name space, uniqueness of names is ensured by the Domain Name System (DNS). The DNS employs a hierarchical allocation structure (think of an upside down tree from the root to the leaves) to enable safe predictable navigation on the Internet. These names are then used by applications of all sorts to transact: for example, big.john.smith.com would be a different identifier in john.smith.com namespace (household) than lil.john.smith.com.

In cyberspace, as in meatspace, names are used to identify an entity (e.g., a web or database server). However, because on the Internet the DNS provides a global system for uniqueness of names, many folks naturally and immediately begin to make assumptions about the rigidity of those names and the spaces in which they exist—assumptions regarding both what does exist in that namespace and what is non-existent in that namespace. For example, assume you were building an internal network at an enterprise that you never intend to expose ‘directly’(ß operative word) to the Internet and you have to develop a naming scheme for servers and desktop systems. To make this work and preserve uniqueness across the enterprise, you select an internal domain - let’s say .inc - as your base domain. Just to be safe, and because you’re clever, you check the current list of country code and generic top level domains (e.g., the 317 TLDs such as COM, NET, CN, ME, etc..) and ensure there are no collisions with your internal top level domain in the global DNS, an important step if you intend to allow Internet access from portions of the internal network. From there, you use team responsibilities to create subdomains (e.g., QA, DEV, SALES, FINANCE, HR, ETC..) in the .inc domain, and hostnames are based on some concoction of employee names and location (e.g., you-thisblog.engineering.inc), or some such schema.

Next, you need to support the ability to communicate securely with software engineering servers, finance databases and human resource systems and to be able to validate that when you’re connecting to a system (e.g., a code repository) it’s actually that system and not some imposter. To do this, you use the state of the art, digital certificates and public key cryptography—which mostly means you fire up a web browser and go buy some certificates (or acquire a managed PKI service) from one of any number of Certification Authorities (CAs). This then allows you to deploy digital certificates that can be used to authenticate the identity of your systems (e.g., you-thisblog.engineering.inc) and to secure communications across the network. Remember, you want to be sure that when your employees use their standard web browsers and email clients (FireFox, IE, Chrome, Outlook, etc.) that the security checks all pass muster.

The only requirement you really have in order to make sure your users don’t get browser warnings, or connection failures, is that the CA you get the certificates from is embedded as “trusted root CA” (Authorities) in the applications you use—and that’s because this root CA is required for your browser to have a trusted way to bootstrap validation and ensure that when connecting to a server the certificate hasn’t been tampered with). Basically, when we use any “Relying Party” software (software that relies on claims for security-related tasks—e.g., like web browsers), we implicitly expect the software maintainers to keep our list of CAs fresh, current, and up to date. This is the heart of today’s state of the art public key cryptography, for end users. See Figure 1 from my Firefox browser Certificate Manager and Authorities tab (and see the Mozilla project Root CA store for more information on CAs embedded there).

Figure 1: Firefox Certificate Manager Authorities Window (Click to Enlarge)

OK, you’ve now got a naming schema in place built upon your .inc TLD, mapping enterprise IP addresses to names, and corresponding [Internal] name-based certificates from CAs on servers where secure communications are required. You’re up and running and all is good. This setup is illustrated in Figure 2. Note that because you want to provide both local and Internet connectivity, your name server(s) (recursive name server) look in both the global DNS and the local enterprise name database to resolve names. For example, you may not even realize that it may check to see if the name exists in the global root of the DNS before it checks the local systems, or it may check local systems first. But, because you were clever enough to verify that .inc doesn’t exist in the wild, it shouldn’t matter what search order you use… right? Also, you’re using public key cryptography, so DNS resolution is not important, right? Well, not exactly…

As you might expect, irrespective of the sequence of which namespace is checked first, if .inc appears only in the enterprise namespace things should be fine. However, if it somehow is added to the global namespace then you may never be able to resolve names that map to systems within your own network, even from your own local name server(s), or vice versa. This is but one of the “first order” naming collisions issues that might exist and needs to be understood with new gTLDs, as it can literally break connectivity in your enterprise.

Figure 2: Two Disjoint Name Spaces with DNS Server Between (Click to Enlarge)

Another example relates to a slightly different naming collision issue. In mid-March ICANN’s Security and Stability Advisory Committee published an advisory titled SAC057: SSAC Advisory on Internal Name Certificates. The crux of the problem is this: if anyone can go get a certificate issued that allows them to attest to the identity of systems within some previously unused namespace, and then that namespace finds its way into the global DNS namespace (e.g., .inc is delegated in the root), those same techniques and certificates can (will) be employed by miscreants to compromise otherwise secure communications related to that namespace. In fairness to the CAs, these certificates were only supposed to be used internally by the recipients (users typically have to agree to that when they are issued) such as .inc and really should NOT be visible on the global Internet facing services, although some do tend to leak out, as discussed in SAC057 and in the EFF SSL Observatory.

ICANN did take a stab at addressing this issue after SSAC brought it to their attention. Specifically, they worked with the CA/Browser (CAB) Forum on efforts that led to the development of Ballot 96, which in a nutshell says that participating CAs should stop issuing certificates that end in an applied-for-gTLD string within 30 days of ICANN signing the contract with the registry operator, and they should also revoke any existing certificates related to that applied-for-string within 120 days of ICANN signing the contract with the registry operator. While this is great progress, there’s still much work that remains to mitigate this vulnerability, to include recognition that:

1. Not all CAs are members of the CA/Browser Forum (many are not)
2. Certificate revocation is largely ineffective on the Internet for many reasons
3. 120 days is not a practical amount of time for an enterprise that has been using some namespace for years to reconfigure their infrastructure, obtain and deploy new certificates for all their systems, etc. So, when CAs begin to try and effectuate this, the timelines will surely expand as they can’t be expected to do things that would disrupt their customer networks only months after selling them updated certificates within that very same namespace
4. Astute attackers would disable revocation checks (e.g., block status queries) when launching man in the middle (MITM) attacks.

While I commend ICANN for some notable progress in this area in a number of weeks after SAC057 was brought to their attention, the vulnerability is far from resolved. And whether or not .inc or any other namespace should have been used by naïve users on the Internet in the first place, many of those decisions were made in good faith and based on best current practices, and have been operational for years. Delegating strings that could impact operational networks without some attempt to thoroughly and accurately evaluate the risks of those delegations and the impact on users connectivity or consumer security IS unilaterally transferring risks to consumers (e.g., the Internal Name Certificate issue), their networks and applications can break when these delegations occur, and we ought not be doing that absent some careful consideration of the implications.

Furthermore, assessing the risks associated with a particular string delegation in the root cannot merely be derived from a snapshot of data from a subset of servers across the root server system, and that risk assessment can’t be based on root query volume alone, as the accuracy of any such study is critical. To illustrate this point simply consider an Internet-connected emergency communication system that used .center as a domain internally for Public Service Access System (PSAP) naming, or a medical device installation technician that used .med for an Internet-connected medical sensor network. These strings may only generate a small number of queries per week or month that find their way to the root server system, but if those networks and critical applications are broken because of delegations of new gTLDs and no attempt has been made to identify those network operators and provide some remediation support before a change is made the implications could be significant. Now consider the thousands or millions of networks that use .home and .corp, among other more common strings—who’s answering the phone when those networks break—assuming the phone works?

For a bit of background from folks who have studied and considered the role of DNS in National Security / Emergency Preparedness (NS/EP) communications systems have a look at the NSTAC Report to the President on Communications Resiliency [PDF] and the U.S. FCC’s CSRIC III Work Group 8 E-9-1-1 Best Current Practice reports part 1 [PDF] and part 2 [PDF].

ICANN just last week announced the undertaking of two studies, one on dotless domain names, which SSAC SAC053 [PDF], Microsoft, and Mozilla, among others have already commented on, and one on the Use of Non-Delegated TLDs, which SAC045 [PDF], SAC046 [PDF], SAC057 [PDF], PayPal, and others have discussed as necessary before delegations occur. Given that the ICANN Board clearly sees the need to conduct these studies, perhaps with the help of another SSAC nudge [PDF], I do hope that the latter of these two studies doesn’t artificially constrain itself to not answer these important questions completely and with due care, and with the perspective of the consumers that depend on these systems in mind. The projected timeframes seem extremely [absurdly] short to me, and absent any early warning capability or instrumentation mechanism across the root server system getting to accurate answers is going to be even more challenging. That said, I think this is progress, let’s hope it’s not simply checking boxes.