FreeSpeech.com

As previously discussed, there’s an initial report published by an ICANN working group that is making various recommendations regarding domain name transfers. One of the recommendations would eliminate the important “NACK” safeguard, which allows a registrant the ability to reject an unauthorized transfer attempt. My first blog post discussed why that’s a bad idea. A newer blog post highlighted the fact that the “AuthInfo Code” (to be renamed the “TAC” — Transfer Authorization Code) is the key to the kingdom” and thus its security is paramount. I compared it to the lack of security of a “bearer bond” (vs. a wire transfer).

Can we do better? I’ve come up with two different ideas.

Continue reading “Making Domain Name Transfers More Secure”

A few days ago, I wrote about a dangerous proposal at ICANN to reduce security of domain name transfers. They extended the public comment period by 2 weeks (which is still insufficient for me), so they’re now due August 16, 2022.

Here’s a simple metaphor to understand what’s really going on. Under the current system, it’s like owning a savings account at Citibank (where it’s protected by 2FA, etc.).  You want to transfer that to Wells Fargo (where it would also be protected by 2FA, etc.). You request the transfer (between banks) and they coordinate it securely (with checks and balances throughout). It’s a safe process, a verified process.

Instead, under the new “faster and easier” proposal, to make things “better”, they want you to convert your savings account into a BEARER BOND at your Citibank Branch (i.e. the new TAC, transfer authorization code, formerly known as the AuthInfo code is essentially the ‘keys to the kingdom’ so that anyone holding that code controls the future of that domain), and then walk it across the street or across town to deposit it at your Wells Fargo account. What could possibly go wrong?

Maybe if it’s a $10 ‘asset’, converting it into a bearer bond (or cash, for a less interest metaphor, with a less creative blog post title) is no big deal. But, if it’s a $1 million asset or $640 million asset**, you start to get a little bit worried! So, I’ve been vehement that there are inherent risks carrying around a bearer bond, even for a short time! No, no, they say….this is BETTER! LOL You’re crazy, George, bearer bonds are the way, they say! Can’t you see it?

So, I’m trying to argue for at least a “certified cheque” with my name on it, or better yet a WIRE TRANSFER between banks (secure, just a little bit slower). But, they insist on BEARER BONDS as being the future!

Frustrating!

P.S. **Credit to “Die Hard” for the Bearer Bonds idea.

As I noted in a prior post on the weekend, there’s an important ICANN public comment period that ends on Tuesday August 2, 2022 regarding the transfers policy. It contains serious security flaws that would make domain name hijacking easier, by removing the ability to NACK the transfer after the transfer request has been initiated. I won’t be able to submit comments by Tuesday, and have asked that they extend the deadline.

However, in my research I came across another startling power grab by registrars (who dominate the composition of that working group), that was inserted into the recommendations.  Recommendation #19 at the bottom of page 32 of the report contains the following text:

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.”

I had tweeted about this on the weekend:

https://twitter.com/GeorgeKirikos/status/1553576661995626496

and noted that it was “ripe for misuse”, since a use that one registrar forbids (politics, porn, casino, crypto, etc.) that isn’t illegal everywhere (like FRAUD) would trap a domain at that registrar (and ultimately lead to its deletion, if it couldn’t be renewed). A registrant couldn’t transfer the domain name to a registrar where that use is legal.

This is what happens when the working group is dominated by participation of registrars, without considering what the impact is for registrants. It’s one-sided and unbalanced.

Indeed, the transcript of that working group’s May 24, 2022 call is quite telling. [I literally stumbled upon that randomly this morning, while looking for something else]

On pages 15-16, Owen Smigelski of NameCheap (formerly of ICANN, and before that Sunrider — interesting lawsuit here that mentions him and also here) states:

But the rationale behind broadening the reasons for this denial is because evidence of fraud—fraud has a very specific definition. It means deceit of some type or trying to scam somebody or an illegal activity in there. It could be considered a very narrow definition. There are certain scenarios that might come up where a registrar might want to block the transfer for violation of terms of service.

