Could crypto solve the Whois crisis?

Could there be a cryptographic solution to some of the problems caused by GDPR’s impact on public Whois databases? Security experts think so.
The Anti-Phishing Working Group has proposed that hashing personal information and publishing it could help security researchers carry on using Whois to finger abusive domain names.
In a letter to ICANN, APWG recently said that such a system would allow registries and registrars to keep their customers’ data private, but would still enable researchers to identify names registered in bulk by spammers and the like.
“Redacting all registration records which were formerly publicly available has unintended and undesirable consequences to the very citizens and residents that electronic privacy legislation intends to protect,” the letter (pdf) says.
Under the proposed system, each registry or registrar would generate a private key for itself. For each Whois field containing private data, the data would be added to the key and hashed using a standard algorithm such as SHA-512.
For items such as physical addresses, all the address-related fields would be concatenated, with the key, before hashing the combined value.
The resulting hash — a long string of gibberish characters — would then be published in the public Whois instead of the [REDACTED] notice mandated by current ICANN policy.
Security researchers would then be able to identify domains belonging to the same purported registrant by searching for domains containing the same hash values.
It’s not a perfect solution. Because each registry or registrar would have their own key, the same registrant would have different hash values in different TLDs, so it would not be possible to search across TLDs.
But that may not be a huge problem, given that bad guys tend to bulk-register names in TLDs that have special offers on.
The hashing system may also be beneficial to interest groups such as trademark owners and law enforcement, which also look for registration patterns when tracking down abuse registrants.
The proposal would create implementation headaches for registries and registrars — which would actually have to build the crypto into their systems — and compliance challenges for ICANN.
The paper notes that ICANN would have to monitor its contracted parties — not all of which may necessarily be unfriendly to spammers — to make sure they’re hashing the data correctly.

ICANN found a zero-day hole in Adobe Connect

It’s looking like ICANN may have found a zero-day vulnerability in Adobe Connect, until recently its default collaboration tool.
The organization on Friday announced the results of a “forensic investigation” into the bug, and said it has reported its findings to Adobe, which is now “working on a software fix to address the root cause of the issue”.
If Adobe didn’t know about it, it looks rather like ICANN — or at least the unnamed member of the security advisory committee who found it — has bagged itself a zero-day.
ICANN had previously said that the glitch “could possibly lead to the disclosure of the information shared in an ICANN Adobe Connect room”.
The review found that the only person who exploited the bug was the person who discovered and disclosed it.
AC is used not only in ICANN’s public meetings but also, I understand, in closed sessions of ICANN staff, board and committees, where secret information is most likely to be shared.
After the bug was discovered, ICANN shut off the system and started using alternatives such as WebEx, to a mixed reception.
In the absence of an immediate patch from Adobe, ICANN has been testing workarounds and said it hopes to have two working ones deployed by May 3.
This would allow the tool to come back online in time for its board workshop, GDD Summit and ICANN 62, the organization said.

Root crypto rollover now slated for October

ICANN has penciled in October 11 as the new date for rolling the DNS root’s cryptographic keys, a delay of a year from its original plan.
The so-called KSK rollover will see ICANN remove the deprecated 2010 Key Signing Key, leaving only the 2017 KSK active.
The KSK acts as the “trust anchor” for DNSSEC across the whole internet.
After the rollover, any network not configured to use the latest KSK would see a service interruption.
This could mean many millions of internet users being affected, but ICANN doesn’t know the extent of the possible impact for sure.
ICANN told us in November that it knows of 176 organizations in 41 countries, fairly evenly spread across the globe, that are currently not prepared to handle the new KSK.
But its data is patchy because only a tiny number of DNS resolvers are actually configured to automatically report which KSKs they’re set up to use.
Key rollovers are recommended by DNSSEC experts to reduce the risk of brute force attacks against old keys. At the root, the original plan was to roll the keys every five years.
ICANN had named October 11 2017 as the date for the first such rollover, but this was pushed back to some time in the first quarter after ICANN became aware of the lack of support for the 2017 KSK.
This was pushed back again in December to Q3 at the earliest, after ICANN admitted it still didn’t have good enough data to measure the impact of a premature roll.
Since then, ICANN has been engaged in (not always successful) outreach to networks it knows are affected and has kicked off discussions among network operators (there’s a fairly lively mailing list on the topic) to try to gauge how cautious it needs to be.
It’s now published an updated plan that’s the same as the original plan but with a date exactly one year late — October 11, 2018.
Between now and then, it will continue to try to get hold of network operators not ready to use the new keys, but it’s not expecting to completely eliminate damage. The plan reads:

Implicit in the outreach plan is the same assumption that the community had for the earlier (postponed) plan: there will likely be some systems that will fail to resolve names starting on the day of the rollover. The outreach will attempt to minimize the number of affected users while acknowledging that the operators of some resolvers will be unreachable.

