“If liberty means anything at all, it means the right to tell people what they do not want to hear.” ― George Orwell
On April 19, 2023, I highlighted negative aspects of the proposed .NET Registry Agreement between ICANN and Verisign.
The public comment period ends on Thursday May 25, 2023 at 23:59 UTC (i.e. tomorrow), and I just submitted my company’s final comments.
I encourage others who care about the rights of registrants to do the same.
Others, including the Internet Commerce Association and TurnCommerce have submitted substantial comments. All of the public comments can be read here.
ICANN, the organization that regulates global domain name policy, and Verisign, the abusive monopolist that operates the .COM and .NET top-level domains, have quietly proposed enormous changes to global domain name policy in their recently published “Proposed Renewal of the Registry Agreement for .NET”, which is now open for public comment.
Either by design, or unintentionally, they’ve proposed allowing any government in the world to cancel, redirect, or transfer to their control applicable domain names! This is an outrageous and dangerous proposal that must be stopped. While this proposal is currently only for .NET domain names, presumably they would want to also apply it to other extensions like .COM as those contracts come up for renewal.
ICANN has a public comment period for the Final Report from the EPDP on Specific Curative Rights Protections for IGOs, which proposes to harm registrants’ rights, by making IGOs (intergovernmental organizations like the UN) exempt from the mutual jurisdiction clause of the UDRP/URS. This would mean that a domain owner’s rights to judicial review of an adverse UDRP/URS decision would be prejudiced.
Our comments can be read on the ICANN site, along with all the other public comment submissions. [including those of the Internet Commerce Association]
I’ve written extensively about the security implications of the “Losing FOA” step of domain name transfers. It’s the opportunity for registrants to “ACK” or “NACK” a pending transfer, before it completes. I wrote about this again yesterday, and that post linked to all prior writings.
I wanted to give readers direct visual evidence of why the Losing FOA is so important as a security mechanism, so I intiated a transfer of a domain name from my company’s portfolio at Tucows/OpenSRS to GoDaddy. After I input the transfer code (currently called the “AuthInfo Code”, but it will be renamed the “Transfer Authorization Code” or “TAC”) at GoDaddy, Tucows/OpenSRS sent me (as registrant) an email, with a link to a page that would allow me to immediately approve the transfer (i.e. “ACK” it), or to reject the transfer (“NAK” it). Here’s a screenshot:
As you can clearly see, the page contains text saying:
The domain name listed above will be transferred to:
New Registrar
GoDaddy.com, Inc.
and gives me the opportunity to accept the transfer, or decline it (I’ve just left things in a pending state for now; I’ll perhaps “ACK” the transfer in a few days).
Had the transfer code been compromised, with an attacker using it at a different registrar, I’d have been able to immediately detect the unauthorized transfer request and stop it before it completed, as I’d be able to see that it wasn’t transferring to GoDaddy.
In conclusion, this is an important security mechanism, given that there is otherwise no protection for misuse of the transfer code once it’s generated. Without this important safety mechanism, the registrant is “on their own”.
[P.S. In case you were wondering about the domain I used for the test transfer, “Big Swinging Dick” is a Wall Street term mentioned in the book “Liar’s Poker” — “If he could make millions of dollars come out of those phones, he became that most revered of all species: a Big Swinging Dick.” And of course, I own the dot-com (through my company).
P.P.S. What if an attacker had used a compromised transfer code at GoDaddy before I did, and I mistakenly approved an incorrect transfer into their account, rather that my own account at GoDaddy? That’s a vulnerability that I’ve advocated be addressed, by showing the full WHOIS “before” and “after” the proposed transfer (while it’s still in a pending state, to allow the current registrant full transparency of how the WHOIS would change, should they accept the transfer). See section G (pp. 23-25) of my full submission to ICANN. Although, even under the status quo, at least the domain name would be at a “friendly” registrar (i.e. a legal jurisdiction that I had specifically wanted to transfer the domain), where presumably the force of law could be used to correct things.]
Despite months spent educating stakeholders, registrars continue to threaten to weaken domain name transfer security.
Continue reading “Registrars Continue To Threaten To Weaken Domain Name Transfer Security”
In August, I submitted extensive comments on behalf of my company to ICANN regarding proposed changes to domain name transfer policy.
I’d written multiple blog posts before then, warning about the negative ramifications should their recommendations be adopted. See here, here, here, here and here for those past articles on the topic.
In September, I participated (as a member of the public, not as a member of the working group) in the public ICANN75 session on the topic (I wrote another blog post immediately before that session.). After that session, one of the ICANN working group members posted some thoughts on my proposals.
As I’ve yet to be invited to participate directly in that working group (which might correct the severe unbalanced and unrepresentative participation, where registrants’ views are not being taken seriously), I’ve written a public response to that email. You can read that response here (while it’s 20 pages long, it’s very generously spaced, so it shouldn’t take long to read and digest).
There is a lot wrong with this working group’s report and ongoing deliberations. The public deserves more than mere lip service during an ICANN75 meeting. We deserve active engagement throughout the remainder of the working group’s efforts, especially given the unbalanced participation at present.
The ICANN75 session of the ICANN Transfer Policy Review PDP Working Group will be taking place in less than 12 hours from this blog post, at 10:30 PM Eastern Time on Friday, September 16, 2022. [10:30 MYT (UTC+8), 17 September 2022]
Remote participation is available via Zoom (you’ll need to create an ICANN account to access the links to the Zoom room, as per the above session link).
As I’ve noted in my lengthy comment submission, there are very serious problems with the working group’s recommendations.
Furthermore, that working group’s review of the public comments is superficial at best. As an example, watch the Zoom recording of this past Tuesday’s working group call. (unfortunately, the written transcript of the call isn’t posted yet on the GNSO’s calendar page).
Did the working group even mention, in discussions of removal of the Losing FOA, my citing of the SSAC report, from page 39 of my comment submission, to:
“Treat transfer attempts as a security event (check and re-check).”
Nope! Apparently such an important point was not worth mentioning on their call! It demonstrates the importance of the Losing FOA.
There’s a certain arrogance in the working group, as if they know better than the public. e.g. Jim Galvin of Afilias (a member of the SSAC) claimed he was “not especially persuaded by most of these comments” and that he didn’t believe “that there’s new information here” (see the “rough transcript” produced by Zoom at around 44:22 into the call, or listen to the actual call; the rough transcript isn’t perfect).
Galvin claimed that he “could sit here and go through, and I think I would have a specific response to each one of these comments” (at around 44:53 into the call). I openly challenge him to do so!
I even reached out to him, to have a telephone call, to go through my concerns to see what his “response” would be. I’ve not heard back, yet.
At 1 hour and 10 minutes into the call, Galvin asserts that “there really is no diference between the FOA and the notification.” He then goes on to claim “the notification has the same properties. It neither adds nor removes them.”
This is demonstrably false!
If I validly create a TAC (transfer authorization code), to transfer a valuable domain name from Tucows to GoDaddy (as an example), and provide that TAC to a buyer or to an escrow company, but then see (via the Losing FOA) that the transfer is actually going to Alibaba or a Russian registrar, I’d be able to NACK (cancel) the transfer, as it’s not going to the correct destination.
That involved no compromise of the registrar’s control panel, but involved misuse of the TAC after it was properly generated, but before it was properly used at the correct gaining registrar).
This is a perfect demonstration that their analysis is completely wrong. The removal of the Losing FOA would have demonstrably made one worse off.
Galvin claims that “all bets are off” if an attacker gains access to a registrar’s control panel (because the attacker can change registrant contact details, so the registrant wouldn’t be able to receive the Losing FOA). Again, his analysis is wrong. Perhaps at a poorly-designed registrar, his analysis might be fine. But, a properly-designed security-conscious registrar wouldn’t immediately make those critical changes. They would seek verification first! I documented in my lengthy submission that I carefully separate out the registrar control panel details and contacts, so that they’re independent of the domain name contacts.
Later on that call, at around 1 hour and 14 minutes, Jim Galvin demonstrates to us all that he didn’t actually do his homework and understand the working group’s report, as he was unaware that the 5 day window after the gaining registrar submits the transfer was being eliminated. How embarrassing for him, and embarrassing for SSAC. He says “maybe I’m missing something here” — yes, Galvin and others are missing a lot!
In conclusion, it’s clear that these working group members are not doing a proper review of the public comments. They have tunnel vision, and are working from the starting point that they “know better” than the public who submitted serious concerns about their dangerous proposals. If you share these concerns and have time on Friday night (North American time) to attend the ICANN75 session remotely, please do so.
Stanley Pace has won a reverse domain name hijacking victory in court, overturning a wrongly-decided UDRP decision at WIPO in the celluvation.com dispute.
You can read the entire court decision here.
In summary:
The Court herby DECLARES and ORDERS:
1. Pace’s use of the celluvation.com domain does not violate the ACPA.
2. Pace’s use of the celluvation.com domain does not violate the Lanham Act.
3. Pace has established a claim for reverse domain name hijacking.
4. Defendant’s counterclaims against Plaintiff are DISMISSED WITH PREJUDICE for willful and inexcusable failure to prosecute and failure to comply with court orders pursuant to Fed. R. Civ. P. 41(b).
5. Pace’s request for fees is DENIED.
6. The WIPO arbitration panel decision is OVERTURNED, and the domain name
registrar for celluvation.com is ORDERED to lift the hold on the domain name and return the domain to Pace.
7. Judgment shall be entered in favor of Plaintiff
Will WIPO add this decision to its list of UDRP-related court cases? You might recall that WIPO retaliated against my company and removed the PUPA.com court case decision from their list (after I voted against Brian Beckham as co-chair of the RPM PDP working group at ICANN).
An Arizona court has ordered that the ETH.LINK domain name be transferred back to True Names. You can read the entire order here.
This was first reported on Hacker News last night, but none of the usual suspects blogged about it yet. Given I’m “on strike” for reporting on SEC Filings findings for the rest of the year, due to too many parasitic bloggers, I figured I’d write about something different. Let’s see how many parasitic bloggers write about this without citing the original Hacker News post or this blog post…especially those who don’t typically blog on the weekends….
Obviously change of ownership and domain transfers in general are matters of critical importance, yet how many people reading this bothered to submit comments to ICANN during their recent comment period? You can read my company’s 60 page submission in a prior blog post. If you were upset about how the registrars handled the ETH.LINK expiration and transfer to a 3rd party, perhaps you should pay more attention to the policies which enable that behaviour. When a registrar can earn more from the expiry of a domain name, rather than its renewal, that creates an enormous conflict of interest. The interests of registrants are routinely ignored at ICANN, because of your apathy.
Today I submitted comments on behalf of my company (Leap of Faith Financial Services Inc.) to ICANN regarding proposed changes to domain name transfer policy. You can read those comments in this PDF, or at ICANN’s public comment forum along with those of others such as the Internet Commerce Association. If you’d like to submit your own comments, the deadline is Tuesday August 16, 2022 at 23:59 UTC.
I’ve written multiple blog posts in the past few weeks, warning about the negative ramifications should their recommendations be adopted. See here, here, here, here and here for those past articles on the topic.
The comment submission reiterates and expands on those past articles. I also took a deep dive into each of the recommendations. It was a considerable effort (at least 40 hours, if not more) in a compressed time frame. It was truly stressful given the deadline would not be extended to mid-September (or beyond) as requested, to be a more reasonable schedule for the amount of work involved. As I note on page 5 of the submission, I could have used more time to reorganize, restructure and condense the material (which amounts to 60 pages!). Consider this a “draft” that wasn’t intended for publication, but is as good as it’s going to get in the time that was provided.
As I note in the conclusion, the most important section is Section E (generate a transaction ID at the gaining registrar, to input at the losing registrar; this way, we can eliminate the TAC). Also, retaining the “Losing FOA” (Section F), at least on an opt-in basis, to preserve the ability to ACK/NACK a pending transfer is critical. Those are the two big counterproposals, although lots of other stuff was important and needed to be said.
The unbalanced nature of the working group composition (registrars dominating) should concern everyone, as registrants’ interests are not being protected.
You must be logged in to post a comment.