.secure applicant claims NCC stole her idea

Domain Security Company CEO Mary Iqbal claims that NCC Group took many of her ideas for a high-security .secure top-level domain following unproductive investment talks.
Iqbal is also hinting at “potential future litigation” over the issue.
The surprising claims, made in emails to DI today, follow the announcement last week that a new NCC subsidiary, Artemis Internet, will also apply to ICANN for .secure.
“NCC Group has taken many of the security measures outlined in the Domain Security Company LLC security plan and incorporated them into the NCC Group’s proposed security measures,” Iqbal said.
Artemis chief technology officer Alex Stamos, a veteran security industry technologist, has dismissed the allegations as “completely ridiculous”.
“The only reason I know she is applying is because we did some Google searches when we were putting together our announcement,” he said.
Iqbal claims she was first contacted by NCC in January this year to talk about signing up for data escrow services – one of the technical services all new gTLD applicants need.
However, she says these talks escalated into discussions about a possible NCC investment in Domain Security Company, during which she shared the company’s security and business plans.
She said in an email:

These disclosures were made based on assurances from the NCC Group that the NCC Group was not then involved with any other applications for a secure Top Level Domain. Specific assurances were also given that the NCC Group was not involved with any other potential application for a .SECURE Top Level Domain.

But Stamos said that he’s been working on .secure at NCC since late last year, and he has no knowledge of any talks about investing in Iqbal’s company.
“All I know is that she talked to one of our salespeople about escrow,” he said. “I’ve never seen a business plan or security plan.”
Emails from an NCC executive sent to Iqbal in January and forwarded to DI by Iqbal today appear to be completely consistent with a sales call.
Iqbal said she has emails demonstrating that the talks went further, but she declined to provide them “since I may have to use it in any potential future litigation”.
Stamos pointed out that if NCC was in the habit with competing with its escrow clients, it would have applied for considerably more gTLDs than just .secure.
Artemis is proposing a significant technology development as part of its .secure bid, he said: the Domain Policy Framework, which he outlines on his personal blog here.
He added that Artemis is happy to compete with other .secure applicants – he evidently expects more to emerge – but on the merits of the application rather than “spurious claims”.
Domain Security Company “already has a very troubling history of using the legal process to overcome problems that should be based on merit”, he said.
That’s a reference to the company’s almost-successful attempt to secure US trademarks on .secure and .bank, in spite of the US trademark office’s rules against granting trademarks on TLDs.
Expect more stories like this to emerge about other gTLDs after ICANN’s Big Reveal of the applicant list next month.
Whether her claims have any merit or not, Iqbal’s not the first to claim that another applicant stole her idea, and she certainly won’t be the last.

How NCC plans to revolutionize domain name security with .secure gTLD

The proposed .secure generic top-level domain is now officially contested, after NCC Group, best known in the domain industry for its data escrow services, announced a bid.
Newly formed NCC subsidiary Artemis Internet Inc, based in San Francisco, is the official applicant.
According to Artemis chief technology officer Alex Stamos, who co-founded security testing firm iSEC Partners and sold it to NCC for $22.8 million two years ago, this is a hard security play.
The .secure gTLD would be all about enforcing strict security policies on registrants, he said.
“Right now there are a lot of interesting security technologies out there, but they’re generally not very effective because they’re optional,” he said.
As well as premium pricing and a manual registrant verification process expected to take about two weeks – complete with mailing address confirmation and two-factor authentication tokens – Artemis plans to force registrants to adhere to certain baseline security policies.
For example, all .secure web sites would have to be completely HTTPS, Stamos said. The only permissible use of a standard port 80 URL would be to redirect to the encrypted site.
The same would go for mail servers – they’d all have to use TLS to encrypt email as standard.
“When you go to bank.secure you’ll know that the software and servers at the other end are going to make the most secure decisions possible,” Stamos said.
Artemis would scan its registrants’ sites for compliance with these baseline rules, looking out for things such as botched SSL implementations.
But Artmeis wants to take it a step further. It is also proposing a new protocol, Domain Policy Framework, which would let registrants publish their security policies in the DNS.
Stamos said the company has set up a Domain Policy Working Group to develop the spec, which it plans to submit to the IETF for standardization before the end of the year.
The other members of the working group, which promise to include some “influential” names in financial services, software and social media, will be announced in July.
DPF would work alongside the existing DNSSEC and DANE protocols to enable registrants to specify, for example, which Certificate Authorities browsers should trust when accessing their .secure domain, preventing certain types of attacks, Stamos said.
Obviously, this system is not going to work without support from browser software, but Stamos said he’s hopeful that the big vendors will embrace the DPF spec.
“The most innovative and forward-leaning browsers will support it first,” he said.
Domains in .secure would still be accessible by non-compliant browsers, he said.
ARI Registry Services has been hired to manage the back-end registry, but Artemis is also building a secondary registry system for storing the DPF records, which it plans to offer to other TLD registries.
NCC plans to invest up to £6 million ($9.7 million) in Artmeis over the next 15 months, according to a press release.
Another firm, Domain Security Company, also plans to apply for .secure.

