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.