So for example, Namecheap doesn’t want our services being used for hate speech but somehow somebody registers a domain name that’s hosting a Nazi website or a Holocaust denying website. Technically, that’s not fraud and we wouldn’t be able to block such a transfer. But if we wanted to, under our terms of service, which
says, you can’t post hate speech, we decided we want to block that transfer, we’d be able to do that as a material violation of our agreement as opposed to being forced to let somebody put something out there that us as a company does not want to escape further into the wild.

This is incedibly poor reasoning, indeed dangerous for registrants. It’s one thing to say “we don’t want you as a client”, but another thing to say “we’re going to prevent you from taking your domain elsewhere” over a dispute of the terms of service (as opposed to actual criminal activity).

While despicable, hate speech is legal in the United States. (Inciting violence isn’t legal, but hate speech itself is legal) Same goes for Nazi and Holocaust denying websites, at least in the United States (where NameCheap is based, and the jurisdiction of its registration agreement).

Volker Greimann immediately pushed back against that in the working group, saying (page 16 of the transcript):

I agree in principle but I think the language is a bit
too broad because simply put, a registrar can make anything a material violation of the registration agreement. We certainly have non-payment of fees in there. We have provision of incorrect registration data in there. We have all kinds of things that we consider a material violation of our registration agreement. And we might not want to have all of them be a reason for blocking a transfer. So I think we need to be a bit more specific. It’s hard [inaudible].

On pages 17-18 of the transcript, Mr. Smigelski brought up the concept of “guardrails”:

And Volker, I agree that that’s a concern and that’s why I want to put those guardrails in there and implementation note, which would be in a report and then, carried forward into an eventual policy to give some more guidelines on that. Happy to consider other wording to put that in there. I was just trying to give some flexibility to the registrars who might want to block for whatever reason. But also, at the same, making [inaudible] you didn’t cross a T properly, so we’re going to deny the transfer.

Yet, if you go back to the actual text in Recommendation #19 above, there are no guardrails! It’s just a pure power grab. Indeed, Mr. Smigelski literally said above “I was just trying to give some flexibility to the registrars who might want to block for whatever reason.”

Read that again! “…who might want to block for whatever reason.”

Zak Muscovitch (of the Internet Commerce Association, which is pro-registrant, but representing the Business Constituency (BC) in his participation in the working group; the BC  is essentially captured by trademark holders — i.e. it’s mostly a clone of the Intellectual Property Constituency) entered the debate on page 20 of the transcript:

This isn’t a hill that I would come close to dying on, but I’m just wondering, if there is a registrant that is violating a registrar’s domain use or anti-abuse policies or Namecheap’s anti-hate speech policies, that’s one thing. But let’s imagine a registrar that—because registrars can write in anything they bloody well want into a registration agreement. They can say that you’re not allowed to use a domain name for anything about the color blue. And so, someone’s using it for the color blue and maybe the registrar has the right to disable them from using the domain name at their registrar.

But if that registrar [sic — should be “registrant”] wants to move it to another registrar, that doesn’t have this policy, there’s another willing registrar, what’s the problem with the registrar of records saying, yeah, get the hell out of our registrar with that blue-related use of your domain name. If you could find someone else that doesn’t have that policy and tolerates it, by all means, it’s out of our hair. I think there’s an important distinction between permitting a registrant to use a domain name not one that’s registered in violation of one’s policies, but getting them out of there is a different thing.

With all due respect to Zak, it might be a “hill worth dying on” (although there are so many bad things coming out of ICANN, it’s tough to pick and choose!). It’s a very dangerous proposal. It’s being sneaked into the transfers policy recommendations, which few people are monitoring (because it’s supposed to be a “technical” working group), instead of having a broader debate in an anti-abuse working group (where the definition of “abuse” is very carefully monitored).

Let’s take a look at NameCheap’s registration agreement to see precisely what they consider to be undesirable:

You agree not to use the Services provided by Namecheap, or to allow or enable others, to use the services provided by Namecheap for illegal or improper purposes. As such, you agree not to:

