Despite months spent educating stakeholders, registrars continue to threaten to weaken domain name transfer security.
I have written extensively in the past few months about the ICANN Transfer Policy that a working group is currently reviewing, as the proposals in their Initial Report would harm domain name registrants by removing an important safeguard. My past blog posts regarding the Transfer Policy working group can be read here, here, here, here, here, here and here. My actual submission to ICANN was in the detailed PDF mentioned in my August 14, 2022 blog post.
The “Losing FOA” step is an important safeguard for registrants in the current transfer process, as it allows a domain owner to reject (“NACK”) a pending transfer request (before it completes) after seeing the identity of the gaining registrar. This step takes place after the transfer code (currently called the “AuthInfo Code”, but it will be renamed the “Transfer Authorization Code” or “TAC”) is input successfully at the gaining registrar. Under the “Losing FOA”, the current registrar (the “losing” registrar should the transfer succeed) would contact the domain name owner, notifying them that a transfer is in progress and providing the opportunity to either reject it (“NACK”) or immediately approve it (“ACK”). If there’s no response, the transfer will go through by default after 5 days. If the transfer code is compromised, and an attacker tries to transfer to a Russian registrar, whereas I wanted to transfer to GoDaddy or MarkMonitor, I would be able to see that, and stop the unauthorized transfer. There are numerous attack scenarios where the transfer code is compromised, as I discussed in detail in my prior blog posts and submissions, so it’s important to retain the Losing FOA step. In particular, there are scenarios where the registrar’s control panel is NOT compromised, but the transfer code is still compromised [and so an attacker is unable to change the contact info that would receive the Losing FOA notification in those attack scenarios].
I’ve been monitoring and reviewing all the working group calls since the Initial Report came out, and continuing to advocate for retention of the Losing FOA by educating stakeholders. It appeared that the working group had been leaning towards retaining this important safeguard. Later this week, they appear to be planning to decide the fate of the safeguard.
However, last week (on November 22, 2022) there was an alarming “proposal” posted on the mailing list that would continue to eliminate the Losing FOA step! This “proposal” purports to “address all the concerns raised in the public comments”, but does no such thing. In fact, it looks essentially unchanged from what was proposed in that working group’s Initial Report! (that’s why I use the term “proposal” in quotations, as it doesn’t appear to be anything new at all)
Rather than actually addressing concerns, all this “proposal” does is make a restatement of the initial report’s recommendations, to frontload the security checks (as per the Initial Report’s recommendations), but then leave the registrant completely on their own once the TAC is generated (where a stolen TAC can then be used by an attacker after the TAC is compromised, with no further opportunities to stop the transfer).
This is completely unacceptable. It does absolutely nothing to address concerns. It completely misses the entire point of our submissions (and those of others), namely that the TAC can be generated properly by a registrant, but can be misused after it is generated, and before the rightful registrant uses it at their desired gaining registrar. By the “numbering” of steps in the November 22 email, what happens between 2(c) and 3? There is absolutely no security left between 2(c) and 3. That’s why we must retain the Losing FOA, to ensure there is no gap created that can be exploited!
Rather than being a step forward, to address concerns, this is a backward step, an attempt to revive and reintroduce the same weakened security proposal that was presented in the Initial Report.
This proposal is alarming because the working group finally (after 3 months of educating them!) appeared to be making some progress in actually recognizing, understanding and agreeing with the concerns of security-conscious registrants.
On the November 8, 2022 working group call, Roger Carney (the Chair of the working group) said (see transcript, or review the Zoom recording):
“One of the topics that came up on that, trying to get to Lutz here, was in that scenario—and it was talked about quite a bit is that scenario up front—once the TAC is provisioned, if the TAC is gained by someone else at that time, there’s no protection to it. Where if the functionality is put at a pending state, the registrant gets to at least identify when and where that transfer was actually finally requested at. So it seemed like if you did it up front—you’re right, Sarah, it seems like you got those benefits out of it. But then you missed the opportunity to add more. I don’t know if you’d call it security or not or confirmation to it, that the TAC was being used at the correct gaining registrar and possibly even at the correct time that the registrant can get that notice then so it improves that possibility there.” (p. 16, emphasis added)
Similarly, Lutz Donnerhacke said:
“The final word to the TAC security, the TAC is not secure at any way. It might be generated in an algorithmic secure way, but it doesn’t mean that the result of the secure generation is stored and transferred securely. Using a cryptographic algorithm to generate something does not mean that the whole result is secure in any way. So, of course, the TAC can be stolen and can be reused in different ways. It can be captured via e-mail or something like this. So I really enjoyed a proposal which allows the registrant to roll back or prevent the transfer. (pp. 16-17, emphasis added)
I was heartened to find that the working group was making such progress, that all the hard work was having an impact. (although “roll back” isn’t acceptable, as it would create issues of “Seller’s Remorse” as we pointed out when we successfully opposed the “Expedited Transfer Reversal Policy proposal a decade ago, as discussed in our formal submission).
Mr. Carney went on:
“Again, no matter how secure you make the TAC, once it’s been provisioned, someone can get it. In our current recommendations, it can be used to immediately transfer. And yes, in phase two, we come back and we have a rollback feature. Great, but then it’s work that probably didn’t need to happen. Again, rolling it back, no matter how great of a process we come up with, rolling back is going to be more impactful than if we could have stopped the transfer to start with.” (p. 17, emphasis added)
And further, Mr. Carney said:
“Again, I think that we went through these ideas and it still came down to obviously still being exposed window of time that this TAC could be gained by someone else and used,…” (p. 17, emphasis added)
And Mr. Carney also said:
“If we leave it in the pending state, then the gaining registrar should be known. That’s another check for the registrant to identify with.” (p. 18, emphasis added)
So, in conclusion, all the November 22, 2022 “proposal” did was keep in place the “exposed window of time”, and delete the “additional check” (identity of gaining registrar revealed in the Losing FOA), which is the entire point why the Losing FOA needs to be kept. This is not good!
It’s hypocritical that they wrote on November 22, 2022 that “we shouldn‘t reject ideas just because they take work, especially since we’re already making changes to the transfer process as a whole. Now is exactly the time to do this!” (emphasis added)
I put forth a serious counter-proposal to the Initial Report’s recommendations, called the “Breakthrough Proposal” (pages 11-18 of my submission) which would be far more secure than the current transfer system, as it would adopt a “push” structure as is done with wire transfer payments and even is used internally within registrars to do domain name transfers. In their deliberations, the working group explicitly rejected my counter-proposals, which are demonstrably more secure and superior to initial report recommendations, because they would take work to implement those changes! This illustrates the repeated double-standards that take place in the comment review process, and generally within ICANN and its working groups.
The “Risk” mentioned in the November 22, 2022 “proposal”
“Risk: There would be no notification/’stop the transfer’ moment after the transfer is initiated with the gaining registrar; Mitigation: (a) there is a notification/stop moment at the time of TAC request, and
(b) the fast-undo process we are committed to creating in the next phase of this WG would specifically address these issues and could certainly include reverting DNS if it was changed”
ignores the fact that the “mitigation” can only reverse the domain’s ownership and registrar, but CANNOT reverse the immense DAMAGE that can take place during the time that a domain name is hijacked, even for brief periods. I recall someone made a rhetorical question of “Can I have control of Google.com for 5 minutes?” This is why criminals hijack phone numbers. They can then use the hijacked phone numbers to reset passwords, hijack accounts of other linked services/email, etc., steal crypto, penetrate corporate networks to steal corporate intellectual property and consumer private data, and do other irreversible acts. And the damage that can happen from a stolen domain is much greater than that from a stolen phone number. [As an aside, registry lock is NOT a solution, as one working group member suggested — this is the period where one actually legitimately wants to do a transfer (where registry lock must be removed); the TAC can be stolen after it’s legitimately generated but then used by an attacker to transfer the domain name to the attacker’s preferred registrar, instead of the legitimate gaining registrar destination that the domain name owner intended to move the domain.]
In conclusion, last week’s proposal does absolutely nothing to address the serious security concerns raised during the public comment period, but instead simply restates the deeply flawed proposal of the Initial Report. By frontloading all security measures, they would create a process that would leave the registrant vulnerable during an exposed window of time. This is unacceptable. Instead, registrants deserve a transfer process that is secure from start to finish.