[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