FW: Draft Comments - FW: Transfer Policy Review Preliminary Report - NCSG Public Comment Discussion

[kathy at DNRC.TECH]

Hi Ken, I've made a few edits to expand a bit what you wrote in as a 
proposed change/expansion to our comments.  Tx you(!) and please review 
and edit.

Adebunmi, I think you have a point.  Ken, as shared below, one email may 
not be enough.  Even with the protections you have added, doesn't it 
still makes sense to reach out by various methods when a domain name is 
being transferred and when the transfer is complete?

Registrars have many methods when they are asking to renew a domain 
name. Could we use these to help them share an attempt to transfer it 
too?  Contacting all of the contacts (Admin, Tech, Registrant) seems to 
make sense - and SMS too. And any other contact information held by the 
Registrar for billing...

Adebunmi, could you add some lines to the draft comment?
Best, Kathy

On 2024-09-27 12:04, Adebunmi Akinbo wrote:
> Thanks Ken and Kathy,
> My take from this brief discuss is our role to outreach in the area of
> 2FA and Whitelisting our Registrars.
> 
> It would reduce the bad experience and minimize damage should a
> malicious transfer occur.
> 
> While some of us would go ahead with such an insight, it brings me to
> the last statement in your response to Kathy; can we be specific on
> email and make an attempt to include an SMS, considering that the
> informations are available to the registrar?
> 
> Thank you.
> 
> On Fri, Sep 27, 2024, 6:33 PM Ken Herman <ken at kherman.com> wrote:
> 
>> Hi Kathy. Thanks for your message.
>> 
>> I'm not sure how best to approach this and present a practical
>> suggestion that, frankly, makes sense to the implementing partners,
>> i.e., the registrars.
>> 
>> What I have heard most from the discussions is that protection of
>> the RNH's registrar account is paramount, since those are the keys
>> to the kingdom, along with RNH's protecting their e-mail accounts.
>> And, I might add, the registrar's need to protect the integrity of
>> their own systems.
>> 
>> The point is, if I make a change to my registered name, either to
>> initiate a transfer or to change the registration data, especially
>> the e-mail address I use, then either of these will result in a
>> notification, which i should expect. It's the situation where I did
>> not make the change that I need to be worried about and I may,
>> indeed, miss the notification.
>> 
>> I'm pretty sure the contracted parties will contend that it is not
>> just a matter of missing one message. What I expect to hear is that
>> to initiate a change in my registration would require an attacker to
>> gain access to my account and in that case is likely to simply
>> change the registration data, which would result in a message to the
>> old and new contacts, as per "Recommendation #27: Change of
>> Registrant Data Notification". If it's a malicious action and I see
>> the message, then I can take action right away. If I miss the
>> message, well, then it's a problem. So, what now?
>> 
>> I believe the answer lies in the Change of Registrant Data (CORD)
>> recommendations. We have already suggested in the comments on
>> recommendation 26 that we would like to impose a transfer
>> restriction (which an RNH may opt out of) after any material change.
>> We can further strengthen this by recommending that the registrar
>> require a confirmation of a material change to registration data
>> from the old and new contact e-mail before completing a material
>> change of registration data. This was the case in the original
>> policy.
>> 
>> Would that satisfy? I think there would be resistance to a
>> requirement for multiple messages to the same e-mail address (none
>> exists now) and I would struggle to find a good answer, whereas a
>> greater protection of the account itself, through a change
>> confirmation process, might be a more practical option.
>> 
>> I have updated the comment document accordingly and here's the link
>> for easy reference:
>> 
>> 
> https://docs.google.com/document/d/1uM38-A98TYK-bED30l4Ue1cFJdNuHaZl/edit?usp=sharing&ouid=105988793481216121706&rtpof=true&sd=true
>> [1]
>> 
>> A couple of other points…I believe there are no more admin
>> contacts; it’s just the RNH contact. Not sure about technical.
>> Registrars might have more, but the data system only has the one.
>> Recommendation 27 does not limit the registrar to one secure methods
>> (e-mail or SMS, for example), but there is no requirement to use
>> more than one.
>> 
>> Let me know what you think.
>> 
>> Ken
>> 
>> -----Original Message-----
>> From: kathy at dnrc.tech <kathy at dnrc.tech>
>> Sent: Friday, September 27, 2024 12:09 PM
>> To: Ken Herman <ken at kherman.com>
>> Cc: NCSG-DISCUSS at listserv.syr.edu
>> Subject: Re: FW: Draft Comments - FW: Transfer Policy Review
>> Preliminary Report - NCSG Public Comment Discussion
>> 
>> Hi Ken,
>> 
>> Tx for all your work on this issue.  Years of work and effort!
>> 
>> I share Adebunmi's concerns below.  How can we can request more than
>> one notification -- at all major points along the way?  One notice
>> can go into a spam folder, as you mention below, or be lost
>> completely when the power goes down (as in so many areas of US right
>> now - since a large hurricane hit overnight).  It seems a fair and
>> reasonable principle that never should a notice on something
>> important involving our domain names be an isolated one.
>> 
>> Precedent: In the Uniform Dispute Resolution Policy (UDRP) rules, we
>> worked very hard for an "actual notice" standard - making sure that
>> the Domain Name Registrant actually knows that the UDRP proceeding
>> is taking place -- by requiring the complaint to be distributed via:
>> 
>> 
>> - Email to all the listed contacts (registrant, admin, tech), and
>> 
>> - "Written Notice to all postal-mail and facsimile addresses for the
>> domain-name holder, administrative and technical contact (as
>> applicable) shown in the domain name's Registration Data in
>> Registrar's Registration Data Directory Service... [and] supplied by
>> Registrar to the Provider for the registration's billing contact."
>> (UDRP Rules)
>> 
>> ****
>> 
>> Can we quickly expand our comments to ensure wide and fair  notice -
>> and certainly no single point of failure in the notice system?
>> 
>> Best and tx,
>> 
>> Kathy
>> 
>> On 2024-09-27 06:41, Ken Herman wrote:
>> 
>>> Hello Adebunmi.
>> 
>>> 
>> 
>>> Thanks for your question. The proposed recommendations include
>> many
>> 
>>> areas where notifications of registration changes are sent to
>> 
>>> registered name holders throughout the process. One key
>> notification
>> 
>>> can be found in recommendation 11, “Notification of TAC
>> issuance”
>> 
>>> which states:
>> 
>>> 
>> 
>>> “The working group recommends that the Registrar of Record MUST
>> send a
>> 
>>> “Notification of TAC
>> 
>>> 
>> 
>>> Issuance” to the RNH without undue delay but no later than 10
>> minutes
>> 
>>> after the Registrar of
>> 
>>> 
>> 
>>> Record issues the TAC. For the purposes of sending the
>> notification,
>> 
>>> the Registrar of Record
>> 
>>> 
>> 
>>> MUST use contact information as it was in the registration data at
>> the
>> 
>>> time of the TAC request.”
>> 
>>> 
>> 
>>> Also, Recommendation #19: Notification of Transfer Completion
>> contains
>> 
>>> a requirement to notify when the transfer has been completed.
>> 
>>> 
>> 
>>> There are other places where notifications to registered name
>> holders
>> 
>>> have been added to the policy.
>> 
>>> 
>> 
>>> When it comes to quantity of notices, it is only going to be one
>> per
>> 
>>> instance. And, as far as whether or not a message goes to a
>> RNH’s spam
>> 
>>> folder, well, that isn’t under the control of the sender, in
>> this case
>> 
>>> the registrar involved.
>> 
>>> 
>> 
>>> As the non-commercial community, we may want to do more outreach
>> to
>> 
>>> constituents to ensure the adoption of good practices, like taking
>> 
>> 
>>> advantage of multi-factor authentication when it is available and
>> 
>>> whitelisting messages from important senders, like the registrars
>> we
>> 
>>> use. Also, as a constituency, we can advocate for registrars who
>> have
>> 
>>> not already done so to put in place security measures such as MFA.
>> 
>> 
>>> 
>> 
>>> I am sorry to hear of your bad experience with a notification, and
>> 
>> 
>>> keep in mind that the policy mandates a 30-day transfer
>> restriction
>> 
>>> after a transfer, so if a domain is taken maliciously, there is
>> time
>> 
>>> to address the problem.
>> 
>>> 
>> 
>>> I hope this helps and once again, thank you for the question.
>> 
>>> 
>> 
>>> Ken
>> 
>>> 
>> 
>>> From: Adebunmi Akinbo <adebunmi.akinbo at gmail.com>
>> 
>>> Sent: Wednesday, September 25, 2024 7:51 PM
>> 
>>> To: Ken Herman <ken at kherman.com>
>> 
>>> Cc: NCSG-DISCUSS at listserv.syr.edu
>> 
>>> Subject: Re: FW: Draft Comments - FW: Transfer Policy Review
>> 
>>> Preliminary Report - NCSG Public Comment Discussion
>> 
>>> 
>> 
>>> Apologies for missing the meeting.
>> 
>>> 
>> 
>>> I will do my best to read the reworked comments, but I want to
>> respond
>> 
>>> briefly to your comment on the 30 days.
>> 
>>> 
>> 
>>> We should factor out the following questions and processes:
>> 
>>> 
>> 
>>> Question: What is the communication strategy to ensure the
>> 
>>> non-commercial registered name user respond to any supposed
>> malicious
>> 
>>> transfer? Would it be once? When does it start counting? How sure
>> are
>> 
>>> we that such mails do not go to junk or spam mail?
>> 
>>> 
>> 
>>> From experience, I failed to respond to an ownership and my domain
>> 
>> 
>>> name was restricted from use. My website stopped loading and my
>> mails
>> 
>>> failed. Apparently, the initial mail sent went to junk.
>> 
>>> 
>> 
>>> If the policy reflects a mandatory communication strategy, it may
>> help
>> 
>>> the seemingly non-commercial registered name holder an opportunity
>> to
>> 
>>> respond on time to a malicious domain name transfer.
>> 
>>> 
>> 
>>> My 2kobo!
>> 
>>> 
>> 
>>> On Thu, Sep 26, 2024, 12:31 AM Ken Herman <ken at kherman.com> wrote:
>> 
>> 
>>> 
>> 
>>>> Dear NCSG Members
>> 
>>>> 
>> 
>>>> I would like to thank everyone who attended today’s session on
>> the
>> 
>>>> Transfer Policy Review. I hope you all found the presentation
>> useful
>> 
>>>> and for those unable to make it, Andrea has circulated a link to
>> the
>> 
>>>> recording.
>> 
>>>> 
>> 
>>>> As a result of this review, and after examining the process for
>> 
>>>> submitting comments, I have reworked and edited the responses,
>> and
>> 
>>>> you can find it at this link:
>> 
>>>> 
>> 
>>>> 
>> 
>>> 
>> 
> https://docs.google.com/document/d/1uM38-A98TYK-bED30l4Ue1cFJdNuHaZl/e
>> [2]
>> 
>>> dit?usp=sharing&ouid=105988793481216121706&rtpof=true&sd=true
>> 
>>>> 
>> 
>>>> As you will see, we won’t be uploading this document per se,
>> but the
>> 
>>>> comments remain basically the same.
>> 
>>>> 
>> 
>>>> Please have a look and provide any comments in the document or to
>> me
>> 
>>>> by 23:00 UTC on Sunday, September 29, 2024. This will give me
>> time to
>> 
>>>> incorporate into the responses prior to the submission deadline
>> on
>> 
>>>> Monday, September 30.
>> 
>>>> 
>> 
>>>> Thanks again and I look forward to any input you may have.
>> 
>>>> 
>> 
>>>> Best regards
>> 
>>>> 
>> 
>>>> Ken
>> 
>>>> 
>> 
>>>> From: NCSG-Discuss <NCSG-DISCUSS at LISTSERV.SYR.EDU> On Behalf Of
>> Ken
>> 
>>>> Herman
>> 
>>>> Sent: Monday, September 23, 2024 7:44 PM
>> 
>>>> To: NCSG-DISCUSS at LISTSERV.SYR.EDU
>> 
>>>> Subject: Draft Comments - FW: Transfer Policy Review Preliminary
>> 
>>>> Report - NCSG Public Comment Discussion
>> 
>>>> 
>> 
>>>> Hello again fellow NCSG members
>> 
>>>> 
>> 
>>>> In preparation for our discussion on Wednesday, or as a way for
>> 
>>>> members unable to attend to contribute, you can find in the link
>> 
>>>> below some suggested text for our public comment.
>> 
>>>> 
>> 
>>>> ·Link Removed
>> 
>>>> 
>> 
>>>> The public comment is due next Monday, September 30, 2024, so I
>> 
>>>> welcome any additional points that you feel are important to
>> raise
>> 
>>>> for this policy.
>> 
>>>> 
>> 
>>>> One aspect of the policy that I have been wondering about is the
>> 
>>>> transfer restrictions imposed after registration or a transfer.
>> The
>> 
>>>> recommendation regarding this aspect of the policy imposes a
>> 30-day
>> 
>>>> restriction (with some exceptions, which you can see I addressed
>> in
>> 
>>>> the draft comments). I have no issue with the restriction itself,
>> but
>> 
>>>> my question is whether or not 30-days (720 hours) is enough time.
>> 
>> 
>>>> Keeping in mind that the transfer restrictions are in place for
>> 
>>>> security reasons, my experience is that the average
>> non-commercial
>> 
>>>> registered name holder does not have substantial knowledge of
>> domain
>> 
>>>> name management activities and may take some time to understand
>> what
>> 
>>>> might be happening in the case of a malicious transfer.
>> Therefore,
>> 
>>>> would 30 days be enough time to understand the issues and
>> respond? If
>> 
>>>> not, what timeframe would be better and why? Or, is my assumption
>> 
>> 
>>>> incorrect and 30 days is generally sufficient.
>> 
>>>> 
>> 
>>>> Your thoughts on this, or any of the other policy
>> recommendations,
>> 
>>>> are most welcome and I look forward to our discussion on
>> Wednesday.
>> 
>>>> 
>> 
>>>> Best regards.
>> 
>>>> 
>> 
>>>> Ken
>> 
>>>> 
>> 
>>>> From: NCSG-Discuss <NCSG-DISCUSS at LISTSERV.SYR.EDU> On Behalf Of
>> Ken
>> 
>>>> Herman
>> 
>>>> Sent: Thursday, September 19, 2024 11:47 PM
>> 
>>>> To: NCSG-DISCUSS at LISTSERV.SYR.EDU
>> 
>>>> Subject: Transfer Policy Review Preliminary Report - NCSG Public
>> 
>>>> Comment Discussion
>> 
>>>> 
>> 
>>>> Dear fellow NCSG members:
>> 
>>>> 
>> 
>>>> As I reported previously, the Transfer Policy review Working
>> Group
>> 
>>>> (TPR WG) has completed its consideration of the issues outlined
>> in
>> 
>>>> its charter and have produced its preliminary report. We are now
>> in
>> 
>>>> the public comment period for this report, which closes at the
>> end of
>> 
>>>> September. Recently, the TPR WG support team have run two
>> webinars
>> 
>>>> describing the recommendations, along with an opportunity to ask
>> 
>>>> questions. The links to the recordings of these webinars are
>> below.
>> 
>>>> 
>> 
>>>> As the deadline for comments approaches, your TPR WG NCSG
>> 
>>>> representatives (Juan and I) welcome all NCSG members to a
>> working
>> 
>>>> session to consider any issues we may wish to include in our
>> public
>> 
>>>> comment contribution.
>> 
>>>> 
>> 
>>>> We have arranged the call for Wednesday, September 25, 2024 @
>> 13:30
>> 
>>>> UTC with the connection details below. I have also requested
>> Andrea
>> 
>>>> to send these details as calendar invitations.
>> 
>>>> 
>> 
>>>> For your reference I have placed below links to the relevant
>> 
>>>> materials, including the NCSG public comment to the interim
>> report
>> 
>>>> published in 2022.
>> 
>>>> 
>> 
>>>> I look forward to your participation in this discussion, but if
>> you
>> 
>>>> cannot attend we welcome any written comments anyone may have.
>> 
>>>> 
>> 
>>>> As always, please feel free to contact me if you have any
>> questions.
>> 
>>>> 
>> 
>>>> Best regards
>> 
>>>> 
>> 
>>>> Ken
>> 
>>>> 
>> 
>>>> Join Zoom Meeting:
>> 
>>>> 
>> 
>>> 
>> 
> https://icann.zoom.us/j/98878189584?pwd=ZVpkSVVuaXVqeGRMelNEWW1LMkxQUT
>> [3]
>> 
>>> 09
>> 
>>>> 
>> 
>>>> Meeting ID: 988 7818 9584
>> 
>>>> 
>> 
>>>> Passcode: i!y7.qx+11
>> 
>>>> 
>> 
>>>> One tap mobile
>> 
>>>> 
>> 
>>>> +16699006833,,98878189584#,,,,,,0#,,7740925615# US (San Jose)
>> 
>>>> 
>> 
>>>> +12532158782,,98878189584#,,,,,,0#,,7740925615# US (Tacoma)
>> 
>>>> 
>> 
>>>> PHONE ONLY DETAILS:
>> 
>>>> 
>> 
>>>> Find your local number: https://icann.zoom.us/u/ayKmeftWg [4]
>> 
>>>> 
>> 
>>>> Meeting ID: 988 7818 9584
>> 
>>>> 
>> 
>>>> Phone only Passcode: 7740925615
>> 
>>>> 
>> 
>>>> Transfer Policy Review PDP Page:
>> 
>>>> 
>> 
>>> 
>> 
> https://community.icann.org/display/TPRPDP/Transfer+Policy+Review+PDP
>> [5]
>> 
>>>> 
>> 
>>>> TPR Public Comment page:
>> 
>>>> 
>> 
>>>> 
>> 
>>> 
>> 
> https://www.icann.org/en/public-comment/proceeding/initial-report-on-t
>> [6]
>> 
>>> he-transfer-policy-review-01-08-2024
>> 
>>>> 
>> 
>>>> Transfer Policy Review Webinar 1:
>> 
>>>> https://community.icann.org/x/OgKkFQ [7]
>> 
>>>> 
>> 
>>>> Transfer Policy Review Webinar 2:
>> 
>>>> https://community.icann.org/x/PAKkFQ [8]
>> 
>>>> 
>> 
>>>> NCSG Response to preliminary report in 2022:
>> 
>>>> 
>> 
>>> 
>> 
> https://itp.cdn.icann.org/public-comment/proceeding/Initial%20Report%2
>> [9]
>> 
>>> 
>> 
> 0on%20the%20Transfer%20Policy%20Review%20-%20Phase%201(a)-21-06-2022/s
>> 
>> 
>>> 
>> 
> ubmissions/NCSG/NCSG%20Response%20-%20Transfer%20Policy%20Review-15-08
>> 
>> 
>>> -2022.pdf
> 
> 
> Links:
> ------
> [1] 
> https://docs.google.com/document/d/1uM38-A98TYK-bED30l4Ue1cFJdNuHaZl/edit?usp=sharing&ouid=105988793481216121706&rtpof=true&sd=true
> [2] 
> https://docs.google.com/document/d/1uM38-A98TYK-bED30l4Ue1cFJdNuHaZl/e
> [3] 
> https://icann.zoom.us/j/98878189584?pwd=ZVpkSVVuaXVqeGRMelNEWW1LMkxQUT
> [4] https://icann.zoom.us/u/ayKmeftWg
> [5] 
> https://community.icann.org/display/TPRPDP/Transfer+Policy+Review+PDP
> [6] 
> https://www.icann.org/en/public-comment/proceeding/initial-report-on-t
> [7] https://community.icann.org/x/OgKkFQ
> [8] https://community.icann.org/x/PAKkFQ
> [9] 
> https://itp.cdn.icann.org/public-comment/proceeding/Initial%20Report%2