2021-06-16 Transfer Policy Review PDP Call - ICANN71

Notes/ Action Items

Action Items

Please refer to the Work Plan and Action Items List [docs.google.com] for updated action items.

1. Discussion of Policy Goals

See the Jamboard at: https://jamboard.google.com/d/1atFQTx8qQbeiWqF1aMdAUkgaVNz7r57COA61nMXvIA4/viewer?f=0 [jamboard.google.com]

Policy Goals Brainstorm:

Policy Goals for Previous Policy Development Work:

• Enable registered name holders to move their domain names to a new provider, thereby increasing consumer choice and competition;
• Ensure the IRTP includes sufficient protections to prevent fraudulent domain name transfers and domain name hijacking;
• Clarify the language of the IRTP so that ICANN-accredited registrars consistently interpret and apply the policy;
• Clarify the language and visibility of the Transfer Dispute Resolution Policy so that providers/panelists consistently interpret and apply the policy.

Additional Goals:

• DNSSEC transfer has a role in mitigating domain name hijacking.  We should clarify this and define guidelines for DNS transfer during registration transfer.
• Efficient/ registrant-friendly transfer?

Second Goal:

-- Question Re: “to prevent fraudulent domain name transfers and domain name hijacking” – are these the same or different?

-- Want to prevent bad transfers, but facilitate good ones.

-- Maybe remove “and domain name hijacking”?

-- One well-known form of fraudulent transfer is slamming, i.e. misleading the customer in order to charge for overpriced services after transfer, but not actually hijack the domain.

ACTION ITEM: For the second goal, rewrite to: ““…prevent fraudulent domain name transfers, in particular to prevent the misuse of the transfer mechanism for domain name hijacking”.”

Fourth Goal:

-- Question: Why is this goal here? Answer: Before the IRTP there was no efficiency.  It is better now, but still needs improvement.

-- Question: How do we know when we achieve this goal?  Answer: We can tie a charter question back to the specific goal.

New goal on DNSSEC:

-- On DNSSEC, you almost always have to transfer the domain service when you transfer the domain name.  How to make this efficient and cost effective.

-- I think the positive goal (facilitate valid transfers) is captured in the first green box, so the second box still seems to me to contain redundancy. I propose we remove "and domain name hijacking".

-- It’s not clear why DNSSEC should be a goal of this PDP, as it was not something identified in the issues report. Maybe consider it later after we’ve considered other items in our charter?

-- It does sound like DNSSEC transfer is more of a technical concern than a policy one.

-- Maybe we all should work/establish at “best practice” document after the new IRTP is settled. This “best practice” should obviously include transfers of signed zone.

-- There is a country code solution in the Netherlands, but for gTLDs the registry is not involved.  Keys have to be available in the new and old locations.  There are a variety of reasons for why there is a loss of service during transfer for DNSSEC services.

-- Is making DNS service transfers in scope of this PDP?

-- Maybe it is important to keep an explicit reference to domain hijacking even if not all fraudulent transfers are hijacking, and not all hijackings are by way of domain transfer. So the phrase could we worded as follows: “prevent fraudulent domain name transfers, in particular to prevent the misuse of the transfer mechanism for domain name hijacking”.

-- Issue comes up if you are moving from one registrar to another and also changing the name service.  If gaining registrar wants to continue the name service it needs the cooperation of the losing registrar if it is offering the name service.

-- Change of registrant might also cause unwanted DNSSEC disruption if the new registrant runs a successor service instead of a new service with the same domain name.

-- But, you could change the name service before the registrar transfer, so these could be separate operations.

-- From the Registrant point of view it is a concern if DNSSEC implies a disruption in the transfer. Thus, a clear statement needs to be in place when the parties explore the transfer.

-- DNSSEC, if implemented correctly, CAN be used as a way to ensure strong authentication that replaces less safe forms of authentication based on email. As a result, removing DNSSEC from the scope would deprive the community of improvements to the transfer process that can only be based on DNSSEC. So it might be good to keep DNSSEC part of the scope, but ensure solutions are available in the absence of DNSSEC too.

SUMMARY: This issue (domain name service transfer) is not part of the charter.  DNSSEC service transfer is important but we aren’t going to solve it here.

CPH TechOps Principles:

• The transfer process must comply with current data privacy regulations
• The transfer process must be instant, but with enough time to validate the legitimacy of a transfer
• A transfer token shall be sufficient to authorize a transfer
• No personal data shall be transferred from the old to the new registrar
• The existing gTLD transfer policy should be changed as little as possible

Second Principle:

-- Re: “The transfer process must be instant, but with enough time to validate the legitimacy of a transfer” – note that this is the entire process from beginning to the end.  Need to qualify that it should be “as efficient as possible”.

