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.
Idea #1: The Best of Both Worlds
I originally posted this on NamePros in the long discussion thread on this issue (post #32), on August 1.
1. At the time that the TAC is generated (or even better, set it at an account level at the registrar, which can only be modified by an out-of-band verification, and with a delay if changed to a weaker state, for safety), give the registrant the choice, whether they want the transfer to be “SuperFast” (or you can call it “Normal”), or “SuperSecure” (Slower).
2. If they pick “SuperFast”, there’d be no “ACK/NACK” step after the TAC is used at the gaining registrar — transfer would complete immediately (what the new working group recommended).
3. If they pick “SuperSecure”, there’d be the current “ACK/NACK” step after the TAC is used at the gaining registrar — which registrars already have code for — it’s what we have now! This is all automated, too, so it’s super-trivial and cheap. [This has greater security in the event the TAC is compromised after it’s generated.]
There’d need to be a few pieces of extra code at the registrar/registry to handle the different branches, depending on the path initially set. [but, since the report already proposed a change, they’d be writing new code anyhow!]
So, we can have the “best of both worlds.” I think it’d be essential for the security-conscious registrant to be able to make a setting that ALL of their transfers are “SuperSecure” by default, which can’t be changed except via out-of-band communications, etc. That preserves my multi-factor security, and also protects against rogue employees somewhat, or if the registrar gets hacked, to some degree. [i.e. if an attacker can override that setting without my consent by breaching the registrar, they can boost their chances of a successful theft]
Thing is, there’s always going to be scenarios where a rogue employee at a registrar does something, or there’s a 0-day Linux vulnerability that hacks the registrar, or there are some other scenarios where the ACK/NACK saves one’s bacon….so I’m reluctant to give it up easily. (not all scenarios; i.e. the ACK/NACK step might get hacked at the registrar too — in an ideal security design, strict access control would be taken into account, to minimize the odds of that kind of attack, with lots of logging, too)
I ran a Twitter poll, and you can see the results below. Of course, it’s not a statistically significant sample, or a carefully controlled random sample, but it’s at least an attempt to get broader input. Clearly, folks like the idea of having the choice of a faster or more secure transfer. They don’t want to be forced to be “SuperFast” all the time. (which is what the working group would impose, if their recommendation was adopted)
https://twitter.com/GeorgeKirikos/status/1554250422747074560
By the way, I didn’t poll on this, but one could enhance things even further, by also providing the option of “UltraSecure”, which would require an ACK for the transfer to succeed. [i.e. it would change the default behaviour of ‘accept the transfer if the registrant doesn’t respond’ to become ‘reject the transfer if the registrant doesn’t respond to the ACK/NACK request’]
Idea #2: Generate Transaction ID At Gaining Registrar, To Replace TAC
This is a brand new idea that I came up with this evening, so I don’t have a snappy name or tagline for it, yet! But, here’s how it would work, and its motivation.
It’s a different way of doing transfers that actually doesn’t suffer from the problem of putting all the “weight” of security into the TAC code. Indeed, the TAC code can become worthless to an attacker under a different
approach.
As I discussed in my prior blog post, the TAC code is the ‘key to the kingdom’, and as such needs to be kept secret. An attacker who gains access to that code can take the domain anywhere they want. That’s why we have transfer locks in the first place (to prevent a lucky guess from working, if the domain is unlocked, via brute force attack of the AuthInfo code/TAC). The working group spent a lot of energy trying to increase the “Complexity of the TAC”. That’s again doubling down on the “everything is in the TAC” camp. [that’s why the NACK has value, as a safeguard against misuse of the TAC after it’s generated but before it’s properly used, if it’s stolen and used by the thief at the wrong registrar, etc.]
So, I said to myself — can we do better? Is there a way to jiggle the process to make the process secure, and make the TAC completely worthless if it’s absconded by an attacker? I think there’s a way.
Step 1: Go to gaining registrar, and initiate a transfer. The GAINING registrar gives registrant a unique transaction id, e.g. GAININGREGISTRAR-EXAMPLE-COM-1
Note that while it’s unique, it need not be fancy or encrypted or have special characters, etc., because (as you’ll see below) knowledge of this code is completely worthless to an attacker, by design! That code is sent to the registry (can even be generated by the registry). For ease of use, it should probably mention the gaining registrar (or its IANA ID), the domain, and some numbers to make it unique. [so it could have been 0023-EXAMPLE-COM-123456, for example, instead]
Step 2: Registrant goes to losing registrar (logs into control panel, or whatever), and says that they want to complete a transfer. They then input the code from Step 1.
Step 3: (optional, but obviously I’d want it) ACK/NACK step by email to registrant from losing registrar, for confirmation of transfer (or at least ability to NACK like today, with default behaviour to be decided by policy — today obviously the transfer succeeds if there’s no NACK or no response). [this step acts as a last layer of defense if the control panel access is compromised, or other attack scenarios, e.g. rogue employee at registrar, etc.]
That’s it!
Notice the attacker GAINS NOTHING by knowledge of the transaction ID in Step 1. Attacker only succeeds if they (a) initiate their own transfer at a different registrar, and (b) convinces the registrant to use THAT transaction ID, instead of the right one!
So, if the “correct” transaction ID is GODADDY-EXAMPLE-COM1234; but
attacker’s version is ALIBABA-EXAMPLE-COM-5678 not too many
registrants are going to be ‘fooled’.
Notice that because there’s no longer a “key to the kingdom” value of
the AuthInfo code/TAC, the ‘value’ of transfer locks themselves is diminished. To the extent that a transfer lock prevents attackers from generating thousands of bogus requests, it might have some value, though (i.e. preventing a denial of service attack, essentially). The registry operator would conceivably have to store multiple competing transfer requests (the one true one, and all the bogus ones), but only one would succeed. And that’s entirely under the control of the registrant (i.e. registrant inputs the valid transaction ID into the losing registrar’s control panel).
To prevent abuse, I would not refund the invalid transfer requests, or
only partially reimburse them — that would be an economic solution
that scales. [i.e. if you make transfer requests ‘free’ until they succeed, that would encourage abuse/attacks]. i.e. it imposes a direct cost on fraudulent/bad transfer attempts.
One can also add a TTL (time-to-live) to the transaction ID, so it can only be used for a couple of days, at most, etc.
So, this has similar security as the working group targeted (namely
(a) security of access to the registrant’s control panel, and (b) control of the email of the registrant), BUT, it keeps the process secure throughout. It doesn’t have the dangerous flaw that I’ve been concerned about, i.e. that the TAC code represents the ‘key to the kingdom’ and has to be protected
at all costs. Indeed, you drop all security under the current system
once you unlock and have generated an AuthInfo Code or TAC.
Instead, it flips things around. The gaining registrar or registrant could literally put the Transaction ID from Step 1 on a billboard — it’s completely useless to an attacker. Knowledge of that code can’t be used by an attacker to transfer the domain to a different registrar.
Why would folks not like this? “Not invented here” syndrome. Or “it’s
different from what we have today” (although, they are already proposing something that’s different from today!) Or, “because George thought of it, and some folks hate George.”
But, on a purely technical basis, it seems far more sound and secure than what we’ve got, and what’s been proposed in the report.
Conceivably, this could also work in parallel to the current system, not having to replace it completely, to allow a transition period.
As you can see, I’m putting considerable work and thought into all
these problems generated by the report, and I would truly appreciate that the deadline for comments by extended to mid-September. So far, they’ve refused to do so. (there’s a huge double standard, as I’ve noted on Twitter, that the working group themselves want to take time off over the summer, and not hold weekly meetings, but expect the public to generate comment submissions during that time frame!).
A few of you have submitted comments to ICANN to request more time. Please continue to do so, and/or reach out to Roger Carney of GoDaddy, or your registrar or to others that might be able to make a difference in extending the deadline. The registrars dominate the composition of that working group, so having registrants tell those registrars that more time is needed to digest and respond to the report might have an impact.
I’m still undecided whether I’m even going to submit a comment by next
week. It’s extremely frustrating to have all this knowledge, but know that it takes an enormous amount of time to write up a thoroughly researched submission. Sufficient time is essential to generate a quality submission, not for the sake of delay itself (in bad faith). Remember, this doesn’t delay the new gTLD program, or have any other ‘consequences’. This is only about having a a reasonable amount of time to submit a quality response to the initial report. The current schedule is unreasonable.
If ICANN comments are intended to provide meaningful input, then the comment period should be extended until mid-September (at least).
In conclusion, I hope this blog post makes the wheels turn in your own minds, and perhaps you’ll also come up with a brand new insight or solution that would improve upon the transfer system!