ICANN not done with TAS bug analysis

Despite sending out hundreds of notifications to new gTLD applicants today, it looks rather like ICANN’s analysis of the TLD Application System bug is not yet complete.
(MAY 10 UPDATE — in a statement today, ICANN provided significantly more information about the notification process, rendering much of the speculation originally in this post moot. Read it here.)

Demand Media mum on $18m new gTLDs investment

Demand Media has invested $18 million in new generic top-level domains, but it won’t disclose whether it has spent all of the money on application fees.
The company, which owns number two domain name registrar eNom, held its first-quarter earnings conference call this evening, during which it revealed the investment.
A roughly $18 million investment could mean as many as 100 new gTLD applications, but Demand executives refused to elaborate on its plans.
CFO Charles Hilliard said that new gTLDs are seen as a “significant strategic growth opportunity” and that Demand would provide more details upon the closure of ICANN’s application window.
As Mike Berkens has already suggested tonight on TheDomains, a massive investment in application fees seems to be the most plausible use for the money.
The fact that the whole of the investment appears to have been made in April would support this view.
But CEO Richard Rosenblatt also confirmed during the call that the company has now also entered into the registry services provider business, providing the back-end for other applicants.
It does not appear to have been particularly successful attracting clients. Rosenblatt said that Demand has created a back-end platform and “signed our first two strategic customers”.
Just two clients would put Demand at the low end of the registry service provider rankings in this first new gTLD round.
I’m aware of at least one applicant that changed its mind about partnering with the company for its application.
ICANN’s background checks on new gTLD applicants include probes into, among other things, adverse cybersquatting decisions under the UDRP.
Demand Media, as a massive domain registrant, gets hit by UDRP complaints fairly regularly, and some have said it’s lost enough to be disqualified from running a registry under ICANN’s rules.
As far as I’m aware, it’s currently an open question whether hiding UDRP losses and applications behind subsidiaries will be enough to evade these background checks.
But if Demand is prepared to pump $18 million into applications, it must have a pretty good inkling that it won’t tumble at the first hurdle.

Amsterdam accepts pre-registrations for city gTLD

The City of Amsterdam has confirmed that it has joined the ranks of major international cities applying to ICANN for a new generic top-level domain.
It has commissioned local publishing company HUB Uitgevers to manage .amsterdam, along with its technical partner SIDN, the .nl ccTLD registry.
Unusually, the project has also already started accepting pre-registrations at its official site.
The ICANN application fees are being covered by the local government, but a City of Amsterdam spokesperson said it expects to make the money back from annual royalty payments from HUB.
The famously liberal tourist destination has about 1.2 million inhabitants, according to Wikipedia.

ICANN expects up to 2,305 new gTLD applications

After months of speculation, ICANN has finally revealed how many new generic top-level domain applications it expects to receive.
The lowest amount appears to be 2,091.
That’s the number of applications in the TLD Application System when it was taken offline due to the data leakage bug on April 12, ICANN said.
Another 214 applications had been registered but not yet paid for.
That’s a potential total of 2,305 applications.
ICANN has $350 million in application fees in the bank as a result.
How many of the unpaid bids convert to full applications will be key in deciding how many evaluation batches the first gTLD round will have.
Closer to 2,091, and it’s likely to be four batches. Closer to 2,305, and we may see a fifth batch.
With Initial Evaluation expected to take five months per batch, with a possible 11 months after that for the final Extended Evaluations and string contention resolution, it could be June 2015 before the first new gTLD round is completely processed.
It remains to be seen how many unique strings have been applied for, and how many applications will be successful, but with ICANN only planning to delegate 200 to 300 new gTLDs per year, the first round is likely going to last a loooong time.

Is .xxx really that crappy?

It’s not a huge secret that the new .xxx gTLD isn’t doing as well, five months after launch, as ICM Registry would have hoped, but how does it shape up against other top-level domains?
Domain Name News earlier this week published an analysis of the top one million most-trafficked web sites, according to Alexa rankings, and found that .xxx had just 61 entries.
Per DNN reporter Mike Cohen:

We would not have thought that only 61 domains in total would be ranking inside the top 1,000,000 most visited sites in the world. That number was suppose to be exponentially higher by all accounts even a few month’s in, which we now are well into 2012, however reality says otherwise.

