security Red Alert: ICANN Working Group Wants To Make It Easier To Hijack Domain Names

[GeorgeK]

There’s an important ICANN [public comment period that ends on Tuesday August 2, 2022](https://www.icann.org/en/public-comment/proceeding/initial-report-on-the-transfer-policy-review-21-06-2022) regarding the transfers policy. I haven’t finished my own comments yet, but I thought it important to sound the alarm, as only 2 4 comments have been submitted to date.

Andrew of DNW.com had sounded the alarm about this in June, but so far few have noticed! Read more here:

https://freespeech.com/2022/07/30/r...nts-to-make-it-easier-to-hijack-domain-names/

Edited to update the number of comments

 

[bmugford]

ICANN is extending the deadline by (2) weeks.

I just got the following email -

Dear Mr. Mugford,

Thank you for your request regarding extension of the public comment period.

I am writing to let you know that the PDP leadership team has extended the public comment period by two weeks. The public comment page (https://www.icann.org/en/public-com...port-on-the-transfer-policy-review-21-06-2022) will soon be updated to reflect the new close date: 16 August.

Thank you for your interest in this public comment opportunity.

Kind regards,
Emily Barabas

 

[GeorgeK]

I got that email too. I told them, in very clear terms, that 2 weeks just isn't enough. I'm not going to jeopardize my health to meet their unrealistic deadlines.

It took a huge investment in time just to write those 2 blog posts, which are only a small subset of the report. Now extrapolate that to the 22 recommendations, and all the sub-questions along the way --- I did the math (my company owns Math.com after all!), and mid-September I was I need (I didn't ask for some 'desire' --- I asked for what I needed).

 

[redemo]

From every mountainside, let freedom ring.

 

[DomainNature]

Why not make in such a way? Before you can unlock to transfer domains you would receive a SMS code, then you can transfer domains without approval.
This would be good feature, I m tired to approve domains, imagine when transferring more than 1K of domains, it's a pain in the boot.

 

[GeorgeK]

Why not make in such a way? Before you can unlock to transfer domains you would receive a SMS code, then you can transfer domains without approval.
This would be good feature, I m tired to approve domains, imagine when transferring more than 1K of domains, it's a pain in the boot.

What happens if the AuthInfo Code (will in the future be called TAC) is compromised AFTER you receive it from the current registrar, but before you've used it at the new registrar? (for example, if your PC had malware/virus, and the attacker grabbed the AuthInfo code without your knowledge) Without the ACK/NACK, the attacker's transfer would go through immediately, and you wouldn't have had the opportunity to NACK (reject) the transfer (if you saw it was going to an unintended registrar; e.g. you wanted it to go to Registrar A in the USA, but the ACK/NACK email says that "Registrar B" in China/Russia has made the request. If you've designed your security well, you'd have used a DIFFERENT email for the ACK/NACK email than the SMS, or for your control panel access. [i.e. you should have a different email address for the registrar account than the one in the WHOIS for the registrant, so that a compromise of one doesn't affect everything]

You'd be in bad shape if someone did a SIM SWAP or stole your SMS phone number, and did an unauthorized transfer that wouldn't be able to be ACK/NACK via the email.

If you're buying or selling a domain name, the ACK/NACK is also potentially a very important security protection, to ensure a transfer to a new registrar is to the right one (and that it's not stolen). e.g. if I sell Example.com to Jane, one way to do a deal (lots of different ways, including escrow, but I'll use this example) would be to have Jane send me the money first, and then I give her the Auth Info code, so she can transfer it to her preferred registrar. Suppose it's at Tucows now, and she wants to move it to GoDaddy. She takes the Auth Info code to GoDaddy, and I should then see (within 20 minutes) an ACK/NACK email from Tucows in my email. It'll say which registrar it's going to ---- if it's not GoDady, but instead some Chinese/Russian registrar, then maybe Jane got hacked, or maybe she's trying to scam me (i.e. pretend that she never got the domain, so she can dispute the deal). So, having the ACK/NACK email is critical, as a safety mechanism.

Perhaps a divorcing couple has someone using a shared PC (with password manager) to login to the registrar, and check the SMS code while the true owner is sleeping, to take the domains before they leave. If the ACK/NACK email was kept more secure (separate PC at the office, or security key in a safety deposit box, etc.), one can be saved.....

Lots of different ways domains get stolen....and the report didn't really study them all properly or systematically.

I understand your pain, though, about it being tough for bulk transfers. They should fix things by allowing a single AuthInfo code for a GROUP of domains, rather than doing it one at a time. But, these obvious things are beyond ICANN, it seems...it would be rather simple to design/implement. It's all politics, though, because registrars that lose a lot of domains won't agree to the policy, because it would make it easier to leave them....and registrants are basically ignored by everyone at ICANN, as we've seen time after time after time. (it still makes sense to make comments, though --- don't let them win by default by giving up completely!)

They really should do a complete overhaul of the transfer system. I'd love to see a "before" and "after" of the WHOIS, for example, to ensure that it's all correct (i.e. more than just the new registrar, but the new registrant too). [I think some ccTLDs do this] I know that registrars are reluctant to do this due to GDPR, etc., but they could certainly do it if the registrant at the gaining registrar consents. [and they don't even need the info to be passed to the losing registrar --- all you'd need is a link from the old registrar to somewhere in the new registrar, so that the new registrar could display the proposed new WHOIS to the old owner]. If the new owner didn't want to provide that consent, the old owner could make up their own mind whether to accept/reject the transfer, depending on their risk tolerance, what they put into their written contract, the value of the domain name, or other factors.

 

[lambo.com]

I got that email too. I told them, in very clear terms, that 2 weeks just isn't enough. I'm not going to jeopardize my health to meet their unrealistic deadlines.

It took a huge investment in time just to write those 2 blog posts, which are only a small subset of the report. Now extrapolate that to the 22 recommendations, and all the sub-questions along the way --- I did the math (my company owns Math.com after all!), and mid-September I was I need (I didn't ask for some 'desire' --- I asked for what I needed).

What a fantastic assemblage of domains you have ! Well done

 

[GeorgeK]

Another option, which I just thought of after a discussion with someone.

1. at the time that the TAC is generated (or even better, set it at an account level at the registrar, which can only be modified by an out-of-band verification, and with a **delay** if changed to a weaker state, for safety), give the registrant the choice, whether they want the transfer to be "SuperFast" (or you can call it "Normal"), or
"SuperSecure" (Slower).

2. If they pick "SuperFast", there'd be no "ACK/NACK step after the TAC is used at the gaining registrar --- transfer would complete immediately (what the new working group recommended).

3. If they pick "SuperSecure", there'd be the current "ACK/NACK" step after the TAC is used at the gaining registrar -- which registrars already have code for --- it's what we have now! This is all automated, too, so it's super-trivial and cheap. [This has greater security in the event the TAC is compromised after it's generated.]

There'd need to be a few pieces of extra code at the registrar/registry to handle the different branches, depending on the path initially set. [but, since the report already proposed a change, they'd be writing new code anyhow!]

