[GNSO-TPR] Notes and action items - TPR WG Meeting #44 - 26 April 2022 at 16:00 UTC

Dear TPR WG Members, Please find below the notes and action items from today’s meeting. The next TPR WG meeting will be on Tuesday, 03 May 2022 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: Discussion of Outstanding Items on TAC: 1. Recommendation 7 (TAC Security) Jim Galvin to suggest revisions to Sarah Wyld’s suggested text for WG members to review. 2.. Additional Candidate Recommendation xx under CQ b1 -- Staff to delete the recommendation. 3. Formerly Recommendation 6, now Recommendation 9: SME input on Recommendation 6.2: Jim Galvin to suggest some functional language for WG review. 4. Recommendation 13 --- Jim Galvin and Rick Wilhelm to consult with the RySG and either provide suggested alternative language or a rationale for why this recommendation should not be included. Previous Action Items: 1. WG members are encouraged to review the overview of proposed response to Charter Question h2 (see page 13 and 14 here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1L2bZnhJUY3Vxy...>) and provide comments and/or suggestions. 2. WG members are encouraged to review the overview of proposed responses to EPDP Phase 1, Recommendation 27 “Wave 1” Report items (see document here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1ZLkSqD2bHDBoQ...>) and add comments in the column “Additional Notes/Discussion”. 3. Staff to suggest a definition along the lines of Designated Agent as referenced in the COR. Could say, “Working Group understands the Designated Representative to mean an individual or entity that the Registered Name Holder explicitly authorizes to obtain the TAC on their behalf.” Notes: Transfer Policy Review Phase 1 - Meeting #44 Tuesday, 26 April 2022 at 16:00 UTC Proposed Agenda 1. Roll Call & SOI updates 2. Welcome & Chair updates * Next few weeks will have quite a bit of reading in between our regular sessions. Staff are ramping up production of our documents for review. * Good time to touch base with your SGs/Cs so that if anyone has any comments or concerns let’s get them documented over the next two or three weeks, so that we can get the Initial Report wrapped up. 3. Upcoming milestones and deliverables for Initial Report: Initial Report Delivery 15 June 2022: * To the extent that SO/AC/SG/Cs want to provide input on the proposed recommendations to be included in the Initial Report, now is the time to provide that input through their members. * Members should be coordinating with the groups they represent. * If unable to provide input in the next three weeks, SO/AC/SG/Cs will have an additional opportunity to provide input during the public comment period on the Initial Report. Key Dates: * 29 April: Working Group members receive full draft of Initial Report for review. * 14 May: Deadline for member input on full draft of Initial Report. * 2 June: Community Webinar on Initial Report proposed recommendations. * 15 June: Publication on Initial Report for public comment. Upcoming Working Group Meetings: 3 May 2022 NACK 10 May 2022 Post-registration and post-transfer locks; Additional security measures 17 May 2022 Review of outstanding items 24 May 2022 Review of outstanding items 31 May 2022 Review of outstanding items 7 June 2022 Review of outstanding items 13 June 2022 ICANN74 session – Introduction to Change of Registrant (COR) - Phase 1(b) Highlights: * Highlight the fact that this is an Initial Report so there will be the opportunity to provide comments during the public comment period, if not before. Preferably WG members should liaise with their groups and provide any comments or concerns before the Initial Report is finalized. * Staff sent draft recommendations and the boilerplate language for the Initial Report for review. Can use line numbers to reference. * 29 April: WG members to receive full draft of the Initial Report for review for two weeks. * The two weeks are for the big type of items in the draft recommendations that the WG has been discussing for a while and the WG members should have been liaising on these during discussions, not at the end of discussions. * Note that we are avoiding using the term “lock” but instead referencing a restriction on transfers. 4. Discussion of Outstanding Items on TAC (see summary in tab 1 here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1VAeYHzXuA...> and working document pages 15-19 here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPof...>) Row 11 -- Formerly Recommendation 3, now Recommendation 7 -- From Sarah Wyld, suggested text for Recommendation 7 (TAC Security) – See recent email: Here is the current shared draft text [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPof...>: The Working Group recommends that ICANN org establish minimum requirements for the composition of the TAC (for example, minimum length, syntax, or entropy value) based on current applicable technical security standards. ICANN org may change these requirements in response to new or updated standards, but any changes to the requirements must go in effect with sufficient notification and time for contracted parties to implement the necessary updates. Here is my suggested updated version: The Working Group recommends that Registrars and Registry Operators follow best practices for the composition of the TAC (for example, minimum length, syntax, or entropy value) based on current applicable technical security standards such as RFC9154 or subsequent or similar RFCs. These best practices may be updated in response to new or updated standards as appropriate. Discussion: * Remove ICANN org as setting the standard? Who is in charge of updating/maintaining the best practices? * How to use the RFCs and keep them updated? * There are two things going on – like the text in principle but it needs to be split. Jim Galvin will propose some text. First, concerns around how randomness is done and to capture that properly. The other thing with 9154 is it is about being able to exchange the new TAC value between the registrar and registry, as well as TAC management (with reference to randomness RFC 4086). This is a technical issue that we need to call out. WG members should consider this. See RFC 9154 at: https://datatracker.ietf.org/doc/html/rfc9154#section-4.3. * Need to think about enforceability or compliance. How would ICANN org make sure that contracted parties are meeting the requirements of best practices. Needs to be enforceable. * Maybe there should be some mention that ICANN org could moderate? * Not sure that every requirement in contracts is testable by compliance. * Question: Don’t think we’ve settled yet on the issue of one TAC per domain name. Talked about multiple/bulk transfers – did we settle on having on TAC per package? Answer: We have settled on one TAC per domain; have some language to consider from Sarah on one TAC per package, so this is still an open item. * Need to make sure that we highlight the security implications of having one TAC per multi-domain transfer. * There is a gray area of implementation of technical standards. There is no specific enforcement of RFCs, so not sure what ICANN org could do if there was a transfer incident. * We can ask Steve Crocker on behalf of the SSAC, but they don’t really have a process to provide quick input on random topics. We need to be careful because these are commercial topics that impact the registry/registrar businesses. Maybe get feedback from TechOps and then see if there is an open item. * Might need to make clear if there isn’t agreement that this isn’t a consensus policy. * As a reminder, we are pointing to this recommendation as part of the justification for removing requirements for the Losing and Gaining FOA. ACTION ITEMS: Recommendation 7 (TAC Security) Jim Galvin to suggest revisions to Sarah Wyld’s suggested text for WG members to review. Row 12 -- Additional Candidate Recommendation xx under CQ b1: If a Gaining Registrar requests a transfer and an inter-registrar transfer lock is in place, the transfer must not proceed. * Don’t think we need a recommendation on this. * Question: Are we talking about ClientTransferProhibited or ServerTransferProhibited? Answer: Maybe both? * Question: Thought that registry locks were out of scope? Answer: It shouldn’t matter – it’s up to the registrar to resolve the lock. * Shouldn’t use the word “stop”. * We do have a recommendation in denial of transfers/NACKing that could address this – but that is on the sponsoring side, not the gaining side. * If a registry lock is out of scope then there can’t be a recommendation that says if there is a registry lock then you can’t transfer. * Think that there is some agreement for dropping this recommendation. ACTION ITEM: Additional Candidate Recommendation xx under CQ b1 -- Staff to delete the recommendation. Row 13 -- Response to CQ b2: Compliance input: For Contractual Compliance to be able to enforce the requirements, all requirements must be clearly enumerated and described within the text of the policy. * This is a general comment. * No need to revise. Row 14 -- SME input on Recommendation 6.2: The Registry MUST securely store the TAC per the requirements specified in recommendation 3. Recommendation text: “When the Registrar of Record sets the TAC at the Registry, the Registry MUST securely store the TAC using a one-way hash that protects the TAC from disclosure.” * Misunderstanding in reading the recommendation – no need for a change to the recommendation. * One-way hash means the registry stores it, but can’t recover it. * Including the specific requirement of a “one-way hash” is inconsistent with the goal to not be prescriptive. We don’t go into details in other handling of the TAC. * Suggested language from Jim Galvin: “the policy should speak to the functional requirement of cryptographically protecting the TAC such that its value cannot be recovered or disclosed once stored.” * #2 gets into more detail. And there are also security requirements for TAC handling that (should) exist for registrars. ACTION ITEM: Formerly Recommendation 6, now Recommendation 9: SME input on Recommendation 6.2: Jim Galvin to suggest some functional language for WG review. Row 15 -- input on Recommendation 6.3: Compliance recommends detailing how this information must be provided and that the provision of this information must be documented. Recommendation text: “When the Registrar of Record provides the TAC to the RNH or their designated representative, the Registrar of Record MUST also provide information about when the TAC will expire.” * Don’t have to tell the Registrar of Record how they have to track when the TAC will expire. So no recording requirement. * No need for changes to the recommendation. Row 16 -- SME input on Recommendation 6.3: Consider developing standard easy to understand language for registrants around this additional info about when the TAC will expire, etc. * No need for changes to the recommendation. Row 17 -- Formerly Recommendation 9, now Recommendation 11: Compliance input: If this is an obligation to be added to the Transfer Policy for registries, Compliance recommends that the text in the policy explains what “clear” means (what actions this entails) so that Compliance is able to enforce it against registries where applicable. Recommendation text: “The working group recommends that the TAC MUST be “one-time use.” In other words, it MUST be used no more than once per domain name. The Registry Operator MUST clear the TAC as part of completing the successful transfer request.” * It should be clear to the RNH, but the registrar can figure out how best to explain it. * No need for changes to the recommendation. Row 18 -- Formerly Recommendation 11, now Recommendation 13: SME input on Recommendation 11.1: Suggestion to use hours instead of calendar days to avoid confusion. Recommendation text: 13.1: A standard Time to Live (TTL) for the TAC MUST be 14 calendar days from the time it is set at the Registry, enforced by the Registries. 13.2: The Registrar of Record MAY set the TAC to null: · At any time in response to a request from the RNH. · After a period of less than 14 days by agreement by the Registrar of Record and the RNH. * Not sure when we settled on this text with respect to registries. The problem is that one of two things have to be true: registrars won’t have any information why this failed, and someone will have to do some research. You will want to talk to the registry to see what happens, but this means that the registry will have to keep logs. Don’t think registries are comfortable with this. * Another alternative if the registries could reject a transfer if the user didn’t provide an AuthInfo code or presented an expired TAC, then they would have to track the time stamp and reason rejection. ACTION ITEM: Recommendation 13 --- Jim Galvin and Rick Wilhelm to consult with the RySG and either provide suggested alternative language or a rationale for why this recommendation should not be included. 5. AOB * Next call: Tuesday 3 May 2022 at 16:00 UTC