I’m not sure what “all accounts” DNN is referring to — possibly ICM’s marketing hype — but I thought the analysis was interesting so I thought I’d try to replicate it.
This morning I parsed today’s Alexa top million sites list and came up with the following (sortable) table.
[table id=7 /]
These are quick and dirty numbers, based on Alexa data, and my code might be wonky, so please don’t place too much faith in them.
I only looked at the “new” gTLDs introduced since 2001, as well as two mass-market ccTLDs (.co and .me) introduced over the same period.
The .co numbers do not include third-level domains under .com.co and the ccTLD’s other legacy extensions.
The “Months Active” column is the number of months since the TLD was delegated into the DNS root, measured by the date of the first registry report it filed with ICANN or the IANA (re)delegation date, not the date of general availability.
The fourth column is the number of domains divided by the number of months. It’s a fairly arbitrary measure, presented merely to give you an idea of the “success” of the TLD over time.
You could possibly, loosely, think of it as “how many domains a TLD can expect to get into the Alexa 1 Million per month”.
By that measure, .xxx isn’t doing too badly.
It’s even beating .jobs and .tel in absolute terms.

TAS bug hit over 100 new gTLD applicants

It just keeps getting worse.
ICANN’s TLD Application System security bug could have revealed file names belonging to 105 new gTLD applicants to 50 other applicants on 451 occasions, according to the organization.
With 1,268 applicants in the system, those numbers certainly fit with the “a minority of applicants” description previously given, but it still shows that the bug was widespread.
The supplied numbers are “approximate”, but ICANN said it is “continuing to review system logs and packet-level traffic to confirm how many viewings actually did occur.”
The latest news means, for example, that 50 new gTLD applicants may have had the ability to see information belonging to other applicants on average nine times each.
While the new data may not strongly suggest that the bug was deliberately exploited by any applicant(s), it’s not inconsistent with that scenario.
It could mean that one applicant saw the details of 56 others (suggesting exploitation), but it could also mean that 50 applicants saw about two third-party file names each (suggesting accidental viewing).
Without further information, it’s impossible to know.
ICANN has not revealed, and is unlikely to reveal in the short term, whether any applicant was able to view the metadata of another applicant for the same gTLD.
The organization has however started to notify affected applicants whether they were affected as victim or beneficiary, according to the latest update from chief operating officer Akram Atallah.
Atallah also revealed that TAS had 95,000 file attachments in the system when it was taken down April 12.
At an average of 75 files per TAS account, this would support the idea that, on average, each TAS account was being used to file more than one application.
ICANN still plans to wrap up the notification process before next Tuesday, May 8, but there’s no word yet on when TAS will reopen for the final five days of the application window.

Beckstrom breaks TAS bug silence, says Big Reveal could be as late as Prague

ICANN may not reveal its list of new generic top-level domain applications until as late as the last week of June, according to CEO Rod Beckstrom.
In his first interview since ICANN took its TLD Application System offline due to a security bug, Beckstrom told DI that he “hopes” to host the Big Reveal before he steps down as ICANN’s CEO.
He said he expects to have the new gTLD program back on track before he hands the reins to the organization over to his successor at the end of the ICANN 44 meeting in Prague, June 29:

I’d like to see us obviously get the technical issues resolved, notify applicants, reopen the window and publish the strings before I pass the baton in Prague. That’s not a commitment at this point in time, it’s an indication as CEO that it’s absolutely my intention to push for a timely resolution of this issue… If we can get things done sooner, then the sooner the better.

That’s two months away, a full month later than anyone was expecting.
The Big Reveal was originally scheduled for today. However, the TAS delays made this impossible. Following an ICANN update on Friday, a late-May date for the Big Reveal was looking more probable.
But Beckstrom would not commit even to the Prague date. He said:

That’s my hope as a CEO, to get these issues resolved by that time-frame and have the string reveal in that time-frame. I haven’t committed the organization, I’m indicating to you volitionally my desire as CEO and the person who’s running the organization.

He framed the issue as a blip on a nine-year process (six years of policy development, one year of outreach and application filing, and up to two years of evaluation). He said:

In the context of nine-year program, a delay of between here and Prague of a few months is undesirable, it’s not what we want to have happen, but the quality of this program is more important to everyone involved than the specific date and time. We’re all focused on quality here and not just doing things in a hurry. This program is too important.

He said he is “sympathetic” to applicants that are burning through start-up funding waiting for ICANN to sort this out, but he noted that the same concerns have been raised over the years whenever the program has previously missed a launch deadline.

We know that some parties have been very patient and we know it’s got to be frustrating right now to see any delay in the program. At the same time, I’m sure that those parties are very concerned that this be done well and that the program be reopened and administered successfully.