-- Seems clear what “instant” means – could change the language to say that the “transfer should be processed” instantly.  Update to be more specific.

-- Is the “instant transfer” a high-level goal, or is that a piece of a high-level goal.

ACTION ITEM: Rewrite the second principle to a high-level goal that the “The transfer shall be processed as efficiently as possible.”

Third Principle:

-- The principle “A transfer token shall be sufficient to authorize a transfer” is too overreaching. There can be very good reason to say that it is necessary but not sufficient. In particular, a well-organize transfer involves proactive cooperation between gaining and losing registrar, rather than a dangerous event for which the losing registrar is unprepared. If we just forget our old habits for a moment, we can see that allowing a concept of “backup registrar” or “primary sponsoring registrar plus secondary sponsoring registrar” would go a long way to make transfers much more secure.

-- This may be too broad.

Fourth Principle:

-- Re: “No personal data shall be transferred from the old to the new registrar” – not sure we need this.  Not sure we need to restrict this.

-- Add “Policy shall not require”?

Fifth Principle:

-- Re: “The existing gTLD transfer policy should be changed as little as possible” – think this one can be removed.

-- Originally the goal was to provide as much security and thought without changing the policy a lot.  We are here to look at it as a whole and change what is needed.

-- Maybe not appropriate for this PDP.

       2. Discussion of Charter Topic 4 – AuthInfo Code Management

See: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0AK00/edit [docs.google.com]

Charter Questions:

b1) Is AuthInfo Code still a secure method for inter-registrar transfers? What evidence was used by the Working Group to make this determination?

-- Answer to the question is “not today, but it could be”.  There are certain security principles that aren’t being protected.

-- Compliance is looking for data.  But this may not be intuitive to inform the question of how secure AuthInfo code is.  So we would need to go to the CPH.

-- Wondering if Compliance is looking at how many times TDRP has been used?

-- Need to come up with the policy or business definers to for TechOps to consider the questions – or those that are relevant.

-- Frame the questions to TechOps in context, such as that the goal of the AuthInfo code is to ensure that the registrant asking for the transfer is the same registrant who owns the domain.

-- The data/metrics from ICANN org is of importance. However, there are members of the PDP that have experience - and maybe data, from ccTLD transfers. These data could be handy to have.

-- It’s not the amount of complaints that we’re looking for, it’s the amount of unauthorized transfers that have been reversed.

-- Distinction for consider: what we are talking about here are the security requirements for the transfer.  That the transfer is authorized by the registrant and that the identity is confirmed by the AuthInfo code.  Or whether additional security requirements are necessary.   But the additional security requirements of the code are what allow the mechanism to achieve the goal – these two security issues should be separate.  1) mechanism, and 2) what to do with the mechanism to achieve the goal.

-- Precision is required here for any input we seek from TechOps/CPs.

-- The current AuthInfo functions much like a one-time password.  It is not fully implemented that way.

-- If we move down the path of wanting to depend on the Transfer Authorization Code (TAC), then we need to think carefully about its security requirements.

-- So this group may want to keep this in mind when formulating possible future recommendations of things that can be measured and data gathered from CPs to help measure the success of the new policy requirements.

-- The goal is to remove the FOAs and using a TAC/AuthCode, and making sure that the registrant asking for the transfer is the registrant authorized to do so.  Have to assume that when answering the questions, until that doesn’t work.

-- Is there an ask for the CPs coming out of this PDP to gather certain data?

-- The available evidence is a leading indicator, but it isn’t definitive.  Important to gather that information, but it won’t answer the question.  The experts here might be able to answer it or not.

-- There have been a lot of changes in the last three years to make the AuthCode more secure, so the data won’t tell the whole story.

-- AuthCodes have proved secure in the last three years, but need to ask for the data from TechOps to answer the question.

ACTION ITEMS:

1) Once the WG has clarified policy parameters for AuthInfo Codes, staff with the WG to draft letter to CPH TechOps asking for input on a technical solution (or technical solutions) to meet those parameters.

2) Staff with the WG to draft a survey to send to Registrars asking for  input and evidence/data regarding the security of AuthInfo Codes.

      3. Next Meeting 29 June 2021:

The WG will continue discussion on the charter questions at the next meeting, beginning with the following question.

B2) The registrar is currently the authoritative holder of the AuthInfo Code. Should this be maintained, or should the registry be the authoritative AuthInfo Code holder? Why?

As a starting point, the CPH Tech Ops Group concluded “to reach a uniform, transparent, and predictable process, Registries should be in control of the storage and processing of the AuthCode, regarding the technical part.”