Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be on Thursday, 17 November at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: 1. Jothan Frakes, Jim Galvin, Jody Kolker, and Rick Wilhelm have volunteered to compile a list of attack vectors and how the recommendations solve for them, or where they are out of scope. Recommendation 6: 1. Staff to redline the language and include it as a sub-bullet in Recommendation 6. WG members to review with other redlines by Wednesday, 30 November. Recommendation 2: 1. WG members to review and comment on Strawman Revision of Recommendation 2 on the Losing FOA [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1e8iG6FmRD0M5V...> on the list by Wednesday, 30 November. Recommendation 7: 1. (c) Proposed edit -- WG agrees with the potential next step of changing the language from “should” to “MUST”. Staff to incorporate. WG members should review and comment. Recommendation 8 1. (a) Proposed Edit -- WG agrees with the potential next step strawman revision. Staff to incorporate. 2. (b) Proposed Edit – WG agrees with the potential next step strawman revision. Staff to incorporate. Recommendation 9: 1. (b) Proposed edit -- WG agrees with the suggested language in the Potential next step. Staff to incorporate. Notes: Transfer Policy Review - Meeting #66 Proposed Agenda 15 November 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates Recommendation 6: Potential next step: Strawman revision: "Designated representative" means an individual or entity that the Registered Name Holder explicitly authorizes to request and obtain the TAC on their behalf.” Discussion: * Re: the recent discussion on “Designated Representative” perhaps suggest instead “Authorized Representative”? Or another term. * Maybe just don’t define “Designated Representative”? * From ICANN org Compliance: Suggestion is to be more clear about the Designated Representative’s authority. Issue of resellers including language of authorizing and denying transfers. Compliance has been able to obtain remediation in these cases, based on definitions in the policy – the more clear the policy is on definitions and authority for transfers, the better can Compliance enforce the policy. Recommends that the definition should be included in the text of the policy. * Some disagree to change the language to include in the policy – RNH should have to abide by the terms agreed to with the reseller with respect to authorizing or denying transfers. * Some agree that the authorization should be clear in the policy. * Keep “Designated Agent” separate. Compliance spoke of “Designated Agent” in the COR as an analogy only. “Designated Agent” is a separate concept/use case. * There was some agreement on the last call to adjust the meaning of the Designated Representative to include “request and obtain”. Also to pull out from the footnote into the policy but as a sub-bullet in Recommendation 6. * Redline of changes to recommendations thus far from discussion of public comments will be out soon – allow two weeks to review, by Wednesday, 30 November. ACTION ITEM: Recommendation 6 -- Staff to redline the language and include it as a sub-bullet in Recommendation 6. WG members to review with other redlines by Wednesday, 30 November. 3. Review of Strawman Revision of Recommendation 2 on the Losing FOA [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1e8iG6FmRD0M5V...> * WG agreement in previous discussions to preserve the functionality of the Losing FOA and consider where best to put it. * Keep the 5-day provisioning window flexible. That’s what this strawman is doing. * WG has two weeks to review this strawman text. ACTION ITEM: Recommendation 2 -- WG members to review and comment on Strawman Revision of Recommendation 2 on the Losing FOA [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1e8iG6FmRD0M5V...> on the list by Wednesday, 30 November. 4. Continue Discussion of TAC Composition – Recommendation 7 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> and Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1796UeXK6GspA7...>) Re: a) Concerns -- Discussion: * RFC9154 is only a guidance/principle – NIS2 will cover a lot of this with high requirements on how you set up security as a European company, including auditing capability; so we don’t have to do all of that. * Important to recognize that we aren’t using everything in RFC9154. * We have left the choice of mechanism for communication up to registrars, not specifying it in the policy. * RFC9154 doesn’t include auditing – but that’s not part of any technical specifications, not a limitation; we can add auditing provisions to the recommendations if we wish. * Reasonable for registrars to think back about what is the minimum from a security standard that we should have – which elements are mandatory and which are optional? Some of these security elements can be left up to the business model. * From a technical point of view you can’t just start eliminating characters – have an algorithm that has been reviewed and accepted – can’t just change it. Re: b) Proposed edit -- Discussion: * After review of Tech Ops discussion, WG doesn’t recommend any changes. Re: c) Proposed edit – Discussion: Potential next step: Strawman revision from ICANN org comment: “The working group recommends that the minimum requirements for the composition of a TAC MUST be as specified in RFC 9154, including all successor standards, modifications or additions thereto relating to Secure Authorization Information for Transfer. The requirement in section 4.1 of RFC 9154 regarding the minimum bits of entropy (i.e., 128 bits) should be a MUST in the policy until a future RFC approved as “Internet Standards” (as opposed to Informational or Experimental standards) through the applicable IETF processes updates the security recommendation.” * Hinges on the meaning of the word “should”. * Using “MUST” means it’s something you have to do; “should” is something you are urged to do, but don’t have to do it. ACTION ITEM: Recommendation 7, (c) Proposed edit -- WG agrees with the potential next step of changing the language from “should” to “MUST”. Staff to incorporate. WG members should review and comment. Re: d) Proposed edit – Discussion: * Think about whether the current language is sufficiently clear. * Seems like we don’t want to include this in our policy – the IETF is taking care of it. * WG members agree that no further clarification is necessary. 5. Discussion of Verification of TAC Composition – Recommendation 8 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> and Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1gUoQQ-YpnjOO_...>) Re: a) Proposed edit – Discussion: Potential next step: Strawman revision: “The working group recommends that the Registry verifies at the time that the TAC is stored in the Registry system that the TAC meets the syntax requirements specified in Preliminary Recommendation 7.” * WG agrees with the suggested change. ACTION ITEM: Recommendation 8, (a) Proposed Edit -- WG agrees with the potential next step strawman revision. Staff to incorporate. Re: b) Proposed edit – Discussion: Potential next step: Strawman revision, based on staff understanding of the WG’s intent: “The working group recommends that the Registry MUST verifyies at the time that the TAC is stored in the Registry system that the TAC meets the requirements specified in Preliminary Recommendation 7.” * WG agrees with the suggested change. ACTION ITEM: Recommendation 8, (b) Proposed Edit – WG agrees with the potential next step strawman revision. Staff to incorporate. 6. Discussion of TAC Generation, Storage, and Provision – Recommendation 9 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> and Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1dbJ8gV6afl9oH...>) Re: a) Concerns – Discussion: Potential next step: WG to consider the suggestion that Gaining Registrars should log failed requests and share with targets, as well as suggestion about enhanced security measures. * The TAC itself is one-time use; from a registry point of view if we get a TAC that matches what is stored, it can’t be used again. Also, rather than counting failed, the TAC has a TTL, which should address that. So, we already have security measures that address this; no need to log failed attempts. * Could be a registry choice to keep note of failures and investigate as part of a particular business model. No need to make it mandatory. * Registrars and registries already log a lot. * WG agrees that no changes are necessary to the policy language. Re: b) Proposed edit – Discussion: Potential next step: Strawman revision: 9.2: When the Registrar of Record sets the TAC at the Registry, the Registry MUST store the TAC securely, at least according to the minimum standard set forth in RFC 9154 (or its successors). ACTION ITEM: Recommendation 9, (b) Proposed edit -- WG agrees with the suggested language in the Potential next step. Staff to incorporate.