The plan is open for public comment and will require the assent of the ICANN board of directors before being implemented. You have until April 2 to respond.

Research finds homograph attacks on big brands rife

Apparent domain name homograph attacks against major brands are a “significant” problem, according to research from Farsight Security.
The company said last week that it scanned for such attacks against 125 well-known brands over the three months to January 10 and found 116,113 domains — almost 1,000 per brand.
Homographs are domains that look like other domains, often indistinguishable from the original. They’re usually used to phish for passwords to bank accounts, retailers, cryptocurrency exchanges, and so on.
They most often use internationalized domain names, mixing together ASCII and non-ASCII characters when displayed in browsers.
To the naked eye, they can look very similar to the original ASCII-only domains, but under the hood they’re actually encoded with Punycode with the xn-- prefix.
Examples highlighted by Farsight include baŋkofamerica.com, amazoṇ.com and fàcebook.com
Displayed as ASCII, those domains are actually xn--bakofamerica-qfc.com, xn--amazo-7l1b.com and xn--fcebook-8va.com.
Farsight gave examples including and excluding the www. subdomain in a blog post last week, but I’m not sure if it double-counted to get to its 116,113-domain total.
As you might imagine, almost all of this abuse is concentrated in .com and other TLDs that were around before 2012, judging by Farsight’s examples. That’s because the big brands are not using new gTLDs for their primary sites yet.
Farsight gave a caveat that it had not generally investigated the ownership of the homograph domains it found. It’s possible some of them are defensive registrations by brands that are already fully aware of the security risk they could present.

Second delay for domain security key rollover

ICANN has decided to delay changing the security keys to the DNS for the second time.
The “KSK Rollover” had been rescheduled from October 11 to some time in the first quarter 2018, but that will no longer happen. We’re now looking at Q3 at the earliest.
“We have decided that we do not yet have enough information to set a specific date for the rollover,” VP of research Matt Larson said in a blog post. “We want to make clear, however, that the ICANN org is committed to rolling the root zone KSK”.
The root KSK, or Key Signing Key, is the cryptographic key pair at the very top of the security hierarchy specified by DNSSEC, the security extension for DNS.
The current, first-ever, root KSK has been in operation since 2010, but ICANN’s policy is to roll it every five years or so.
The October date was delayed after newly available data showed that hundreds of DNS resolvers were still only configured to use the 2010 keys and not the 2017 keys that have already been deployed in tandem.
This would mean a rollover would cut off access to DNSSEC-signed zones to potentially millions of internet users.
ICANN found that 4% of the 12,000 DNSSEC-validating resolvers — roughly 500 IP addresses — it surveyed in September were not ready for KSK-2017.
Larson told us last month that at least 176 organizations in 41 countries were affected.
Since the first delay, ICANN has been trying to contact the owners of the 500 incompatible IP addresses but has run into some serious problems, Larson blogged.
First, a significant number of these addresses are dynamically allocated (such as to home broadband hubs) meaning tracking down the owners of the misconfigured devices would be next to impossible. Others were forwarding DNS queries on behalf of other devices, creating a similar problem.
Additionally, it seems ICANN has still not received responses from owners of 80% of the affected IP addresses.
Due to the lack of reliable data, it’s difficult for ICANN to figure out how many users’ internet access will be affected by a rollover.
The threshold called for by current policy is about 20 million people.
So ICANN has delayed the event to some point after Q1. Larson wrote that the organization will publish a plan on January 18 which will be open for public comment and discussed at the ICANN 61 meeting in Puerto Rico next March.
A final plan is not expected until ICANN 62, which happens in late June, so Q3 would be the earliest the rollover could actually occur.
Larson encouraged anyone interested in discussing the plan to join this mailing list.

Davies named new IANA boss

Kim Davies has been named the new head of IANA.
ICANN said today that he’s been promoted from his role as director of technical services to VP of IANA services and president of Public Technical Identifiers, the company that manages the IANA functions.
With ICANN since 2005, he replaces Elise Gerich, who announced her departure, originally scheduled for October, back in April.
Gerich has been IANA’s top staffer since 2010 and was PTI’s first president.
IANA is responsible for overseeing the top-level domain database, as well as the allocation of IP address blocks and protocol numbers.
Starting January 1, Davies will be in the top spot when ICANN executes the first-ever rollover of the root system’s most important DNSSEC keys, due to delays.

Up to 20 million people could get broken internet in domain security rollover