So, we can have the "best of both worlds" -- I think it'd be essential for the security-conscious registrant to be able to make a setting that ALL of their transfers are "SuperSecure" by default, which can't be changed except via out-of-band communications, etc. That preserves my multi-factor security, and also protects against rogue employees
somewhat, or if the registrar gets hacked, to some degree.[i.e. if an attacker can override that setting without my consent by breaching the registrar, they can boost their chances of a successful theft]

Thing is, there's always going to be scenarios where a rogue employee at a registrar does something, or there's a 0-day Linux vulnerability that hacks the registrar, or there are some other scenarios where the ACK/NACK saves one's bacon....so I'm reluctant to give it up easily. (not all scenarios; i.e. the ACK/NACK step might get hacked at the registrar too -- in an ideal security design, strict access control would be taken into account, to minimize the odds of that kind of attack, with lots of logging, too)

 

[twiki]

I think this change might impact high value portfolios / domains more.

The temptation to do something bad like domain theft increases with domain worth obviously.

(although any investor can be affected of course)

 

[GeorgeK]

I think this change might impact high value portfolios / domains more.

The temptation to do something bad like domain theft increases with domain worth obviously.

(although any investor can be affected of course)

If you're just a domainer, buying/selling undeveloped domains, It would undermine the entire industry -- Gresham's law ("bad money drives out good"). If there are more stolen domains, then all asset prices would suffer.

And actually, while it seems at first glance to harm higher value domains more, it actually also harms the less valuable domains substantially, even higher in proportion!

e.g. if you have to factor in a probability that a domain name is stolen, and the ensuing LEGAL COSTS to rectify things, that's a friction that imposes a higher relative value on the less valuable domain.

So, if there's a 1% chance the domain is stolen, and the legal costs and trouble to "fix things" are $25,000, then look what happens.

A rational buyer will need to lower the value of the transaction by 0.01 x $25,000 = $250, on average.

If the name is worth $1000 (if you know 100% it's not stolen), then it would drop to $750. That's a 25% drop.

For a $1 million domain, the same $250, on average!

When an actual theft takes place, the $1 million domain owner would definitely spend the $25K to fix things in the courts.

When the $1000 domain turns out to be stolen, both sides will probably have to eat it! (i.e. the frictions are too great to even pursue it in the courts).

But, wait, there's MORE! What about developed domains! There are many domains which are developed, and can get stolen. You have email addresses that are attached to them, that are linked to bank accounts, crypto, etc. These need not be obvious high value domains (as pure domains), but they're high value targets because of the damage that can take place when they're hijacked. And when those are transferred between registrars, they need to maintain security (basically, under the proposal, security drops to ZERO once the TAC is provisioned -- you're on your own).

 

