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]

What a terrible idea. It would make it far easier when it comes to domain theft.

Brad

 

[GeorgeK]

Agreed, these guys are complete idiots. What were they thinking?

They pretend that they're the "masters of the universe", knowing better than everybody else, but their idiotic ideas just embarrass themselves.

 

[GeorgeK]

For the (few) folks who read the blog post right after I posted it, I made a couple of updates, including some stats on Canadian phone number thefts (given they'd be similar in nature to domain name thefts).

 

[GeorgeK]

I updated the post again, to point out how last year it was "unreasonable" to expect comments to be worked on in July! See statement by Mike Rodenbaugh:

https://mm.icann.org/pipermail/gnso-tpr/2021-August/000112.html

I added that to the "P.P.P.S" (!!) section at the end.

 

[Business Brands]

icann staff is all about drama

 

[DNabc]

Amazing ideas from that group. Their replacement is to warn me (through mail, app or sms) when TAC / auth codes are requested... well, do same thing when a transfer is requested, it's not that hard.

 

[GeorgeK]

Amazing ideas from that group. Their replacement is to warn me (through mail, app or sms) when TAC / auth codes are requested... well, do same thing when a transfer is requested, it's not that hard.

Exactly --- because a breach/vulnerability can happen after a TAC is legitimately created, but then is stolen/misused to send a domain name to an attacker.

e.g of just one scenario (there are lots of others). You want to sell EXAMPLE.com to Fred Jones. In the contract, as a safeguard, it specifies that the buyer is going to get the AuthInfo Code (now renamed as TAC) and only use it at GoDaddy, and the seller (current owner) has it at Tucows (e.g. I'm the seller).

At present, I'd get notified (Losing FOA) once the TAC is input at the gaining registrar, to be able to ACK/NACK the transfer. I'd be able to see exactly which gaining registrar was used. If it's not GoDaddy, I would know something is afoot, and reject the transfer on that basis! (all this would happen in real-time on the phone, typically --- I'd get the ACK/NACK email within 20 minutes from Tucows). I would ACK the transfer if I see it is going to GoDaddy.

Now, let's suppose we're in the new proposed system. TAC is generated, and I get a notice of that. But, nothing's wrong at that point, since I wanted it to be generated. But, I give the TAC to the buyer, and instead of inputting the TAC at GoDaddy, it's now used at a Chinese or Russian registrar! (e.g. maybe the buyer got hacked, or an escrow service got hacked, or maybe the buyer is fraudulent, and knowingly wants to take it to another registrar, but plausibly deny that they received the domain) In these scenarios, once the TAC is used, it's game over! The transfer is complete.

Now, they talk about creating a new "undo" system, to reverse transfers. That opens up a whole new can of worms, where you have seller's remorse, or fraudulent misuse of that undo. It would totally disrupt and undermine transactions in the secondary market. It would decrease domain values, as there'd be uncertainty over title (and so one would have to factor in frictions over legal costs to enforce contracts, given the uncertainty over title). This "ETRP" (Expedited Transfer Reversal Policy) proposal was hotly debated over a decade ago, and was rightly rejected (I led the opposition on that, even having to leave that IRTP-B working group after they ignored me, and educating registrants why it was a horrible idea). Bob Mountain and Simonetta Batteiger, among others, were heavily involved to stop this. Now they want to resurrect that idiotic idea? i.e. they literally want to reduce security, to force that rejected "solution" to be required! And the unintended consequences would be severe.

 

[GeorgeK]

P.S. Time is running out, and no new comments have been submitted since I sounded the alarm. I hope others are contacting ICANN and/or the chair of the working group (Roger Carney of GoDaddy), to request that the comment period is extended.

 

[ixex]

Why?
The intention should be to improve, not go backwards.

 

[GeorgeK]

There was an article about how Canadian mobile phone porting requests were made more secure, by adding verification:

https://mobilesyrup.com/2020/11/05/...orting-verification-process-to-prevent-fraud/

The carriers have launched a new mobile number porting system that requires customers to respond to an SMS confirmation before porting occurs.

It essentially offers additional verification to ensure a request from another provider to transfer a customer’s service. It also confirms that the telephone number is generated by the customer and not a fraudster. If the customer doesn’t confirm the request then the transfer will not take place.

Unlike domains, where a transfer goes through if there's no response to the ACK/NACK email, the cell phone porting out verification is better. By default the phone number won't port out if there's no response.

Yet, ICANN's working group wants us to go BACKWARDS, and reduce security.

 

[GeorgeK]

Here's an example of what that verification looks like, in the Canadian mobile phone system

https://www.publicmobile.ca/en/bc/get-help/articles/port-fraud-protection

(see the "Transferring Your Public Mobile Number To Another Service Provider" section at the very bottom)

Transferring Your Public Mobile Number To Another Service Provider​

To help protect our customers from fraud, Public Mobile will send you an SMS text message should we receive a request to transfer your mobile phone number to another carrier. This step is designed to protect your account by confirming if the request is genuine or fraudulent.The SMS text will read as follows: Public Mobile message: We’ve received a request to transfer this phone number to another service provider. To approve this request, please reply “Yes”. If you did not request this transfer, please reply “No”. Please note that you must respond within 90 minutes. If we don’t receive a response within this time, the request will be automatically cancelled. For any issues with this number transfer, contact our Porting Team. Thank you.

While not perfect (it doesn't tell you which provider it's being switched to, which is a potential vulnerabiity), it's better to have this layer of protection. With the ACK/NACK that we currently have with domains, one can see what registrar it's being moved to, which is an important piece of information (if it's the wrong registrar, you can cancel/reject the transfer).

 

[bmugford]

P.S. Time is running out, and no new comments have been submitted since I sounded the alarm. I hope others are contacting ICANN and/or the chair of the working group (Roger Carney of GoDaddy), to request that the comment period is extended.

ICANN really does a great job of discouraging involvement, which is probably by design.

When you mobilize a response like with the .ORG takeover, the comments were so overwhelmingly against their plans that they simply just disparaged them.

With UDRP they basically fully ignored them.

It is clear this is no actual multi-stakeholder process.

Brad

 

[bmugford]

Looking over the comment process on this one, ICANN makes it extremely difficult to navigate.

There is a 22 part questionnaire, one for each section.

Brad

 

[bmugford]

I will submit a brief comment, specifically related to the transfer issue, but I also requested an extension to the public comment period as well.

Brad

 

[bmugford]

I submitted a comment -

https://www.icann.org/en/public-com...1-06-2022/submissions/mugford-brad-31-07-2022

Brad

 

[GeorgeK]

Kudos to Brad Mugford for submitting a request for more time:

https://www.icann.org/en/public-com...1-06-2022/submissions/mugford-brad-31-07-2022

https://itp.cdn.icann.org/public-co...fer Policy Review - Phase 1(a)-31-07-2022.pdf

Since they've not responded to me, I'm thinking of writing a 1 page outline, and request for more time too. I'm not going to be able to make the Tuesday deadline, and am not going to jeopardize my health to do so (I think it'll take 20 or 30 more hours to finish; I already invested more than 10 hours). Since there are only about 48 hours left, I'm not going to kill myself to meet their unrealistic deadline, particularly given how they've ignored my past comment submissions completely.

 

[bmugford]

Kudos to Brad Mugford for submitting a request for more time:

https://www.icann.org/en/public-com...1-06-2022/submissions/mugford-brad-31-07-2022

https://itp.cdn.icann.org/public-comment/proceeding/Initial Report on the Transfer Policy Review - Phase 1(a)-21-06-2022/submissions/mugford-brad/Comments on Initial Report on the Transfer Policy Review - Phase 1(a)-31-07-2022.pdf

Since they've not responded to me, I'm thinking of writing a 1 page outline, and request for more time too. I'm not going to be able to make the Tuesday deadline, and am not going to jeopardize my health to do so (I think it'll take 20 or 30 more hours to finish; I already invested more than 10 hours). Since there are only about 48 hours left, I'm not going to kill myself to meet their unrealistic deadline, particularly given how they've ignored my past comment submissions completely.

