Hello team, So glad to see the discussion, thanks to all who provided input as we work through this idea. I wanted to provide some thoughts in response, ahead of tomorrow’s meeting. Jim: One clarification I would add is that in Step 1, where you say the RNH unlocks the domain, this means removing all registrar locks. It does not include removing registry locks, since they may be associated with Registry Lock Services and those are explicitly out of scope for this PDP. A registry has a responsibility to resolve its registry locks at some time beginning with the receipt of a valid TAC and ending upon the actual transfer of the domain. SW: Yes - I wasn’t suggesting to include registry lock, I was thinking about the “ClientTransferProhibited” status. No intention to alter our scope here. Theo: If the registrant nacks the tac and other things happen, those should be optional as an account password reset are not possible on an operational level for some business models and I can imagine there are some retail registrars that rather not lock accounts after a nack, at least I suspect that is what the password reset is for. SW: Agreed, those “other things” are external to this policy, it was included for context but I don't think we should set requirements there, sorry for the confusion. Catherine: One thing to confirm - once the transfer is completed (Step 4), the losing registrar still sends the notice of transfer completion, correct? SW: Yes, definitely! Then of course there’s the great thread with Zak, I think that’s been covered. Looking forward to tomorrow’s meeting, thanks all! -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com From: Sarah Wyld Sent: November 29, 2022 3:59 PM To: Zak Muscovitch; Catherine Merdinger Cc: James Galvin; gnso-tpr@icann.org Subject: RE: [GNSO-TPR] Input Due 30 November: Draft RevisionstoRecommendations 2-9 Hi all, Thanks so much to everyone for the engagement with the proposal that I shared earlier. I intend to reply to the various questions that have been raised tomorrow, but wanted to jump in here on this thread. Indeed, I was considering only registrar transfer, and not an included registrant (owner) transfer. Both FOAs can be found on the ICANN website here; the Losing FOA currently in use does not require the inclusion of who the Gaining Registrar is. Zak wrote: “‘what benefit does the new proposed TAC request / refusal approach have over the current approach, if the proposed new approach introduces a possible (even if generally unlikely) vulnerability into the process (as referenced above)?’” I do not think the proposed new approach creates any new area of vulnerability. In both methods there’s a point where the RNH obtains the TAC, and so it could be accessed by a baddie then, or if the RNH gives the TAC to someone else then that someone else could let it fall into the wrong hands. In the “TAC ACK” method, if the party who requests the TAC to be created is NOT the RNH, then the RNH will get an email notice and can stop it at that moment. Non-response will wait and then automatically ACK – if the group thinks it would be better for security, we could consider that it might wait and then automatically NACK, cancelling the TAC creation at that point entirely. Either way, this is a security measure that does not exist currently. Instead, in the current system the TAC always exists (so the period of potential vulnerability is longer) and there’s no notice to the RNH when the TAC is obtained (so no ‘stop the transfer’ moment here), but rather the stop moment is later on, with the Losing FOA (which does auto-approve after 5 days of no response, but gives the RNH the chance to cancel). Thanks, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com From: Zak Muscovitch Sent: November 29, 2022 3:39 PM To: Catherine Merdinger Cc: James Galvin; Sarah Wyld; gnso-tpr@icann.org Subject: RE: [GNSO-TPR] Input Due 30 November: Draft Revisions toRecommendations 2-9 Many thanks, Catherine, for the helpful clarifications. Indeed, Sarah and I (off-list) also came to the realization that we were talking about two different kinds of transfers. Sarah was referring to I believe, as you point out below a transfer between registrars involving the same registrant. Whereas I was referring to a transfer between two different registrants and two different registrars. I agree that ultimately it is the RNH’s responsibility to ensure that its TAC is secure after it is provisioned and I also agree that the issue of protecting a TAC is not different from protecting an Auth Code, and that we do not need to necessarily concern ourselves with that. Nevertheless, it was my understanding that at some registrars at least, the FOA does identity the gaining registrar. If this is the case, then the point is that the Losing FOA approach enables a registrant to know who the gaining registrar is, which is arguably incrementally more beneficial than not knowing (since it can arguably in some circumstances, avoid a transfer to an unintended registrar). If it is incrementally beneficial as aforesaid, there should I think be a corresponding incremental benefit or an even greater reason, to not employ the Losing FOA, and I am uncertain what that it. Best regards, Zak From: Catherine Merdinger <catherine@identity.digital> Sent: Tuesday, November 29, 2022 3:20 PM To: Zak Muscovitch <zak@muscovitch.com> Cc: James Galvin <jgalvin@identity.digital>; Sarah Wyld <swyld@tucows.com>; gnso-tpr@icann.org Subject: Re: [GNSO-TPR] Input Due 30 November: Draft Revisions to Recommendations 2-9 Hi Zak, I think your first point is assuming that the domain is both changing registrars and changing registrants, which isn't always the case. I don't think we could have metrics on what percent of inter-registrar transfers are intended to both change registrars and registrants, but that could be helpful to this discussion. Setting that aside, the transfer is only completed when someone (whether that person be the current registrant or a new registrant) provides the TAC to the gaining registrar, so I believe what Sarah wrote is what she meant, though, as you point out, it's possible that the "RNH" as listed in Step 3, might not be the actual RNH, it may be the person to whom the RNH is intending to transfer the domain. Regarding your second point (if not addressed by my first), I'm not really sure how we could prevent the transferor, as you called them, from providing the TAC to a baddie transferee who transfers the domain to a different registrar. Even if the transferee isn't a baddie, if their email or other method of communication isn't secure, I don't really understand what we can do about it. Surely the transferee can use any registrar they want, and the transferor wouldn't necessarily need to know where it was going. Plus, they will receive a notification from the losing registrar that the transfer has completed, after which they can check the RDAP output for the new registrar. All of this is basically to say, once the TAC is in the hands of the RNH, it is their job to ensure it stays secure - I'm not sure what our role would be to ensure it stays that way. Surely we have the same issue with today's AuthCodes, right? Finally, I'm not actually sure that the Losing FOA currently lets the RNH know where the domain is transferring - wouldn't that be the Gaining FOA, which hasn't been used since GDPR? Please let me know if I've misunderstood anything from your email. And registrars, please jump in and correct me if I'm wrong. Catherine Catherine Merdinger | Corporate Counsel | Identity Digital Inc. | +1.319.541.9416 | she/her On Tue, Nov 29, 2022 at 10:32 AM Zak Muscovitch <zak@muscovitch.com> wrote: Many thanks, Sarah for preparing the below revised straw-man proposal. I have a couple questions in order to gain a better understanding and to explore the issues presented: 1. In the proposed Step 3, it states: When the RNH receives the TAC, they provide it to the gaining Rr and the transfer is completed The proposal appears to envision a RNH providing the TAC directly to the gaining registrar, rather than providing it to the gaining registrant. Is this what you had intended? And if so, that would seem to provide a possible solution to the concern I express in latter portion of my second question, below. 2. Under the status quo, I understand that a registrant would have the ability to see which registrar has made the transfer request via the Losing FOA, whereas under the proposed Straw Man, a registrant would not be able to see this and therefore, after providing the TAC to the gaining registrant (i.e. the transferee), the TAC could in theory somehow be stolen by a third party and used at an unintended and foreign registrar (though I recognize that this would generally be a very rare instance and would likely involve greater security issues than we are trying to address via the Transfer Policy Itself). If this is the case, then my question is, ‘what benefit does the new proposed TAC request / refusal approach have over the current approach, if the proposed new approach introduces a possible (even if generally unlikely) vulnerability into the process (as referenced above)?’ What I am trying to better understand here, is although the new proposal rather elegantly provides the crucial ability of a registrant to stop a transfer (at the TAC stage, instead of at the transfer stage, per se), it may not be so much of an incremental improvement overall, that it justifies even an arguably minimal risk of an TAC being deployed by an unauthorized third party at an unintended registrar with no notice to the registrant. The previous and current approach which employs the FOA, does not have this issue, so I am thinking there should be a very clear benefit to abandoning the FOA in favor of this approach, and I am genuinely uncertain what it is. That being said, if as per my remarks above at #1, there is a procedure envisioned for the registrant (transferor) directly inputting the TAC into the losing registrar, then that could possibly route around this potential issue, since the registrant would maintain constant control of the TAC and would be able to deploy it at the intended registrar. Of course, there would need to be a system available at the gaining registrar for enabling a non-account holder to input the TAC for the benefit of the gaining registrar’s account holder, and this would involve a correlation between the TAC and for example, the prospective new registrant’s recorded email address. Best regards, Zak Zak Muscovitch Muscovitch Law P.C. 1-866-654-7129 (Toll Free) 416-924-5084 (Office) Zak@Muscovitch.com Muscovitch.com DNattorney.com TrademarkLawyer.ca From: GNSO-TPR <gnso-tpr-bounces@icann.org> On Behalf Of James Galvin Sent: Tuesday, November 29, 2022 11:10 AM To: Sarah Wyld <swyld@tucows.com> Cc: gnso-tpr@icann.org Subject: Re: [GNSO-TPR] Input Due 30 November: Draft Revisions to Recommendations 2-9 One clarification I would add is that in Step 1, where you say the RNH unlocks the domain, this means removing all registrar locks. It does not include removing registry locks, since they may be associated with Registry Lock Services and those are explicitly out of scope for this PDP. A registry has a responsibility to resolve its registry locks at some time beginning with the receipt of a valid TAC and ending upon the actual transfer of the domain. Jim On 22 Nov 2022, at 13:48, Sarah Wyld wrote: Hello team, I’ve reviewed our draft updated recommendations and the strawman for Rec 2. Left some minor changes in the redline doc. I want to provide more context specifically around the suggestion for an alternative to the Losing FOA, we can call it the “TAC ACK” process. Prior to our public comment review, the WG seemed aligned on the decision to drop the Losing FOA; we must certainly address all the concerns raised in the public comments, and I think we can do that while also maintaining our goal of streamlining the transfer process by further exploring the TAC ACK option. What the process would look like: 1. RNH unlocks domain and requests TAC from the Registrar of Record (Losing Rr) 2. Losing Rr sends a TAC ACK email to the RNH saying “Someone requested a TAC; if this wasn’t you, click <NACKlink>. If it was you, you can either do nothing and we’ll provide you the TAC in 5 days or you can click <ACKlink> and we’ll give you the TAC right now” a. If RNH clicks <NACKlink>, the TAC is never set at the Ry, and other things might happen (e.g. account password reset, etc) b. If RNH clicks <ACKlink>, the Losing Rr provisions the TAC at the Ry and issues it to the RNH (Rec 3 Notification of TAC Issuance) c. If no response, Losing Rr waits 5 days and then provisions the TAC at the Ry and issues it to the RNH (Rec 3 Notification of TAC Issuance) 3. When the RNH receives the TAC, they provide it to the gaining Rr and the transfer is completed (Rec 4 “Notification of Transfer Completion” etc) Why this is beneficial: • Registrant agency: the Registrant has the option to cancel the transfer right away, following the same process as with the current Losing FOA (which has the option to NACK, and which auto-ACKs after a 5 day pending period) • Just-in-time notifications: The TAC ACK process occurs right when the RNH is preparing for the transfer, rather than at some point later on after they’ve initiated it with the gaining Rr and moved on/stopped thinking about it • Simplicity: Registrants consistently request fewer emails overall and fewer steps specifically in the transfer process, and have requested an ‘instant transfer’ process for years Risks & mitigations: • Risk: There would be no notification/’stop the transfer’ moment after the transfer is initiated with the gaining registrar; Mitigation: (a) there is a notification/stop moment at the time of TAC request, and (b) the fast-undo process we are committed to creating in the next phase of this WG would specifically address these issues and could certainly include reverting DNS if it was changed • Risk: Level of development effort does not balance benefit; Mitigation: The level of effort will differ for different providers, and we shouldn‘t reject ideas just because they take work, especially since we’re already making changes to the transfer process as a whole. Now is exactly the time to do this! The working group hasn’t reached consensus on eliminating the Losing FOA, but we also haven’t reached consensus on keeping it. I still believe that this “TAC ACK” proposal would address the entirely valid concerns about security and registrant agency, while also providing noticeable improvement for registrants who have repeatedly and for quite some time requested a faster transfer process. I hope we can discuss this proposal alongside the Losing FOA strawman. Thank you, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com From: Emily Barabas Sent: November 16, 2022 12:18 PM To: gnso-tpr@icann.org Subject: [GNSO-TPR] Input Due 30 November: Draft Revisions toRecommendations 2-9 Dear working group members, As discussed on yesterday’s call, staff had an action item to provide a redline revision of the Initial Report reflecting agreed updates to Recommendations 3-9 (see pages 18-24), as well as a strawman draft of the new Recommendation 2 and response to Charter Question A7. The redline is attached. The Recommendation 2 strawman is available here. Please carefully review these documents in coordination with the groups you represent. If you feel that there are items that need to be revised, please enter them here. For each item, please include: • Report version (the date listed in the header of the document) and applicable line numbers ( these are listed along the left margin of the document). • Name and group you represent: If multiple WG members represent a group, input should be in coordination with these other members. • Rationale: please provide a clear explanation for why you are proposing the revision. • Specific proposed revision: Provide the language you would like to see added/removed/edited. The deadline for submitting input is 30 November 2022. After the deadline, the working group will discuss the items submitted in the input document. Following review of those items, the text will be considered stable. Please do not hesitate to reach out with any questions about the review process. Kind regards, Caitlin, Julie, Berry, and Emily Emily Barabas Policy Development Support Senior Manager Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org _______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org https://mm.icann.org/mailman/listinfo/gnso-tpr _______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org https://mm.icann.org/mailman/listinfo/gnso-tpr