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

Ken Herman ken at KHERMAN.COM
Sun Sep 29 11:20:55 EEST 2024


Hello NCSGers.

Based on comments received, I have updated the text of NCSG comment. I hope it conveys our concerns, and your representatives can emphasize our positions when the comment is discussed at the next working group meeting.

https://docs.google.com/document/d/1uM38-A98TYK-bED30l4Ue1cFJdNuHaZl/edit?usp=sharing&ouid=105988793481216121706&rtpof=true&sd=true

The comment period closes tomorrow, Monday, September 30, so any further written comments must come shortly.

Thanks for all the input received.

Ken
-----Original Message-----
From: NCSG-Discuss <NCSG-DISCUSS at LISTSERV.SYR.EDU> On Behalf Of Ken Herman
Sent: Friday, September 27, 2024 5:55 PM
To: NCSG-DISCUSS at LISTSERV.SYR.EDU
Subject: Re: FW: Draft Comments - FW: Transfer Policy Review Preliminary Report - NCSG Public Comment Discussion

Thanks Kathy. Appreciate the edits and additions. 

I agree that we can press for more than one where they are available, such as SMS, and over the weekend I can have another look to see how these can be added to the comment.

BTW, my understanding is that administrative and technical contacts no longer exist in the registration process (as part of the privacy initiatives), so there is only one contact, which is the RNH. I can make that point in the comment as well.

Ken 

-----Original Message-----
From: NCSG-Discuss <NCSG-DISCUSS at LISTSERV.SYR.EDU> On Behalf Of kathy at DNRC.TECH
Sent: Friday, September 27, 2024 4:38 PM
To: NCSG-DISCUSS at LISTSERV.SYR.EDU
Subject: Re: FW: Draft Comments - FW: Transfer Policy Review Preliminary Report - NCSG Public Comment Discussion

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/e
> dit?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/e
> dit?usp=sharing&ouid=105988793481216121706&rtpof=true&sd=t
> rue
> [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



More information about the Ncsg-discuss mailing list