Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be in two weeks on Tuesday 08 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. 2. For Recommendation #3 -- WG members to review the language in the Implementation note and suggest improvements. See page 4 in the Working Document at: https://docs.google.com/document/d/1SaEV9vjiSZONjHvnXj3zbPVTTflDTo4WphZrbqDT.... Notes: Transfer Policy Review - Meeting #63 Proposed Agenda 25 October 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates * No call next week (01 November) due to the CPH Summit, starting up twice-a-week meetings the following week (with 10 November). Timeline see: https://community.icann.org/display/TPRPDP/2022-10-25+Transfer+Policy+Review... * Berry: * First, this is very much conceptual in nature and doesn’t cover all of the mechanics of doing a domain transfer. * Three depictions – current, Initial Report, proposed. * Depicts fake phases. Just trying to focus on when the transfer is eligible for transfer – all issues are cured. What is good about this approach versus the swimlane diagram, which can’t represent all of the timeframes. * At the top: current state, with the Gaining FOA and authorization can’t happen because of GDPR. Interesting in going back when a transfer was initiated at the Gaining Registrar it could live up to 60 days. If there is no NACK at the end of the process the default approval is set at 5 days. * In the middle: based on the recommendations in the Initial Report – what is interesting here is you can see what the preliminary recommendations do to the current process. No easy way to show that the TAC gets submitted to the Gaining Registrar could wait until just under 14 days before the TTL expires. But the moment the TAC is submitted to the Gaining Registrar the transfer is initiated. * Last row: Under consideration based on public comments – does not represent that there is a final decision (orange boxes), just for discussion. Timing depends on when they submit the TAC to the Gaining Registrar. 3. Continue Discussion of Comments on Elimination of the Losing FOA – Recommendation 2 (see Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt-Initial-Report-Recommendations_Rec%202_20220829.docx?version=1&modificationDate=1661772796000&api=v2> and Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1gyy9xfe0-ymW-irtY2gKSEy3za8IcG-GrF8EcCGE57g/edit__;!!PtGJab4!8EDzIDATb57WbfIoSp3iWCyuspiXiubvw5Um15S42IsIn0o2vyqSNflqotx_9WtkAjsS_w1x0DLV6pd0mf9KxL8wXiyD4GPThw$>) * Proposal based on Public Comment adds complexity to the process. * Gives RNH them a window of time to NACK – either in a 5-day window or shorter. As today, it is an auto-ACK process; if no NACK it will be ACKed. * Issue with the proposal: The Losing FOA – there is no pending transfer. Doesn’t really do anything because the transfer has already gone through. Putting them back in the process continues to do nothing. Like the option to NACK up front because the minute the TAC is released the transfer is live. * The idea is that the orange box goes back to what it is today. * The RNH must inform the Gaining Registrar about the TAC to start the transfer. * So we have to now define a pending Transfer period then. * Issue is that the TAC is vulnerable for up to 14 days. If you put the NACK at the end the RNH can still stop it. * Clarification: regarding the rationale for what was done with the TAC – the security of the AuthInfo code in the current system was a message – long period of vulnerability; changes in the Initial Report have addition security measures when setting the TAC. * If we are going to recommend additional requirements also see if we can address the issue that when a TAC is requested it is not automatically generated. You can bypass the problem of the Losing FOA by getting an ACK/approval when the TAC is requested. * Some comments noted that there is a window from when the TAC is provisioned/communicated when the TAC is given to the Gaining Registrar the Registry processes it and it is gone. The functionality that gives the RNH the ability to stop the transfer once the Gaining Registrar is known is critical to some commenters. There still is the problem of TAC vulnerability once provisioned and putting the NACK at the end (once the Gaining Registrar is known) addresses this problem. * If an account is breached, all options are out the window, as it's already breached, regardless of which process we decide. * Suggested 'step' simply adds a verification option, which gives a Registrant a chance to deny. Since there's no room to deny later in the process. * The losing FOA is a warm fuzzy option at this option. My take away from the public comment is that people don’t really understand how the security profile is implemented and how what we have is actually better than what was had before. I’m hoping that the text that the small team will propose will make this more clear and if so we can add it to the document and it will help others too. * If this is solving extreme scenarios not sure it is worth the effort. * Not sure about the 'adding dev cycles' since we're already sending a 'notice of TAC provision' this simply modifies that so instead of delivering the TAC initially, it informs the registrant of the request and how to deny it, if ignored it will be sent within the 120 hour window. * If we move it forward from where it is today, it will require more development. * Do we need to see what the small team will give us before we make a decision? The small team is looking at just the different threats that can occur and how they are solved or not. * Compliance data regarding unauthorized transfers. Transfer complaints previously provided to the WG can be found here: https://community.icann.org/display/TPRPDP/Metrics * If we move the NACK to the front everyone has work to do, or if we leave it where it’s at we still get the security advantage without the extra work. * Reminder, Registrars will still have to educate their customers on the new process regardless. * Not sure how At-Large will address it, but in discussion in the CCWG is that we want as secure a process as possible, without being complex or lengthy, but this doesn’t lie in the policy but in the registrar processes. We have to identify what we initially agreed in the WG in the preliminary recommendations was a great step forward. * BC/Zach will get back after consulting with his group. * The issue is not whether this functionality should exist or not, even if some think it’s fluffy, just where it should happen/lie in the process --- beginning or where it is now. 4. Continue Discussion of Notification of TAC Provision – Recommendation 3 (see Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt-Initial-Report-Recommendations_Rec%203_20220829.docx?version=1&modificationDate=1661772946000&api=v2> and Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1SaEV9vjiSZONjHvnXj3zbPVTTflDTo4WphZrbqDTmxU/edit__;!!PtGJab4!8EDzIDATb57WbfIoSp3iWCyuspiXiubvw5Um15S42IsIn0o2vyqSNflqotx_9WtkAjsS_w1x0DLV6pd0mf9KxL8wXiyq48SsVw$>) * One of the considerations for Recommendations #3 and #4 is whether we will keep these notifications. If we assume that – regardless of Recommendation #2 – then we can dive into the specifics. * Recommendation #3 has to exist regardless of whether we retain the Losing FOA. * Public Comments Review: * First few are about the Losing FOA. * About the tech contact being an important recipient -- that was assuming that contact would receive the notice of TAC provision (not the TAC). Question of who that contact would be – admin contact is going away. Having a database of additional contacts is a risk. * The principle of notifications is essential – when to notify either at provision or at request – it depends on how far apart are there two steps. If there is a gap then there should be two notifications. The second part is whether you should notify more than one person – from a security perspective it would be good to have more than one notification, but not mandatory – SHOULD and not MUST. * If the group changed course and sent the notification to multiple contacts, the notice would have to be distinct from the provision of the TAC itself. * Having an optional additional contact might be helpful, but having the contact on file doesn’t add anything. * Adding contacts who aren’t customers sounds a complex issue for GDPR. The current recommendations don’t preclude from doing this. Or could be optional but not required. * What if one contact NACKs the transfer and one ACKs it? Only one should get the option to NACK/ACK. * Does this need to be policy? * Summary: Leave it as a MUST for notification to the RNH and leave the other options out of the policy. * Number of comments about how the recommendations don’t address a customer using a privacy/proxy service. Staff drafted text for an implementation note: Potential next step: Strawman revision: Recommendation 3: The working group recommends that the Registrar of Record MUST send a “Notification of TAC Provision” to the RNH, as listed in the registration data at the time of the TAC request, without undue delay but no later than 10 minutes after the Registrar of Record provides the TAC. Implementation Note: For the purposes of sending the notification, the Registrar of Record should use contact information as it was in the registration data at the time of the TAC request. In cases where a customer uses a Privacy/Proxy service, the Registrar of Record should send the notification directly to contact information associated with the underlying customer where it is possible to do so * Question: Should this only refer to Proxy service? Proxy service is RNH, whereas for Privacy service, the underlying customer is RNH. * No registrar would send the TAC to the proxy service. * My concern is that the proxy service should not be doing the transfer- it should be the underlying customer/domain registrant. * Do we need the implementation note? * Not sure the distinction between privacy and proxy is necessary if you are talking about the underlying customer. * Think what we are saying is for the recommendation we can strike out “as listed in the registration data at the time of the TAC request”. If we have an Implementation note we could improve the language to call out the issue of the underlying customer is known. * If keeping the note, we still have to realize that Registrars may not have access to underlying data. ACTION ITEM: For Recommendation #3 -- WG members to review the language in the Implementation note and suggest improvements. See page 4 in the Working Document at: https://docs.google.com/document/d/1SaEV9vjiSZONjHvnXj3zbPVTTflDTo4WphZrbqDT.... For next meeting – review comment from ICANN org: “Include additional elements required to be included in the “Notification of TAC Provision” such as: * An element that explains that the TAC will enable the transfer of the domain name to another registrar. * The deadline by which the RNH must take action if the request is invalid so that the registrar has sufficient time to NACK the transfer, where applicable (note that, at the time the RNH receives the “Notification of TAC Provision”, the TAC may have already been provided and the transfer command sent to the registry operator). * Required actions registrars must take (and by when) upon receiving notification by the RNH of an invalid request.” 6. AOB -- Work Plan for Reviewing Public Comments – see attached and below: * Suggestion is to go through the recommendations sequentially. * Will adjust the work plan as we go after each meeting. * Try to wrap up the public comment review by the end of the year. Work Plan 25-10-22: Meeting #63 - Review of public comments for Phase 1A - Recs #2, #3, #4 TPR WG 10/25/22 In Progress PC review 08-11-22: Meeting #64 - Review of public comments for Phase 1A - Recs #3, #4, and Question for Community Input on Rec #4 TPR WG 11/08/22 Not Started PC review 10-11-22: Meeting #65 - Review of public comments for Phase 1A - Recs #5, #6, #7 TPR WG 11/10/22 Not Started PC review 15-11-22: Meeting #66 - Review of public comments for Phase 1A - Rec #7, #8 TPR WG 11/15/22 Not Started PC review 17-11-22: Meeting #67 - Review of public comments for Phase 1A - #9, #10, #11, #12 TPR WG 11/17/22 Not Started PC review 22-11-22: Meeting #68 - Review of public comments for Phase 1A - #13, #14, and Question for Community Input on Rec #14 TPR WG 11/22/22 Not Started PC review 29-11-22: Meeting #69 - Review of public comments for Phase 1A - Question for Community Input on Rec #14, [no comments on #15], #16, #17 TPR WG 11/29/22 Not Started PC review 01-12-22: Meeting #70 - Review of public comments for Phase 1A - Rec #16, #17 TPR WG 12/01/22 Not Started PC review 06-12-22: Meeting #71 - Review of public comments for Phase 1A - Rec #18, #19 TPR WG 12/06/22 Not Started PC review 08-12-22: Meeting #72 - Review of public comments for Phase 1A - Rec #20, #21, #22 TPR WG 12/08/22 Not Started PC review 13-12-22: Meeting #73 - Review of public comments for Phase 1A - Charter Questions and Report Text; Additional Suggested Topics and Proposals TPR WG 12/13/22 Not 15-15-12-22: Started PC review 20-12-22: Meeting #74 - Review of public comments for Phase 1A - WG Processes and Modalities; Additional Input TPR WG 12/15/22 Not Started PC review 22-12-22: Meeting #75 - Review of public comments for Phase 1A