2021-08-10 Transfer Policy Review PDP WG Call

Notes/ Action Items

Action Items

ACTION ITEM: WG members to review/comment on the Losing FOA Working Document [docs.google.com] in preparation for the meeting on Tuesday, 17 August. 

Also see the project workplan [docs.google.com] for action items.

Notes:

Transfer Policy Review Phase 1 - Meeting #12 – Tuesday, 03 August at 16:00 UTC

Proposed Agenda

1. Roll Call & SOI Updates (5 minutes)
2. Welcome & Chair updates (5 minutes)

• Staff sent out the updated Project Plan last week.  Let us know if you have any questions or comments on it.
• Calendar invites have been sent for meetings through October 2021.

      3. Continued discussion of AuthInfo Codes (15 minutes): Focus relevant SO/AC/SG/C written input: See -- AuthInfo Codes working document [docs.google.com] and Early Input:

• One piece to comment on is that there is a new standard out raised by a security organization on using dictionary words.  That you could use three different dictionary words in a string and it would be just as secure.  See: Link on password strength (related to Auth-Info) I mentioned in call https://www.ncsc.gov.uk/blog-post/the-logic-behind-three-random-words [ncsc.gov.uk].
• Didn’t see anything new that the WG hasn’t already discussed.
• Mark this AuthInfo discussion as complete for now.

      4. Discussion of Losing FOA (60 minutes):  See – Losing FOA Working Document [docs.google.com]:

Charter Questions:

Note: In answering this question, the Staff Support Team has included feedback from the Registrar/Registrant Survey that was issued as part of the Transfer Policy Policy Status Report. Additionally, the Support Staff Team has included a non-exhaustive list of sub-questions for the WG to consider. 
Early Written Input received from the BC on this charter question: Although apparently not necessary from a practical perspective, the Losing FOA may have some utility as a means of evidencing a transfer.

Discussion:

• Seems to be working without the losing FOA since GDPR.  .NL we don’t use FOAs at all.
• If it’s not broken, just leave it as it is and let the registrars make that decision.
• Delays transfer for up to 5 days, so nice that it could be optional – particularly if we could do it faster.  Would like to leave it optional if the registrar thinks it’s necessary for its registrant.
• Reminder that there is a gaining FOA that a gaining registrar used to send to confirm their desire to transfer; the losing FOA was a form of acknowledgement of intent to transfer.  The current transfer mechanism identifies those two steps. 
• The losing FOA is required today but a change we make could be to make it optional.
• The thing to avoid here if we eliminated it or made it option if there was no form of awareness to stop a legitimate transfer.  Should eliminate that there is some notice and means to decline in order to avoid having a registrant’s name transferred away under non-normal circumstances.
• A fourth option: we could think about how to make it better – to require that it is as easy to accept the transfer as to deny it.
• Think about the losing FOA to acknowledge that there is an intent to transfer.  Think about the purpose of the losing FOA: you can meet the needs with the AuthInfo code, for example.  Question is: what are we looking to achieve here?  The purpose of the losing FOA.
• Where the FOA is the second factor of protection, the losing FOA email in many cases serves as a means for the registrant to know the transfer occurred (or may occur) vs a silently vanishing name.
• If you drill down you will find registrars using it for right and wrong reasons, so that argues for making it optional.  For example, could be easier to explain for Dutch registrants as it would be similar to what we are doing now.
• If the losing FOA is eliminated, then make sure that the registrars could have 5 days to determine if this is a fraudulent request or not.
• Also, if the losing FOA is eliminated would like some way to get the domain name back if the registrar notifies that it is transferred erroneously.

---

Additional questions for consideration (from the working document):

• Should the five-day grace period remain or should the timeframe be reconsidered?
• Is the current text of the Losing FOA sufficient or does it require updating?
• Similar to the Gaining FOA, should the Losing FOA require express authorization/confirmation of the transfer?
• Some registrar survey respondents have noted that the Losing FOA provides a useful paper trail - is this important to retain, or is there an alternative way to achieve this? 
• Is there another security mechanism that should be included with the Losing FOA in the event the registrant’s email address is hacked?

----