[GeorgeK]

And if you think thieves aren't creative, or patient, think again. e.g. a fake court order to trick a registrar into transferring a domain:

https://www.vice.com/en/article/qj8833/dark-fail-fake-court-order-dark-web-markets

Think about corporations, whose networks are penetrated and where RAT trojans are installed. Then, they sit and wait for opportunities. You can have all the fancy registry lock protection in place. Then one day you decide that you want to move from CSC to MarkMonitor, for example (high value places). You *have* to remove the security lock at that point, generate the TAC, and at that point it becomes vulnerable. Because a transfer would complete immediately (without the NACK/ACK protection step), if the attacker moves faster than you do, they win! (and then enormous damage can take place)

I don't want to point out every scenario, but don't think because you perceive your domains as not valuable, that this doesn't affect you. Maybe your own domain doesn't ever get stolen, but someone else's will, and you might be a customer or have data with that provider (e.g. when credit bureaus, or other famous hacks take place).

If they make a way to move a domain name from CSC to MarkMonitor while maintaining the security lock (and only allowing a transfer between those two places), I'll shut up. But, that's not what's in the report!

 

[GeorgeK]

Elliot Silver had an interesting article about a negative review on Dan.com:

https://domaininvesting.com/negative-reviews-impact-you-too/

"Even though negative reviews on a domain name sales platform don’t have a direct impact on my company, they do have an impact on my bottom line."

This is also what will happens when you undermine security and trust of the entire domain ecosystem, in the name of 'speed'. [It's like Facebook's "move fast and break things", I suppose]

Folks don't always see or understand all the interrelationships, how one seemingly minor thing might have ripple effects that do eventually have an impact on them!

 

[redemo]

Thank you for taking action for us on this important matter.

 

[GeorgeK]

Here's a quick post with a metaphor, to help understand what's going on:

https://freespeech.com/2022/08/03/die-hard-opposition-to-reduced-security-for-domain-name-transfers/

With the ICANN proposal to eliminate the ACK/NACK safeguard, it's essentially transform a secure asset protected by 7 layers of security, into an inherently insecure 'bearer bond' which has zero security remaining!

 

[Recons.Com]

Don't fix what ain't broken.

The process works fine as of now. If I don't do anything, the name transfers in 5 days which is normally enough to notice things going wrong. If I want to expedite, it is near-instant at reputable registrars. You just need to go into your control panel and confirm the transfer (or via email).

If seller can cancel the transfer post transaction, that is going to open the gates of hell. How will even escrow operate? Buyer confirms he got the name, escrow transfers money to seller, then seller goes and cancels the transaction?

Basically, people will be afraid to buy any name, expensive or cheap. They already have hard time trusting all the aftermarket selling platforms. With this, it becomes riskier. Especially, if few horror stories hit the media.

And, of course, if ICANN goes ahead with this, I do hope their asses get sewed for billions of dollars and a new organization is created to take over domains and all current management is disallowed from taking positions in domain industry.

 

[GeorgeK]

Elliot Silver had a blog post today:

https://domaininvesting.com/ica-submits-comment-to-icann-on-transfer-policy/

which links to the ICA's submission.

 

[GeorgeK]

I started a new thread at:

https://www.namepros.com/threads/making-domain-name-transfers-more-secure.1280493/

with a topic of "Making Domain Name Transfers More Secure", to highlight some new ideas in a new blog post.

 

[GeorgeK]

I just published a new article:

https://freespeech.com/2022/08/11/xprize-style-competition-to-improve-domain-name-transfer-security/

calling for new ideas on domain name security via an open "Call for Papers" or XPRIZE-style competition.

 

[GeorgeK]

I also started a new thread with my company's final comment submission to ICANN, see:

https://www.namepros.com/threads/me...ers-final-call-for-comments-to-icann.1280904/

There are just 2 days left to submit comments (deadline is Tuesday August 16, 2022 @ 23:59 UTC).

 

[GeorgeK]

There's a public session tonight (10:30 pm Eastern time) at ICANN75 with that Transfer Policy working group.

https://freespeech.com/2022/09/16/i...rking-group-is-friday-at-1030pm-eastern-time/

One can participate remotely via Zoom.

 

[GeorgeK]

I just made a new blog post:

https://freespeech.com/2022/10/09/r...-group-regarding-domain-name-transfer-issues/

responding to a post on the ICANN working group's mailing list concerning the domain name transfer issues (since I've not been invited to join the working group, I can't respond on their mailing list, so I made it a public response).