Twenty million people losing access to parts of the internet is considered an acceptable level of collateral damage for ICANN’s forthcoming DNS root security update.
That’s one of a number of facts and figures to emerge from recent updates from the organization, explaining its decision to delay the so-called “KSK rollover” from October 11 to some time in the first quarter next year.
The rollover will see a new Key Signing Key, used as the trust anchor for all DNSSEC-signed domains, replace the seven-year-old original.
DNSSEC protects internet users and registrants from domain-based man-in-the-middle attacks. It’s considered good practice to roll keys at each level of the DNS hierarchy periodically, to reduce the risk of successful brute-force attacks.
The root KSK update will affect hundreds of millions of people who currently use DNSSEC-compatible resolvers, such as Google DNS.
ICANN delayed the rollover after it, rather fortuitously, spotted that not all of these resolvers are configured to correctly handle the change.
The number of known incompatible servers is quite small — only about 500 of the 11,982 DNSSEC-using recursive servers initially surveyed (pdf). That represents only a very small minority of the world’s internet users, as most are not currently using DNSSEC.
Subsequent ICANN research, presented by principal researcher Roy Arends at ICANN 60 last week, showed that:

• There are currently about 4.2 million DNS resolvers in the world.
• Of those, 27,084 are configured to tell the root servers which KSKs they support (currently either the KSK-2011 or KSK-2017).
• Of those, 1,631 or 6.02% do not support KSK-2017

It was only possible to survey servers that have turned on a recent update to DNS software such as BIND and Unbound, so the true number of misconfigured servers could be much higher.
Matt Larson, ICANN’s VP of research, told DI that ICANN has identified 176 organizations in 41 countries that are currently not prepared to handle the new KSK. These organizations are fairly evenly spread geographically, he said.
Since making the decision to delay the rollover, ICANN has hired a contractor to reach out to these network operators to alert them to potential problems.
ICANN’s CEO Goran Marby has also been writing to telecommunications regulators in all countries to ask for assistance.
After the rollover, people using an incompatible resolver would be unable to access DNSSEC-signed domains. Again, that’s still quite a small minority of domains — there are only about 750,000 in .com by some accounts and apparently none of the top 25 site support it.
ICANN could roll back the change if it detects that a sufficiently large number of people are negatively affected, but that number turns out to be around 20 million.
According to its published rollover plan:

Rollback of any step in the key roll process should be initiated if the measurement program indicated that a minimum of 0.5% of the estimated Internet end-user population has been negatively impacted by the change 72 hours after each change has been deployed into the root zone.

According to InternetWorldStats, there were around 3,885,567,619 internet users in the world this June. It’s very likely more people now.
So a 0.5% threshold works out to about 19 million to 20 million people worldwide.
Larson agreed that in absolute terms, it’s a big number.
“The overall message to take away from that number, I suggest, is that a problem would have to be pretty serious for us to consider rolling back,” Larson, who was not on the team that came up with the threshold, said.
“I think that’s a reasonable position considering that, in the immediate aftermath of the rollover, there are two near-immediate fixes available to any operator experiencing problems: update their systems’ trust anchors with the new key or (less desirable from my perspective but still effective) simply disable DNSSEC validation,” he said.
He added that the 0.5% level is not a hard and fast rule, and that ICANN could be flexible in the moment.
“For example, if when we roll the key, we find out there’s some critical system with a literal life or death impact that is negatively affected by the KSK roll, I think I can pretty confidently state that we wouldn’t require the 0.5% of Internet user threshold to be met before rolling back if it looked like there would be a significant health and safety risk not easily mitigated,” he said.
The chances of such an impact are very slim, but not impossible, he suggested.
It’s not ICANN’s intention to put anyone’s internet access at risk, of course, which is why there’s a delay.
ICANN’s plan calls for any rollover to happen on the eleventh day of a given calendar quarter, so the soonest it could happen would be January 11.
Given the complexity of the outreach task in hand, the relative lack of data, and the holiday periods approaching in many countries, and ICANN’s generally cautious nature, I’d hazard a guess we might be looking at April 11 at the earliest instead.

Verisign and Afilias testing Whois killer

Verisign and Afilias have become the first two gTLD registries to start publicly testing a replacement for Whois.
Both companies have this week started piloting implementations of RDAP, the Registration Data Access Protocol, which is expected to usurp the decades-old Whois protocol before long.
Both pilots are in their very early stages and designed for a technical audience, so don’t expect your socks to be blown off.
The Verisign pilot offers a web-based, URL-based or command-line interface for querying registration records.
The output, by design, is in JSON format. This makes it easier for software to parse but it’s not currently very easy on the human eye.
To make it slightly more legible, you can install a JSON formatter browser extension, which are freely available for Chrome.
Afilias’ pilot is similar but does not currently have a friendly web interface.
Both pilots have rudimentary support for searching using wildcards, albeit with truncated result sets.
The two new pilots only currently cover Verisign’s .com and .net registries and Afilias’ .info.
While two other companies have notified ICANN that they intend to run RDAP pilots, these are the first two to go live.
It’s pretty much inevitable at this point that RDAP is going to replace Whois relatively soon.
Not only has ICANN has been practically champing at the bit to get RDAP compliance into its registry/registrar contracts, but it seems like the protocol could simplify the process of complying with incoming European Union privacy legislation.
RDAP helps standardize access control, meaning certain data fields might be restricted to certain classes of user. Cops and IP enforcers could get access to more Whois data than the average blogger or domainer, in other words.
As it happens, it’s highly possible that this kind of stratified Whois is something that will be legally mandated by the EU General Data Protection Regulation, which comes into effect next May.