• The 5 days in the current process – how long do you go before finding out that the name has been transferred if the losing FOA goes away?
• ICANN Org Compliance: The investigation of the transfer complaint – the main burden for evidence is on the losing registrar at that FOA (since the gaining FOA is not being used).
• We do have a discussion later around the dispute mechanism/process.
• More questions: What problem are we trying to solve?  What has failed when it is necessary for a transfer to be recalled?  Is it that the transfer itself was bad?  Or did the transfer process work as it was supposed to but there is an external reason to recall the transfer?  That factors into how easy or hard the transfer has to be or what the recovery process will be.
• Don’t think there is a failure in the transfer process, but is an external failure.
• When a domain hasn’t been properly transferred, it’s because an account was compromised, but not a failure of the transfer process, so we may not find a solution in the transfer policy.
• There is no process that is so secure that it can never be bypassed.
• To take that a step further, if the registrant has lost control of their email, as well as their registrar account, does the Losing FOA help at all?
• We do need a process for recovery, so in that way there should be a way to internalize it.  The question is whether the transfer process has to protect against email compromise or registrant account compromise.
• There are numerous cases where we can’t protect everyone – so maybe the transfer process isn’t the place to find a solution.
• Going back to the original question – this seems to be a second factor of protection, so we need to decide whether it is the best/right second factor of protection.
• +1 on better recourse for 'clawback' under bad-act situations, however, there is also a need to have some finality to legitimate transfers.  There are ways that bad-folk could abuse the clawback process (ex bad outcome scenario: 1] legitimate domain sale to third party, 2] money exchanges, 3] name transfers, 4] clawback + keep money).
• It sounds like it’s a necessary thing, if not exactly what we have today.  Maybe that doesn’t mean that the transfer process gets more secure, but maybe we change the dispute procedure.
• How often is a “clawback” required?  Does this require additional security measures, or would the dispute procedures solve that?
• Security and the need for secure is a holistic type of problem.  We want transfers to be secure, but that doesn’t mean that the transfer process has to solve every problem.  If a registrant’s account at a registrar there is nothing we can do about that, unless you have other types of security controls, such as second factor authentication.
• Even if the transfer process works the way it should be, there still could be other security failures.
• The SSAC’s input references SAC007, SAC040, SAC044, and SAC074.  You can find these four reports here:https://www.icann.org/groups/ssac/documents.
• The registrar account: the account holder with the registrar may not be the registrant – it could be an entity doing something on behalf of the registrant.  In this context: if there is an authorization to allow a registration to transfer, it might be coming from a third party, or from the registrant, but either way the registrant has to be notified quickly and reliably.
• Looking through the additional questions it looks like we have hit on most of these.
• Need to continue to discuss whether the policy should be changed to make the losing FOA and whether that might make compliance harder/slower.  People are still looking at keeping a 5-day window, but not necessarily as part of the losing FOA, but perhaps part of the TAC.
• Or, are there any requirements we would make in additional to the current ones?
• In terms of gauging people’s reactions on whether the losing FOA should be optional: seems that we could put the emphasis on an improved dispute mechanism that addresses thefts.
• Could look at the transfer dispute mechanism to see if we can improve that process.
• Note that the TDRP (transfer dispute mechanism process) was hardly used.  In general, the procedure itself is between the gaining and losing registrars.  Only used when the registrant has exhausted all other options to recover the domain.  We’ll take a closer look at it in phase 2.  The WG can look at it in phase 1 and suggest some pointers for phase 2.
• In terms of changing the existing requirement of the losing FOA:  The losing and gaining FOA are requirements.  There is a moratorium on the gaining FOA, but the losing FOA is a requirement so it will take consensus to change it.
• The paper trail is an important factors – helpful for the registrars to give examples of logging of transfers that could be used for investigating fraudulent transfers.
• Today it’s the losing registrar’s responsibility to prove everything.  Is that responsibility in the correct spot, or should the gaining registrar have any responsibility?

Note: As a starting point, the CPH Tech Ops Group “agreed that the requirement to notify the Registrant about a transfer request should be mandatory. As general business practices of Registrars and individual transfer scenarios vary, the group concluded that such notification does not have to be an email, but rather may incorporate other means of more modern communication.”

Early Written Input received from the BC on this charter question: Good starting point.

• What are you trying to achieve by notifying the registrant?  If you get the AuthInfo Code that is a form of notification.  What does this notification add to the process?

• It is possible to obtain the AuthInfo Code other than with an email request, so the notification is another way for the registrant to be aware.  The objective is to ensure that a domain doesn’t just silently vanish.

• Note that Tech Ops concluded that the notification doesn’t have to be in an email.

• Notification to registrant by gaining registrar (if different than the gaining registrant) was severely complicated by the GDPR _stuff_.

• The question asked “does it provide sufficient security for registered name holders”.  Nothing wrong with the additional level of notification, but from a risk management point of view, what are we really getting here?  The losing registrar has to send it and if the losing registrar is behaving badly what is the point of having this requirement, or in cases where the registrar’s account is compromised.

• Notification can be affected differently by thick or thin registries.  Our suggestions/recommendations should be agnostic (not assuming) one or another.

• What are we trying to solve here?  The notification brings little to the table.

Early Written Input received from the BC on this charter question: Transfer locks should be removable by the registrant.

• As mentioned, where thin registry is in place, the registrant (and contact info) are known to registry… at thick registries but not at thin.
• On the BC comment – the opportunity to opt out should be made more clear to registrants, registries, etc.
• It is the registrant who had to remove a transfer lock, not the registry.
• Question: Do we need to specify what is a transfer lock?  Answer: We need to be specific.  Which transfer lock we are mentioning.

      5. AOB (5 minutes)

• Next meeting: 17 August 2021 @ 16.00 UTC