On day one, Donuts in breach of new gTLD contract

Ooops! Donuts accidentally broke the terms of its first new gTLD Registry Agreement last night, just hours after its first string, .游戏, was delegated to the DNS root.
If you’ve been following the name collisions debate closely, you’ll recall that all new gTLD registries are banned from activating any second-level domains for 120 days after they sign their contracts:

Registry Operator shall not activate any names in the DNS zone for the Registry TLD (except for “NIC”) until at least 120 calendar days after the effective date of this agreement.

For the first four gTLDs to go live, that clock doesn’t stop ticking until November 12.
And yet, last night, Donuts activated donuts.游戏, apparently in violation of its new contractual obligations with ICANN.
The name was live and resolving for at least an hour. Donuts pulled it after we asked a company executive whether it might be a breach of contract.
I don’t think it’s a big deal, and I doubt ICANN needs to take any action.
Chalk it down to the understandable ebullience that naturally accompanies finally getting delegated to the root after such a long and painful evaluation process.
The 120-day rule was also a late amendment to Specification 6 of the RA, added by ICANN just seven days before .游戏 was delegated and over three months after Donuts signed the original contract.
It’s designed to address the potential for collisions between second-level domains in new gTLDs and names used on internal networks that already have working SSL certificates.
The no-activation window was chosen to match the 120-day period that the CA/Browser Forum gives its certificate authority members to revoke clashing certificates.
It seems unlikely donuts.游戏 will have caused any security issues during the brief period it was alive.

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.

Verisign’s security angst no reason to delay new gTLDs, says expert

Potential security vulnerabilities recently disclosed by Verisign and PayPal are well in hand and not a reason to delay the launch of new gTLDs, according to the chair of ICANN’s security committee.
Patrick Falstrom, chair of the Security and Stability Advisory Committee, said today that the risk of disastrous clashes between new gTLDs and corporate security certificates has been taken care of.
Talking to the GNSO Council at the ICANN public meeting in Beijing, he gave a definitive “no” when asked directly if the SSAC would advise ICANN to delay the delegation of new gTLDs for security reasons.
Falstrom had given a presentation on “internal name certificates”, one of the security risks raised by Verisign in a paper last week.
These are the same kinds of digital certificates given out by Certificate Authorities for use in SSL transactions on the web, but to companies for their own internal network use instead.
The SSAC, judging by Falstrom’s presentation, had a bit of an ‘oh-shit’ moment late last year when a member raised the possibility of new gTLDs clashing with the domain names on these certificates.
Consider the scenario:
A company has a private namespace on its LAN called .corp, for example, where it stores all of its sensitive corporate data. It uses a digital certificate, issued by a reputable CA, to encrypt this data in transit.
But today we have more than a few applicants for .corp that would use it as a gTLD accessible to the whole internet.
Should .corp get delegated by ICANN — which of course is by no means assured — then there could be the risk of CAs issuing certificates for public domains that clash with private domains.
That might enable, for example, a hacker on a Starbucks wifi network to present his evil laptop as a secured, green-padlocked, corporate server to an unlucky road warrior sitting in the same cafe.
According to Falstrom, at least 157 CAs have issued certificates that clash with applied-for new gTLDs. The actual number is probably much higher.
This risk was outlined in Verisign’s controversial security report to ICANN, which recommended delay to the new gTLD program until security problems were resolved, two weeks ago.
But Falstrom told the GNSO Council today that recent secretive work by the SSAC, along with ICANN security staff and the CA/Browser Forum, a certificate industry authority, has mitigated this risk to the point that delay is not needed.
Falstrom said that after the SSAC realized that there was a potential vulnerability, it got it touch with the CA/Browser Forum to share its concerns. But as it turned out, the Forum was already on the case.
The Forum decided in February, a couple of weeks after an SSAC briefing, that member CAs should stop issuing internal name certificates that clash with new gTLDs within 30 days of ICANN signing a registry contract for that gTLD.
It has also decided to revoke any already-issued internal domain certificate that clashes with a new gTLD within 120 days of contract signing.
This means that the vulnerability window will be much shorter, should the vulnerability start getting exploited in wild.
But only if all CAs conform to the CA/Browser Forum’s guidelines.
Much of this is detailed in a report issued by SSAC last month (pdf). The CA/Browser Forum’s guidance is here (pdf). Falstrom’s PowerPoint is available here (pdf)