• violate the laws, regulations, ordinances or other such requirements of any applicable Federal, State or local government, including those that relate to privacy, data collection, consumer protection (including in relation to misleading and deceptive conduct) and applicable consumer laws in respect of fair lending, debt collection, organic farming (if applicable), disclosure of data and financial regulation;
• transmit any unsolicited commercial or bulk email, not to be engaged in any activity known or considered to be spamming or Mail Bombing;
• cause repetitive, high volume inquiries into any of the services provided by Namecheap (i.e. domain name availability, etc.);
• infringe any copyright, trademark, patent, trade secret, or other proprietary rights of any third-party information;
• use the Services for content that will profess hatred for particular social, ethnical, religious or other groups;
• use the Services to distribute viruses, malware, abusively operating botnets, phishing, Trojan horses, worms, time bombs, corrupted files, or any other similar software or programs that may damage the operation of a computer or a person’s property;
• contain warez; contain any kind of proxy server or other traffic relaying programs; promote money making schemes, multi-level marketing or similar activities; contain lottery, gambling, casino; contain torrent trackers, torrent Portals or similar software;
• redirect to another website without their permission and/or to impersonate another person or company;
• use for the purposes of impersonating another person or entity such as redirecting a domain to another website without permission and/or using a domain to send fraudulent or abusive emails;
• use the Services in a manner that is violent or encourages violence;
• violate the Ryan Haight Online Pharmacy Consumer Protection Act of 2008 or similar legislation, or promote, encourage or engage in the sale or distribution of prescription medication without a valid prescription;
• use the Services for fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law.

One can see immediately that it’s very broad (like most registration agreements at registrars). Note how the very first sentence states that it’s not just “illegal” purposes, but also “improper“, which is extremely broad and subjective. Indeed, NameCheap (or any other registrar granted such discretionary powers to block outgoing transfers) would presumably be judge, jury, and executioner, and wouldn’t rely on an actual court to make a decision.

I’m not going to go through every point in their agreement (since I already made the “hate speech” arguments above), but let’s take a look at the “spam” language, namely “transmit any unsolicited commercial or bulk email”. The word “any” is quite powerful (i.e. just 1 message is enough! How would domains of political parties ever survive, given how often their messages are marked as spam?), especially when combined with the fact that it’s not just your own behaviour as domain name owner that matters — one also needs to police “others” as per the very first line above.

Would a domain name like Gmail.com pass that test, given it allows others to send messages? Gmail.com is used by a considerable number of spammers. Of course, Google takes anti-spam measures seriously, but one could easily interpret that domain as being in violation of NameCheap’s agreement. Google is very powerful and would fight back, so NameCheap would never use that weapon against someone like them. Instead, they would tend to use that weapon against the less powerful. However, the less powerful are those that most need to be protected against misuse of such discretionary powers. Raise your hand if you’re less powerful than Google…(of course, Google doesn’t have Gmail.com at NameCheap).

How about the part about “redirect to another website without their permission” — would the famous Loser.com domain be trapped by such a policy? It has been redirected to numerous sites (like that of Al Gore), presumably without permission.

Actually, going back to the “hate” text, their terms are “profess hatred for particular social, ethnical, religious or other groups;” Would it be a violation of their agreement to say that you “hate spammers” or  “hate the New York Yankees and their fans” or “hate dumb lawyers in ICANN working groups with too much time on their hands”? Spammers, New York Yankees fans and dumb lawyers in ICANN working groups with too much time on their hands are certainly “groups” and thus fall under “other groups“.

How about the part about “infringe any copyright”? Any site with user-generated content regularly has challenges in that regard. But, you’re at NameCheap’s discretion. They simply want the power to go after the “bad guys”, to trust them not to misuse their discretionary power.

I think that the people we should mistrust are those who seek extraordinary and one-sided powers in the first place.

In conclusion, this report is replete with dangerous proposals that will harm registrants. An extension of time is needed so that the public can fully digest the report and submit high quality comments.

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:

1. 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.
2. 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:

1. Emily Barabas of ICANN: email on ICANN website
2. 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).