[GNSO-TPR] Input Due 30 November: Draft RevisionstoRecommendations 2-9

James Galvin jgalvin at identity.digital
Thu Dec 1 01:31:04 UTC 2022


Thanks Sarah.

Jim


On 30 Nov 2022, at 9:48, Sarah Wyld wrote:

> 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 at tucows.com
>
> From: Sarah Wyld
> Sent: November 29, 2022 3:59 PM
> To: Zak Muscovitch; Catherine Merdinger
> Cc: James Galvin; gnso-tpr at 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 at tucows.com
>
> From: Zak Muscovitch
> Sent: November 29, 2022 3:39 PM
> To: Catherine Merdinger
> Cc: James Galvin; Sarah Wyld; gnso-tpr at 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 at identity.digital>
> Sent: Tuesday, November 29, 2022 3:20 PM
> To: Zak Muscovitch <zak at muscovitch.com>
> Cc: James Galvin <jgalvin at identity.digital>; Sarah Wyld 
> <swyld at tucows.com>; gnso-tpr at 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 at 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 at Muscovitch.com
>  
> Muscovitch.com
> DNattorney.com
> TrademarkLawyer.ca
>  
>  
>  
> From: GNSO-TPR <gnso-tpr-bounces at icann.org> On Behalf Of James Galvin
> Sent: Tuesday, November 29, 2022 11:10 AM
> To: Sarah Wyld <swyld at tucows.com>
> Cc: gnso-tpr at 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 at tucows.com
>  
> From: Emily Barabas
> Sent: November 16, 2022 12:18 PM
> To: gnso-tpr at 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 at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-tpr
> _______________________________________________
> GNSO-TPR mailing list
> GNSO-TPR at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-tpr

> _______________________________________________
> GNSO-TPR mailing list
> GNSO-TPR at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-tpr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20221130/15451227/attachment-0001.html>


More information about the GNSO-TPR mailing list