Security experts say ICANN should address collisions before approving more new TLDs

ICANN’s Security and Stability Advisory Committee has told ICANN it needs to do more to address the problem of name collisions before it approves any more new gTLDs.
In its latest advisory (pdf), published just before Christmas, SSAC says ICANN is not doing enough to coordinate with other technical bodies that are asserting authority over “special use” TlDs.
The SAC090 paper appears to be an attempt to get ICANN to further formalize its relationship with the Internet Engineering Task Force as it pertains to reserved TLDs:

The SSAC recommends that the ICANN Board of Directors take appropriate steps to establish definitive and unambiguous criteria for determining whether or not a syntactically valid domain name label could be a top-level domain name in the global DNS.
…
Pursuant to its finding that lack of adequate coordination among the activities of different groups contributes to domain namespace instability, the SSAC recommends that the ICANN Board of Directors establish effective means of collaboration on these issues with relevant groups outside of ICANN, including the IETF.

The paper speaks to at least two ongoing debates.
First, should ICANN approve .home and .corp?
These two would-be gTLDs were applied for by multiple parties in 2012 but have been on hold since August 2013 following an independent report into name collisions.
Names collisions are generally cases in which ICANN delegates a TLD to the public DNS that is already broadly used on private networks. This clash can result in the leakage of private data.
.home and .corp are by a considerable margin the two strings most likely to be affected by this problem, with .mail also seeing substantial volume.
But in recent months .home and .corp applicants have started to put pressure on ICANN to resolve the issue and release their applications from limbo.
The second incident the SSAC paper speaks to is the reservation in 2015 of .onion
If you’re using a browser on the privacy-enhancing Tor network, .onion domains appear to you to work exactly the same as domains in any other gTLDs, but under the hood they don’t use the public ICANN-overseen DNS.
The IETF gave .onion status as a “Special Use Domain“, in order to prevent future collisions, which caused ICANN to give it the same restricted status as .example, .localhost and .test.
But there was quite a lot of hand-wringing within the IETF before this status was granted, with some worrying that the organization was stepping on ICANN’s authority.
The SSAC paper appears to be designed at least partially to encourage ICANN to figure out how much it should take its lead from the IETF in this respect. It asks:

The IETF is an example of a group outside of ICANN that maintains a list of “special use” names. What should ICANN’s response be to groups outside of ICANN that assert standing for their list of special names?

For members of the new gTLD industry, the SSAC paper may be of particular importance because it raises the possibility of delays to subsequent rounds of the program if ICANN does not spell out more formally how it handles special use TLDs.
“The SSAC recommends that ICANN complete this work before making any decision to add new TLD names to the global DNS,” it says.

Is the .home new gTLD doomed? ICANN poses study of security risks

ICANN has set up a study into whether certain applied-for new gTLD strings pose a security risk to the internet, admitting that some gTLDs may be rejected as a result.
Its board of directors on Saturday approved new research into the risk of new gTLD clashes with “internal name certificates”, saying that the results could kill off some gTLD applications.
In its rationale, the board stated:

it is possible that study might uncover risks that result in the requirement to place special safeguards for gTLDs that have conflicts. It is also possible that some new gTLDs may not be eligible for delegation.

Internal name certificates are the same digital certificates used in secure, web-based SSL transactions, but assigned to domain names in private, non-standard namespaces.
Many companies have long used non-existent TLDs such as .corp, .mail and .home on their private networks and quite often they obtain SSL certs from the usual certificate authorities in order to enable encryption between corporate resources and their internal users.
The problem is that browsers and other applications on laptops and other mobile devices can attempt to access these private namespaces from anywhere, not only from the local network.
If ICANN should set these TLD strings live in the authoritative DNS root, registrants of clashing domain names might be able to hijack traffic intended for secure resources and, for example, steal passwords.
That’s obviously a worry, but it’s one that did not occur to ICANN’s Security and Stability Advisory Committee until late last year, when it immediately sought out the help of the CA/Browser Forum.
It turned out the the CA/Browser forum, an alliance of certificate authorities and browser makers, was already on the case. It has put in new rules that state certificates issued to private TLDs that match new gTLDs will be revoked 120 days after ICANN signs a contract with the new gTLD registry.
But it’s still not entirely clear whether this will sufficiently mitigate risk. Not every CA is a member of the Forum, and some enterprises might find 120 day revocation windows challenging to work with.
Verisign recently highlight the internal certificate problem, along with many other potential risks, in an open letter to ICANN.
But both ICANN CEO Fadi Chehade and the chair of SSAC, Patrick Falstrom, have said that the potential security problems are already being addressed and not a reason to delay new gTLDs.
The latest board resolution appears to modify that position.
The board has now asked CEO Fadi Chehade and SSAC to “consider the potential security impacts of applied-for new-gTLD strings in relation to this usage.”
The Root Server Stability Advisory Committee and the CA/Browser Forum will also be tapped for data.
While the study will, one assumes, not be limited to any specific applied-for gTLD strings, it’s well known that some strings are more risky than others.
The root server operators already receive vast amounts of erroneous DNS traffic looking for .home and .corp, for example. If any gTLD applications are at risk, it’s those.
There are 10 remaining applications for .home and five for .corp.

Afilias exec returns to ICANN board

Afilias chief technology officer Ram Mohan has been reappointed to ICANN’s board of directors for a fourth year.
He’s the Security and Stability Advisory Committee’s non-voting liaison, joining the board in 2009.
According to a notice (pdf) posted on ICANN’s web site yesterday, he’s been picked to continue in the role for another year.
Board liaisons, who are unpaid, serve annual terms and there are no limits on the number of years they can serve.
As arguably the most-conflicted person on the ICANN board in relation to new gTLDs, Mohan does not sit in on discussions of the program.

Some new TLDs will have traffic from day one

Some non-existent top-level domains already receive so much traffic that they would risk being overwhelmed if delegated under ICANN’s new TLD program.
That’s one of the takeaways from a new report from ICANN’s Security and Stability Advisory Committee, published this week (pdf).
Amazingly, the SSAC found that the top 10 non-existent TLDs already account for a whopping 10% of traffic at the DNS root servers, with some strings receiving many millions of lookups every day.
Over a quarter of the TLD resolutions handled by the roots result in errors, it found.
Most of these invalid lookups are the result of configuration errors on networking gear.
The word “local” is responsible for about 5% of all TLD lookups, the report says. The terms “corp”, “lan”, “home” and “belkin” also account for big slices of traffic.
This presents potentially serious security problems, as you might imagine.
Imagine that “.lan” is approved as a TLD. Previously unresolveable domains would start working, and badly configured gear could start sending private LAN data out into the cloud.
It would also put an big load on the .lan TLD operator from day one.
The SSAC said:

The .lan TLD registry operator – and generally, any TLD registry operator that chooses a string that has been queried with meaningful frequency at the root – potentially inherits millions of queries per day. These queries represent data that can be mined or utilized by the registry operator.

The report recommends that ICANN add certain highly trafficked strings from to its list of prohibited TLDs, and also that it warns applicants for TLDs that already have traffic.

We recommend that ICANN inform new TLD applicants of the problems that can arise when a previously seen string is added to the root zone as a TLD label and that ICANN should coordinate with the community to identify principles that can serve as the basis for prohibiting the delegation of strings that may introduce security or stability problems at the root level of the DNS.

If endorsed by ICANN, the recommendation could make TLDs such as .home, .corp and .local verboten. It could also present Belkin with a problem if it planned to apply for a “.brand”.
(UPDATE: .local is actually already on the reserved list)