Dear TPR WG members, Please find below the brief notes from today’s meeting. Please note that these brief notes are not a substitute for the recording or transcript. The next meeting will be on Tuesday, 04 October at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Notes: Transfer Policy Review – ICANN75 Session Proposed Agenda 17 September 2022 1. Welcome 2. PDP Introduction and Status * Not going to go through everything; just to give you some background to follow. * See the slides at: https://community.icann.org/download/attachments/208208420/Transfer%20Policy%20PDP%20-%20ICANN75.pdf?version=1&modificationDate=1663093458000&api=v2 3. Discussion of Public Comments<https://community.icann.org/display/TPRPDP/Phase+1A+-+Public+Comment+Review+Tool> on the Working Group's Phase 1A Initial Report [itp.cdn.icann.org]<https://urldefense.com/v3/__https:/itp.cdn.icann.org/en/files/inter-registrar-transfer-policy-irtp/transfer-policy-review-initial-report-21-06-2022-en.pdf__;!!PtGJab4!5BpERb5gGHoqUmiGpDMUO63lr3vG4KKtiNY995SjMeuNNW0YkMkXLnww7vtca9dWg0XWkaXYmbBJOwlKnCsbdHt4j8AAsD-gVg$> * Focus: Recommendation 1 to Eliminate the Gaining Form of Authorization and Recommendation 2 to Eliminate the Losing Form of Authorization (FOA) * Materials to review for this discussion: Pages 12-18 of the Working Group’s Phase 1A Initial Report [itp.cdn.icann.org]<https://urldefense.com/v3/__https:/itp.cdn.icann.org/en/files/inter-registrar-transfer-policy-irtp/transfer-policy-review-initial-report-21-06-2022-en.pdf__;!!PtGJab4!5BpERb5gGHoqUmiGpDMUO63lr3vG4KKtiNY995SjMeuNNW0YkMkXLnww7vtca9dWg0XWkaXYmbBJOwlKnCsbdHt4j8AAsD-gVg$> Recommendation 1 Public Comment Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1xBQpbMbbJgaBHth2fucmEElQTc-pbaqbQIkAYS_kHS0/edit__;!!PtGJab4!5BpERb5gGHoqUmiGpDMUO63lr3vG4KKtiNY995SjMeuNNW0YkMkXLnww7vtca9dWg0XWkaXYmbBJOwlKnCsbdHt4j8CihBsiaQ$> Recommendation 2 Public Comment Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1gyy9xfe0-ymW-irtY2gKSEy3za8IcG-GrF8EcCGE57g/edit__;!!PtGJab4!5BpERb5gGHoqUmiGpDMUO63lr3vG4KKtiNY995SjMeuNNW0YkMkXLnww7vtca9dWg0XWkaXYmbBJOwlKnCsbdHt4j8DVddRnCQ$> Public Comment Review Tool – Recommendation 1<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt-Initial-Report-Recommendations_Rec%201_20220829.docx?version=2&modificationDate=1661939450000&api=v2>: All Comments Public Comment Review Tool - Recommendation 2<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt-Initial-Report-Recommendations_Rec%202_20220829.docx?version=1&modificationDate=1661772796000&api=v2>: All Comments Public Comment Review Tool - Recommendation 3<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt-Initial-Report-Recommendations_Rec%203_20220829.docx?version=1&modificationDate=1661772946000&api=v2>: Comments #10, #11, #12 Public Comment Review Tool - Recommendation 4:<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt-Initial-Report-Recommendations_Rec%204_20220829.docx?version=1&modificationDate=1661772959000&api=v2> Comment #10 Public Comment Review Tool – Additional Input<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt-Initial-Report-General_20220829.docx?version=1&modificationDate=1661778347000&api=v2>: Comments #1-#11 Leap of Faith Financial Services Comment [itp.cdn.icann.org]<https://urldefense.com/v3/__https:/itp.cdn.icann.org/public-comment/proceeding/Initial*20Report*20on*20the*20Transfer*20Policy*20Review*20-*20Phase*201(a)-21-06-2022/submissions/Leap*20of*20Faith*20Financial*20Services*20Inc./LEAP-comments-Transfers-Phase1a-20220814-FINAL-15-08-2022.pdf__;JSUlJSUlJSUlJSUlJSU!!PtGJab4!5BpERb5gGHoqUmiGpDMUO63lr3vG4KKtiNY995SjMeuNNW0YkMkXLnww7vtca9dWg0XWkaXYmbBJOwlKnCsbdHt4j8DEZWBK0Q$> (full text, especially pages 11-24, 31-39) Summary of WG Discussion on 13 September: WG discussion and agreement: In initial discussions, working group members did not believe that the relevant comments present new information. Working group members expressed that the recommendations remain appropriate, but that the rationale for recommendation 2 should be augmented to fully explain why the recommended approach offers an appropriate level of security to registrants. Points to emphasize in rationale: · The first and most important line of defense and the primary point of control is logging into the account at the Registrar. This is the “affirmative consent” to initiate the transfer. · Once an attacker has logged into the control panel, they can change the points of contact, including who receives the FOA/notifications, eliminating the utility of the FOA/notifications in that scenario. This is true with FOA and will also be true with notifications. The properties of the two are very similar. · Additional security is provided in the recommended approach because the TAC is generated on demand and is therefore less vulnerable to theft. · The Losing Registrar still has 5 days to provision the TAC. As a business decision, the Registrar has the discretion to delay provision of the take additional steps including to perform due diligence during that window. Registrars will decide if and how to use that period based on their chosen approach as well as the type/value of the domain. Registrar due diligence can give extra protection to the registrant. Delayed provision of the TAC also gives registrants more time to respond to notifications, to the extent they are receiving notifications (attacker has not updated contact into). Registrants have the choice to pick a Registrar that fits their needs. · The proposed 30-day post-transfer lock helps to ensure that if a domain is stolen, domain hopping will be slowed, allowing the Losing and Gaining Registrars to work together to resolve the problem. This recommendation may prompt registrars to take a “backdoor security measure” by delaying the time between people asking for Transfer Authorization Codes (TACs) and issuing them to customers, which will ultimately burden domain registrants. They would not be able to complete the domain transfer process in one sitting. WG discussion and agreement: In initial discussions, WG members noted that they see optional delayed provision of the TAC as a feature, not a bug. · As a business decision, the Registrar has the discretion to delay provision of the take additional steps including to perform due diligence during that window. · Registrars will decide if and how to use that period based on their chosen approach as well as the type/value of the domain. · Registrar due diligence can give extra protection to the registrant. Delayed provision of the TAC also gives registrants more time to respond to notifications, to the extent they are receiving notifications (attacker has not updated contact into). Registrants have the choice to pick a Registrar that fits their needs. The authorization of Losing FOA should remain with the Registrant, not the Registrar. RFC 9154 is unequivocal: "A transfer is coordinated by the REGISTRANT to transfer the sponsorship of the object from one registrar to another." Any transfer coordinated by a losing registrar (or a gaining registrar), or registry, or anyone other than the REGISTRANT violates RFC 9154. WG discussion and agreement: One of the co-authors of RFC9154 who is a member of the WG disagreed with the commenter’s interpretation of the RFC. The RFC is not making a normative statement that would impose policy on the ICANN process. In addition, the registrant is still coordinating the process with the new proposed process, so the new process would be consistent with the RFC language. Measures to increase security of the TAC are insufficient to justify elimination of the Losing FOA. The TAC is an extremely valuable asset that is vulnerable to theft or use by third parties once it has been generated. The WG’s recommendations to strengthen elements of TAC security do not address this vulnerability. WG discussion and agreement: In initial discussion, members emphasized that with the new recommendations, the TAC will be generated on demand and will only be available for 14 days after being generated. This is significant improvement to the security of the TAC. While it is true that the TAC can be stolen once it has been generated, WG members noted that is the case in the current environment, as well. Additional data/reference points that the respondent believes the WG should review in considering retention of the Losing FOA: NACKed transfers as listed in TPSR, data on Canadian mobile phone number transfers/thefts, ARIN's procedures for the transfer of IP addresses, SSAC Advice: SAC040, SAC044, SAC074. WG discussion and agreement: In initial discussions, WG members noted that the number of NACKed transfers can’t be used to understand the number of domain thefts, because transfers are also NACKed for other reasons. Discussion of Leap of Faith Comments: Link to Leap of Faith Financial Services Comment [itp.cdn.icann.org]<https://urldefense.com/v3/__https:/itp.cdn.icann.org/public-comment/proceeding/Initial*20Report*20on*20the*20Transfer*20Policy*20Review*20-*20Phase*201(a)-21-06-2022/submissions/Leap*20of*20Faith*20Financial*20Services*20Inc./LEAP-comments-Transfers-Phase1a-20220814-FINAL-15-08-2022.pdf__;JSUlJSUlJSUlJSUlJSU!!PtGJab4!5BpERb5gGHoqUmiGpDMUO63lr3vG4KKtiNY995SjMeuNNW0YkMkXLnww7vtca9dWg0XWkaXYmbBJOwlKnCsbdHt4j8DEZWBK0Q$> (full text, especially pages 11-24, 31-39) * Keep the 5-day window that registrars can roll back – minimum standard for registrars. * Talked about when a request for a transfer is made that a notice has to be sent (mandatory). WG should consider whether this makes sense. * Also discussed having the gaining IANA ID. Would help know where it was going – asked this as a question in the public comments. * Need to retain the losing FOA --- once the TAC is generated the registrants are on their own. * Need to think about what we are talking about as a practical matter. The TAC is ephemeral. The TTL can be set to very low levels. Help registrants to restrict transfers. * The majority of the recommendations go together. * Comments center on the registrant no longer getting a 5-day window. * You could have an secure PTID that the domain is being transferred to. * Many registrants don’t log into their registrar very frequently, so lose the ability to NACK. * If we keep the existing approach and improve the rationale – see 2.2 existing text seems to suggest there is a means to NACK the transfer, but we may need to make it clear that while this is true, it is a very small window. But before that even happens is there a chance to stop it? The comments are getting to allowing the registrant to NACK the transfer – and making that window (to NACK, be it 5-day or otherwise) mandatory. * What is the argument against having some window that allows the registrant to NACK the transfer. * Give registrants the choice to have the losing FOA; this report suffers from lack of data – giving a choice would allow ICANN to see who opted in. * Question to George Kirikos: Would having a transfer window plus an embedded Gaining Registrar IANA ID be better than the WG’s current proposal? Answer: Yes to the IANA ID but not the transfer window. George’s breakthrough proposal is still preferable. * Just have a few options: 1) keep the recommendation as is with no changes; 2) keep the recommendation but provide better rationale to address the comments/concerns; 3) modify it so it supports what the commenters are proposing. * There are problems identifying the registrar from the embedded IANA ID for most registrants. * Problems would be eliminated if you “push” the ID. * It is a problem today that registrants don’t know where the transfer is going. * Might be that the WG members should look at what can happen at the gaining registrar. * Section E of George Kirikos proposal: Registrant would go to the Gaining Registrar that would create an ID (ends to a destination account, like a wire transfer), registrant would take that to the Losing Registrar and enter the name – still need to preserve the Losing FOA step. * Couldn’t someone still hack and get the ID? Yes, and that is why you need the Losing FOA. * But then the Losing FOA would go to the hacker. * Just need to create a somewhat secure transfer system because it seems that the security is in the multi-factor authentication, which is outside of the transfer policy. * Registries offer additional security mechanisms such as locks. 4. Wrap up