The public comment page is overly complex on this one and the deadline is far too short to dig deeper into it.

Additionally, ICANN's track record of just ignoring or disparaging public comments really limits the motivation to write a detailed response.

Brad

 

[Clover]

Interesting decisions to say the least. Seems better off how it was.

 

[GeorgeK]

Following Brad's lead, I submitted a 2 page PDF to request more time. I won't be submitting detailed comments by Tuesday (will likely add to my ongoing complaint with the ICANN Complaints Office re: public comment periods instead, if they don't extend).

https://www.icann.org/en/public-com...ap-of-faith-financial-services-inc-31-07-2022

https://itp.cdn.icann.org/public-co...est-Transfers-Phase1a-20220731-31-07-2022.pdf

 

[GeorgeK]

It's too late to edit the first post in this thread, but there were actually *4* comments at the time of the initial post, not *2*, just to get the numbers correct.

 

[Recons.Com]

What a terrible idea. It would make it far easier when it comes to domain theft.

Brad

I hope someone tries to steal icann.org and verisign.com just to teach them a lesson.

 

[Recons.Com]

Do they realize a damage that can be done to a large business if they lose the primary domain for even a day?

And smaller companies might not realize they lost it for days as they don't check it often. Especially if notifications are sent to an email linked to the domain. They won't get it ever.

Someone put in your comment that these idiots will get lawsuits worth billions of dollars.

 

[bmugford]

I just saw this post from George -

Double Red Alert: Domain Registrars Seek Power Grab To Deny Outgoing Transfers Of Legal Domains They Dislike​

https://freespeech.com/2022/08/01/d...oing-transfers-of-legal-domains-they-dislike/

They propose to broaden the discretion of registrars to block an outgoing domain name transfer, from the limited “evidence of fraud” to the far broader “Evidence of fraud or violation of the Registrar’s domain use or anti-abuse policies.”

Giving the current registrar the ability to block an outgoing domain transfer on such broad grounds is a dangerous policy indeed.

This is like the opposite of not wanting to do business with someone. A registrar could block the domain owner from doing business with others.

This opens up the floodgates for nefarious uses and abuses of registrant rights.

Brad

 

[GeorgeK]

I just saw this post from George -

Double Red Alert: Domain Registrars Seek Power Grab To Deny Outgoing Transfers Of Legal Domains They Dislike​

Thanks Brad. I created a new thread here at:

https://www.namepros.com/threads/do...nsfers-of-legal-domains-they-dislike.1279825/

to highlight that aspect of the working group's report. As I noted, the ICANN recommendations are replete with such "gotchas", and thus the public deserves more time to analyze the report in order to submit highly quality comments.