Beckstrom reaffirmed ICANN’s promise to notify all applicants whether or not they were affected by the TAS bug – which revealed user names and file names to other TAS users – by May 8.
But TAS will not, it seems, reopen immediately after the notifications have been sent. As well as the log audit, ICANN is also working on performance upgrades.
While Beckstrom confirmed that the plan is to open TAS for five business days, to give applicants a chance to finish uploading their applications and confirm that their data has not been corrupted, he would not say when this window is due to open.

We’re going to share more precise dates when we have them. What I can tell you precisely right now is that the key thing we’re working on is combing through this large data set we have so that the parties that were affected are notified within the seven days. When we have clarity on the next milestone in the process we’ll communicate that openly.
…
We’re still doing system testing, we’re still looking at some of the performance issues. We have a whole set of things to do and feel comfortable that we’re ready and have full internal sign off. We’ll notify you and other parties when we have that clarity. Right now we have the clarity that we’re going to get the notification done in seven days – that’s the key dating item at this time.
…
We have very strong reason to believe we understand the bug and we’ve fixed the bug, but every day that we continue to test we gain a higher level of confidence in the system that this specific issue will not reappear.

While the first report of the bug was received March 19, it was not until April 12 that ICANN managed to “connect the dots” and figure out that the problem was serious and recurring, Beckstrom said.
ICANN saw the bug show up again repeatedly on April 12, as many TAS users logged in to finish off their applications, which was why it chose to take the system down with just 12 hours to go before the filing deadline.
ICANN is currently analyzing a 500GB log containing a record of every data packet that went into and out of the TAS between January 12 and April 12, to reconstruct every user session and determine who could see what and when, Beckstrom said.
He refused to comment on whether this analysis has revealed any attempts by TAS users to deliberately exploit the bug for competitive intelligence on other applicants.
He also declined to comment on whether ICANN has discovered instances of data leakage between two applicants for the same gTLD string.
The full packet capture system was introduced following a third-party security audit of the system conducted late last year, he said.
That audit, of course, did not reveal the data leakage vulnerability that continues to delayed the program.
When I put it to him that this is precisely the kind of problem ICANN wanted to avoid, due to the confidentiality of the applications, Beckstrom played down the seriousness of the bug.

Let’s be clear here: some user names and file names were visible, not the contents of applications and not the contents of those files. I think that if that had occurred it would be an even more undesirable situation and we have no indication that that occurred.
I wouldn’t call this a security issue, I’d call this… every major software system we use has bugs in it or bugs that are discovered over time. Whether that’s our operating systems or desktop applications or specific applications, you conduct the best tests you can. You assemble a testing suite, you assemble testers, you take various methods, but there’s never a guarantee that software is bug-free. The issue is that if and when bugs are encountered you deal with them appropriately, and that’s what we’re doing right now.

But Beckstrom admitted that the problem is embarrassing for ICANN, adding that sorting out the mess is currently the top priority.

Obviously any time you have a software problem or technical problem with any program you come under enhanced scrutiny and criticism, and I think that’s understandable, that’s fair. What we’re focused on is resolving this successfully and I think ICANN has dealt with many challenges in its past successfully and we’re committed to resolve this issue professionally.
…
I should tell you that this is our top priority right now internally right now. The resolution of this issue is our number one priority, the number one issue for me as CEO, number one for most members of the executive management team and for a large part of the organization. We’re extremely focused on this.

ICANN plans to reveal how many applicants were affected by the bug at the same time as it notifies applicants, Beckstrom said. It will not publish information about who could see what, he said.
Unfortunately for applicants, it seems they will have to wait well into next week before they have any more clarity on the timetable for TAS coming back online and the application window finally closing.
With Prague now emerged as a potential deadline for the reveal, the delays could in fact be much worse than anyone was expecting.
DI PRO subscribers can read a full transcript of the 30-minute interview.

ICANN expects at least 1,268 new gTLD applications

ICANN is expecting at least 1,268 applications for new generic top-level domains, according to CEO Rod Beckstrom.
Speaking to DI at the weekend, Beckstrom said that the TLD Application System had 1,268 user accounts when registration closed March 29.
That represents a spike of over 50% from the 839 registered TAS accounts that ICANN had reported just four days earlier, March 25.
As before, there is not a one-to-one correlation between the number of TAS accounts and the number of applications. Each TAS account can be used to file up to 50 applications.
However, with each TAS slot costing $5,000, 1,268 now seems to be the minimum number of new gTLD applications we’re likely to see.
“It’s unlikely to be lower than that number,” Beckstrom said.
Read more of our interview with Beckstrom.