The issues are linked, for the reasons explained below.
But let us please first go back in history to put things in context, and I will be mostly targeting gTLDs and .COM/.NET in fact:
- when the registry/registrar split started, the protocol used to communicate was then RRP (see RFC2832); as you can see in its section 4.3.10 the transfer command was used by the new registrar... without providing anything except the domain name
- this of course just by itself mean that abuses can happen, so ICANN drafted a policy mandating registrars to ask prior consent to the current registrant (or administrative contact); this was in fact a nightmare for registrars as they had to parse whois output to grab email addresses to be able to contact a registrant before launching the transfer command; this policy evolved over time and its latest version mandates specific email messages that the prospective registrar has to sent, again to registrant or admin contact and he needs to get back specific positive acknowledgement before proceeding with the transfer
- even with this danger, or to mitigate it, many registrars did send emails to their customers when they are notified of an outgoing transfer (they get the information from the registry), since by default a transfer takes 5 days during which the current registrar can oppose it (if it does nothing, the transfer get approved, but can also be explicitely expedited before it if the current registrar sends the appropriate command to the registry, some of them did provide this feature to their customers); so transfers could be blocked, but only during this 5 days period
- in parallel, RRP got progressively replaced by EPP (see STD69); in this protocol the transfer goes a little differently: the idea is that each domain name has a "password", called
authInfo in the protocol, defined at creation time (and later updated as wanted) and normally under control of the registrant (which was in fact not really what happened on the field, registrars often took care of it just by themselves); the transfer command required the prospective registrar to send the
authInfo along with the domain name, the idea being that the prospective registrar got hold of this "password" because the person starting the transfer would either been the registrant or somone having received the
authInfo as given by the registrant
- even with this newer protection, the ICANN policy did not change, and hence registrars will still contractually mandated to send and get positive authorizations by email before even attempting the transfer, and even if they got the
authInfo (this would still be mandatory by the protocol).
Even with all of these "protections", it happened on the field that "many" domains got stolen for various reasons, and people doing so went from one registrar to another, which made both the investigations and the eventual cancellation of the operations complicated because if a domain went from X to Y then Z, the resolution could not be done from Z back to X, it would still need to involve Y, so that made things long and complicated.
Hence the 60 days blackout after any creation or transfer: it gives the registrant that think its domain has been stolen enough time to contact the registrar to at least freeze the domain while investigating the dispute, before the domain name moves again.
This ICANN policy is detailed here: https://www.icann.org/resources/pages/registrars/transfers-en
(and, as a consensus policy, it applies immediately and without the need of explicit reference anywhere, to any registrar or registry accredited by ICANN, so this concerns gTLDs only).
Only very recently (December 2016) did ICANN extend its policy also to registrant change, especially its email.
You can view the redline here: https://www.icann.org/en/system/files/files/transfer-policy-redline-25may16-en.pdf
Note that, contratry to the delay after transfer/creation, the delay after registrant change is an opt-out, so the registrar can forfeit it if the customers ask for it.
Why did ICANN add that? Because otherwise you have a clear loophole as the whole procedure above depends on the current registrant (or administrative contact) to reply to some email to allow to start the transfer.
Imagine you want to steal some domain like that: you need both the
authInfo code (to give to the future registrar) and to control the email address to be able to reply to the "FOA" (the formatted email to gather authorization). By default, you can not. But if you find a way to connect to the registrar panel with the correct authorization (by any kind of other attack, like a phishing one), you could change the correct registrant which gives you two things:
- first you will easily be able to get the
authInfo code, as all registrars have a system to give that to the current registrant
- then, you could put any kind of email you want, so that you are able to receive there the FOA and reply to it.
If all of the previous succeeds you can start the transfer. And this will be difficult to troubleshoot if the former registrant suddenly complains because there are 5 parties involved: the registry (the policy allows the registry to have a role in handling disputes about transfers), the former registrar, the new registrar, the current registrant, and the previous one.
Now, with the newest ICANN policy, even if you manage to change the registrant information, you will need to wait 60 days to start the transfer.
Again, this gives more time for the former registrant to detect there was a problem (the registrar may have notified him that something changed on its account, or for advanced users they may monitor the whois output and see there a difference...), and to correct it. Or at least to freeze the transfer, to make sure the problems do not get worse.
For a final point, note that all of this can change in the near future and come back to some saner setup, like at the beginning (piling policies and protocols one of top of the other to resolve a problem gives you only more problems). Newer European regulations (GDPR) have an impact on both whois and transfers. In short the consequence is that it makes very hard for a prospective registrar to send email to the current holder and get its approval. ICANN's current proposal on the table is to use RDAP tiered access for it, which might work but will certainly take time and is indeed more of a workaround around a broken system than really a revamp of the system (and previous attempts by ICANN to change the whole system were going in directions even more wrong, such as creating a global whois content repository). Another solution was put on the table by some working group inside ICANN: https://www.icann.org/en/system/files/files/gdpr-comments-contract-party-techops-icann-proposed-compliance-models-08mar18-en.pdf
In short, it will mandate the current registrar, not the prospective one to get acknowledgement from the current holder. The prospective registrar would just need to start the transfer, again and still with the
authInfo required by the protocol and retrieved from the customer starting the transfer.