Telco billed $2.7 million for failing to renew domain

A US telecommunications provider has agreed to pay $2.7 million after an emergency service went offline because it forgot to renew a domain name.
According to the Federal Communications Commission, Utah-based Sorenson Communications saw its “video relay service” go offline for two days in June 2016 after a domain was not renewed.
The service is basically a 911 emergency calls replaced designed for people with hearing or speech problems.
The settlement (pdf) describes the scenario like this:

Sorenson.com is a domain name Sorenson uses to provide access to SVRS. On the morning of June 6, 2016, Sorenson experienced a VRS Service Interruption that resulted from a preventable, internal operational failure.10 This failure led the domain registration for Sorenson.com to expire and be deactivated. After the deactivation occurred and before Sorenson could correct the situation, some Internet Service Providers (ISPs) updated their records to reflect that the domain was expired. If a user’s ISP updated its records while the domain was shown as expired, that user could not make or receive calls routed through Sorenson.com — including VRS, 911, Dial-Around, and Point-to-Point calls — during at least part of the outage.
Upon discovery of the VRS Service Interruption, Sorenson took immediate steps to correct the problem and notify callers. Once the domain name was reactivated, each caller’s ISP had to take certain steps to ensure that calls were routed through Sorenson.com. To expedite this process, Sorenson reached out to multiple large ISPs, such as Verizon and Comcast, and posted information about the VRS Service Interruption on its website11 and social media outlets. The VRS Service Interruption continued for some callers through the morning of June 8, 2016.

The $2.7 million charge is a repayment of a reimbursement of the same amount paid out by the nation Telecommunications Relay Service Fund.
Sorenson has agreed to pay a more modest $252,000 in formal penalties to the FCC for its indiscretion.
Still, as domain renewal fumbles go, it’s got to be one of the biggest facepalms we’ve seen for a while.

New gTLDs still a crappy choice for email — study

New gTLDs may not be the best choice of domain for a primary email address, judging by new research.
Over 20% of the most-popular web sites do not fully understand email addresses containing long TLDs, and Arabic email addresses are supported by fewer than one in 10 sites, a study by the Universal Acceptance Steering Group has found.
Twitter, IBM and the Financial Times are among those sites highlighted as having only partial support for today’s wide variety of possible email addresses.
Only 7% of the sites tested were able to support all types of email address.
The study, carried out by Donuts and ICANN staff, looked at 749 websites (in the top 1,000 or so as ranked by Alexa) that have forms for filling in email addresses.
On each site, seven different email addresses were input, to see whether the site would accept them as valid.
The emails used different combinations of ASCII and Unicode before the dot and mixes of internationalized domain name and ASCII at the second and top levels.
These were the results (click to enlarge or download the PDF of the report here):

The problem with these numbers, it seems to me, is the lack of a control. There’s no real baseline to judge the numbers against.
There’s no mention in the paper about testing addresses that use .com or decades-old ccTLDs, which would have highlighted web sites that with broken scripts that reject all emails.
But if we assume, as the paper appears to, that all the tested web sites were 100% compliant for .com domains, the scores for new gTLDs are not great.
There are currently over 800 TLDs over four characters in length, but according to the UASG research 22% of web sites will not recognize them.
There are 150 IDN TLDs, but a maximum of 30% of sites will accept them in email addresses.
When it comes to right-to-left scripts, such as Arabic, the vast majority of sites are totally hopeless.
UASG dug into the code of the tested sites when it could and found that most of them use client-side code — JavaScript processing a regular expression — to verify addresses.
A regular expression is complex bit of code that can look something like this: /^.+@(?:[^.]+\.)+(?:[^.]{2,})$
It’s not every coder’s cup of tea, but it can get the job done with minimal client-side resource overheads. Most coders, the UASG concludes, copy regex they found on a forum and maybe tweak it a bit.
This should not be shocking news to anyone. I’ve known about it since 2009 or earlier when I first started ripping code from StackOverflow.
However, the UASG seems to be have been working on the assumption that more sites are using off-the-shelf software libraries, which would have allowed the problem to be fixed in a more centralized fashion.
It concludes in its paper that much greater “awareness raising” needs to happen before universal acceptance comes closer to reality.