GMO Registry is to offer .shop domain registrants a free one-year SSL certificate with every purchase.
The company said yesterday that the deal, made via sister certificate company GMO GlobalSign, should be in place by the end of the month.
The certs on offer appear to be the of low-end “Domain Validation” variety.
Nevertheless, GlobalSign usually sells them for over $150 per year, many times more expensive than .shop domains themselves.
Popular registrars are currently selling .shop names from $10 to $25.
There are about 90,000 domains in .shop’s zone file today.
That’s a goodish volume by new gTLD standards, but probably not good enough to help GMO recoup the $41.5 million it paid for .shop at auction any time soon.
Upsell opportunities such as the SSL offer, assuming they get any uptake, may help accelerate its path to breakeven.
The proposed gTLDs .home and .corp create risks to the internet comparable to the Millennium Bug, which terrorized a burgeoning internet at the turn of the century, and should be rejected.
Meanwhile, every other gTLD that has been applied for in the current round could be delayed by months in order to mitigate the risks they pose to internet users.
These are the conclusions ICANN has drawn from Interisle Consulting’s independent study into the problems that could be caused when new gTLDs clash with widely-used internal naming systems.
The extensive study, which drew on 8TB of traffic data provided by 11 of the 13 DNS root server operators, is 197 pages long and absolutely fascinating. It was published by ICANN today.
As Interisle CEO Lyman Chapin reported at the ICANN meeting in Durban a few weeks ago, the large majority of TLDs that have been applied for in the current round already receive large amounts of error traffic:
Of the 1,409 distinct applied-for TLD strings, 1,367 appeared at least once in the 2013 DITL [Day In the Life of the Internet] data with the string at the TLD position.
We’ve previously reported on the volume of queries new gTLDs get, such as the fact that .home gets half a billion hits a day and that 3% of all requests were for strings that have been applied for in the current round.
The extra value in Interisle’s report comes when it starts to figure out how many end points are making these requests, and how many second-level domains they’re looking for.
These are vitally important factors for assessing the scale of the risk of each TLD.
Again, .home and .corp appear to be the most dangerous.
Interisle capped the number of second-level domains it counted in the 2013 data at 100,000 per TLD per root server — 1,100,000 domains in total — and .home was the only TLD string to hit this cap.
Cisco Systems’ proposed .cisco TLD came close, failing to hit the cap in only one of the 11 root servers providing data, while .box and .iinet (both also used widely on home routers) hit the cap on at least one root server.
The lowest count of second-level domains of the 35 listed in the report came from .hsbc, the bank brand, but even that number was a not-inconsiderable 2,000.
Why are these requests being made?
Surprisingly, interactions between a security feature in Google’s own Chrome browser and common residential routers appear to be the biggest cause of queries for non-existent TLDs.
That issue, which impacts mainly .home, accounts for about 46% of the requests counted, according to the report.
In second place, with 15% of the queries, are requests for real domain names that appear to have had a non-existent TLD — again, usually .home — appended by a residential router or cable modem.
Apparent typos — where a user enters a URL but forgets to type the TLD — were a relatively small percentage of requests, coming in at under 1% of queries.
The study also found that bad requests come from many thousands of sources. This table compares the number of requests to the number of sources.
|2013 Rank||String||Count (thousands)||Prefix Count (thousands)|
The “Count” column is the number, in thousands, of requests for each TLD string. The “Prefix Count ” column refers to the number of sources providing this traffic, counted by the /24 IP address block (each of which is up to 256 potential hosts).
As you can see, there’s not necessarily a correlation between the number of requests a TLD gets and the number of people making the requests — .google gets queried by more sources than the others, but it’s only ranked 24 in terms of overall query volume, for example.
Interisle concluded from all this that .corp and .home are simply too dangerous to delegate, comparing the problem to the year 2000 bug, where a global effort was required to make sure software could support the four-digit dating scheme required by the turn of the century.
Here’s what the report says about .corp:
users could be taken to the wrong web site (and possibly be exposed to phishing attacks) or told that web sites do not exist when they do, depending on how the .corp TLD is resolved. A corporate mail system might attempt to deliver email to the wrong server, and this could expose sensitive or confidential information to someone who was not supposed to receive it. In essence, everything deployed in the private network would need to be checked.
There are no easy solutions to these problems. In an ideal world, the operators of these private networks would get a timely notification of the new TLD’s delegation and then take action to address these issues. That seems very improbable. Even if ICANN generated sufficient publicity about the new TLD’s delegation, there is no guarantee that this will come to the attention of the management or operators of the private networks that could be jeopardized by the delegation.
It seems reasonable to estimate that the amount of effort involved might be comparable to a wholesale renumbering of the internal network or the Y2K problem.
It notes that applied-for TLDs such as .site, .office, .group and .inc appear to be used in similar ways to .home and .corp, but do not appear to present as broad a risk.
To be clear, the risk we’re talking about here isn’t just people typing the wrong things into browsers, it’s about the infrastructure on many thousands of private networks starting to make the wrong security assumptions about domain names.
ICANN, in response, has outlined a series of measures sure to infuriate many gTLD applicants, but which are consistent with its goal to protect the security and stability of the internet.
They’re also consistent with some of the recommendations put forward by Verisign over the last few months in its campaign to show that new gTLDs pose huge risks.
First, .corp and .home are dead. These two strings have been categorized “high risk” by ICANN, which said:
Given the risk level presented by these strings, ICANN proposes not to delegate either one until such time that an applicant can demonstrate that its proposed string should be classified as low risk
Given the Y2K-scale effort required to mitigate the risks, and the fact that the eventual pay-off wouldn’t compensate for the work, I feel fairly confident in saying the two strings will never be delegated.
Another 80% of the applied-for strings have been categorized “low risk”. ICANN has published a spreadsheet explaining which string falls into which category. Low risk does not mean they get off scot-free, however.
First, all registries for low-risk strings will not be allowed to activate any domain names in their gTLD for 120 days after contract signing.
Second, for 30 days after a gTLD is delegated the new registries will have to reach out to the owners of each IP address that attempts to query names in that gTLD, to try to mitigate the risk of internal name collisions.
This, as applicants will no doubt quickly argue, is going to place them under a massive cost burden.
But their outlook is considerably brighter than that of the remaining 20% of applications, which are categorized as “uncalculated risk” and face a further three to six months of delay while ICANN conducts further studies into whether they’re each “high” or “low” risk strings.
In other words, the new gTLD program is about to see its biggest shake-up since the GAC delivered its Advice in Beijing, adding potentially millions in costs and delays for applicants.
ICANN’s proposed mitigation efforts are now open for public comment.
One has to wonder why the hell ICANN didn’t do this study two years ago.
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.
A couple of weeks back, I emailed PR folk at Microsoft, Mozilla, Google and Opera, asking if they had any plans to provide native support for DNSSEC in their browsers.
As DNS uber-hacker Dan Kaminsky and ICANN president Rod Beckstrom have been proselytizing this week at the Black Hat conference, support at the application layer is the next step if DNSSEC is to quickly gain widespread traction.
The idea is that one day the ability to validate DNSSEC messages will be supported by browsers in much the same way as SSL certificates are today, maybe by showing the user a green address bar.
CZ.NIC has already created a DNSSEC validator plugin for Firefox that does precisely that, but as far as I can tell there’s no native support for the standard in any browser.
These are the responses I received:
Mozilla: “Our team is heads down right now with Firefox 4 beta releases so unfortunately, I am not going to be able to get you an answer.”
Microsoft: “At this stage, we’re focusing on the Internet Explorer 9 Platform Preview releases. The platform preview is a developer and designer scoped release of Internet Explorer 9, and is not feature complete, we will have more to share about Internet Explorer 9 in the future.”
Google: No reply.
Opera: No reply.
In 11 years of journalism, Apple’s PR team has never replied to any request for information or comment from me, so I didn’t bother even trying this time around.
But the responses from the other four tell us one of two things:
- Browser makers haven’t started thinking about DNSSEC yet.
- Their PR people were just trying to brush me off.
I sincerely hope it’s the former, otherwise this blog post has no value whatsoever.
VeriSign’s $1.3 billion sale of its SSL business to Symantec yesterday means not only that the company will be almost entirely focussed on domain names, but also that it will no longer “sign” anything.
The word “VeriSign” will cease to describe what the company does, so will it change its name?
The idea could make sense, given that the services Symantec bought are all about trusting the VeriSign brand, and Symantec has acquired certain rights to use that brand.
Under the deal, Symantec is allowed to use the VeriSign name in authentication services such as the VeriSign Trust Seal. The company plans to incorporate “VeriSign” into a new Symantec trust logo.
VeriSign boss Mark McLaughlin said on a conference call yesterday that Symantec is buying certain VeriSign trademarks, such as Thawte and GeoTrust, but that VeriSign will stay VeriSign.
Symantec will be able to use the VeriSign brand in its logos for a “transition period of time over a number of years”, McLaughlin said.
On the one hand, there’s a potential for a certain degree of confusion that might persuade VeriSign to brand itself afresh. On the other, corporate rebranding is not cheap.
I suppose, if it does choose to rename itself, it had better hope that its first choice of .com is available.