There’s an important ICANN public comment period that ends on Tuesday August 2, 2022 regarding the transfers policy. I haven’t finished my own comments yet, but I thought it important to sound the alarm, as only 4 comments have been submitted to date.
Andrew Allemann of DomainNameWire.com had blogged about this topic in June, yet it seems that wasn’t enough to get folks engaged. [although, perhaps folks are sick of being ignored, given ICANN comment periods are notorious for being shams]
One of the biggest changes, as Andrew noted, would be the elimination of the ability to reject a pending transfer request (before the transfer has been completed), aka “NACKing” the transfer. (in contrast, an “ACK” would approve a transfer) This was recommendation #2 on page 18 of the report. This is a recipe for disaster. The registrant would be notified after the domain transfer has already completed, and would not have ample opportunity to reject a pending transfer. A fast-acting domain name thief could successfully complete a transfer before a registrant is even aware of a pending transfer.
This sham report hides the enormous negative impact that this change would have, by not even mentioning in their analysis the number of times the “NACK” procedure has saved a domain from an unauthorized transfer. Andrew’s own comment submission wondered about those stats, asking:
It would be interesting to hear from registrars about how many times customers try to stop fraudulent transfers after receiving the FOA.
I found the numbers he sought. Page 11 of the initial report linked to a separate “Status Report” from 2019. Page 12 of that Status Report mentioned that there were approximately 4,968,000 domain transfer per year, roughly 0.3% of total domain name registrations. Chart 4 on page 23, and the table on page 24, show that “NACKs” are done an average of 12,348 times, vs. an average of 414,000 transfers per month. That means that approximately 1 in every 34 domain name transfers is NACKed!
That means, in the course of a year (12 months), approximately up to** 150,000 domains are saved from unauthorized transfer attempts by the “NACK” system. [Update August 1: the data didn’t have the granularity to specify the reason for each NACK, so I changed the word “approximately” to “up to”, since conceivably a NACK might take place for another reason.]
Ask yourself this: Why did the working group not put these numbers directly into their own report?
This ICANN working group foolishly proposes to eliminate this “security in depth” procedure, instead proposing that a new system be designed to allow one to “undo” a transfer. (to be determined in a future phase of the working group). That proposal disregards 2 obvious problems:
- The immense damage that can take place in a short time when a domain name is hijacked (e.g. resetting passwords of linked 3rd party accounts by hijacking emails, e.g. bank accounts, crypto accounts, social media, etc.) cannot simply be undone by reversing a domain transfer.
- An “undo” procedure for domain transfers was already hotly debated in the past, and rejected, as it would severely impact the secondary market for domain names. This was the “Expedited Transfer Reversal Policy” (ETRP) in the IRTP-B working group, that I led the charge against in 2010 (see the public comments on that proposal here). It should be obvious that “sellers’ remorse” and pure fraud would be the result if a former registrant could simply undo a transfer. [They mention the ETRP on page 31 of the report, but didn’t go into detail as to why it was soundly rejected by the community, after considerable debate.]
This horrible report from ICANN literally exacerbates a problem (increased unauthorized/fraudulent transfers via lowered security), and then seeks to resurrect a rejected policy from the past to “solve” the problem!
How did such a flawed report get so far? One of the problems was the composition of the working group, with domain name registrants severely underrepresented (see pp. 46-47 for the names of those responsible for the report). I’ve pointed this out for other working groups (e.g. the RPM PDP was dominated by pro-complainant participation; the recent IGO working group showed even more shocking unbalanced participation). Of course, I’m unfairly banished from all ICANN working groups.
There’s more to say about this garbage report, but time is of the essence so I’m posting this article today, before I’ve completed my own comments. I’ll also request an extension of the comments deadline (others should do so too), given few in the community are aware of the negative impacts of these proposals, dropped in the summertime when few are paying attention.
P.S. To request that the comments deadline be extended (I requested it be extended until the 2nd week of September), your best bets are to contact:
- Emily Barabas of ICANN: email on ICANN website
- Roger Carney of GoDaddy (chair of working group): email via mailing list archives
P.P.S. After additional research, I found a newspaper article in the Globe & Mail titled “Canada saw surge in phone-number fraud in 2019, 2020, figures show” (POSADZKI, ALEXANDRA; page B2, Sept. 29, 2021) The article is paywalled, but I found the print article using a different database. That article notes that there were 21,589 fraudulent customer ports in the Canadian phone number system over a 10 month period from mid-2019 to 2020. These are similar to domain name thefts, but for phone numbers. Roughly 1 percent of transfers were unauthorized (with a peak in a single month of 2.5%). By reducing security of domain name transfers, ICANN would be making similar attacks on domain names easier. The damage from a domain name hijacking might be far greater in many cases than the payoff from phone fraud. This is the kind of data that should inform policymaking, yet is missing from the ICANN working group’s analysis.
P.P.P.S. If you need ‘evidence’ of the deadline being unreasonable, I
point to the comments last year by Mike Rodenbaugh, on behalf of the
IPC:
“I should have spoken up earlier about the unreasonable timeframe to require constituency comments be drafted in July. Anyway now I do need to note that the IPC written comments will not be ready by tomorrow. We have struggled to coordinate during the July holiday season (for many). But we are fully in motion now. We are still taking input and drafting responses, and hope to have a constituency position at least as to the Phase 1 questions in the next 2 or 3 weeks.”
in response to an unreasonable timeframe. Unlike the IPC, which is able to provide continuing input due to their representation within the working group itself, the broader community is not adequately represented (particularly registrants), meaning that the public comments are their only opportunity for feedback to the working group.
Update: July 31, 2022
There was an article about how Canadian mobile phone porting requests were made more secure, by adding verification:
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.
Here’s an example of what that verification looks like, in the Canadian mobile phone system (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 vulnerability), it’s better to have this layer of protection. With the ACK/NACK that we currently have with domains, one can see which registrar it’s being moved to, which is an important piece of information (if it’s being moved to the wrong registrar, you can cancel/reject the transfer).
Yet, ICANN’s working group wants us to go BACKWARDS, and reduce security.
Second Update of July 31, 2022
It’s not feasible for me to complete my submission by the current deadline of Tuesday August 2, 2022. So, I instead submitted a 2 page request for an extension of time to ICANN. See the request here (and also the PDF attachment).