[NCSG-PC] Fw: [NCUC-DISCUSS] Suggested Comment: Draft Framework for Registry Operators to Respond to Security Threats
Dr. Tatiana Tropina
t.tropina at mpicc.de
Sat Aug 5 00:56:18 EEST 2017
Hi all,
I have a couple of comments:
1) I have hard time making sense of the first point:
"1. Registry Response, Responsible Parties
“ROs are not necessarily the best parties to address certain security
threats. The identification of the parties considered as being most
relevant and appropriate in resolving the security threat is critical to
the prompt resolution of the matter.”
More specifically, responsibility of identifying security threats
connected to New gTLDs and resolving them when possible rests with ROs."
As this point is a part of the comment that refers to the "issue" I
wonder what is this - a statement? What kind of issue is identified
here? Are we recommending anything? If not and if this is just an
introduction, may be it's better to rephrase? May be it's just too late
here but I struggling with what this "issue" implies.
2) I wonder if this one is really in line with NSCG values such as due
process:
2. We ask you to consider including the following GAC recommendation in
Registry Response:
“If Registry operator identifies risk of harm, Registry operator will
notify the relevant registrar and , if the registrar does not take
immediate action, suspend the domain name until the matter is resolved.”
The framework already lists the actions that Registry can take even in
the case if "a negative or non-existent response from the Registrar",
which "should not
preclude the Registry from taking action". I do not like the notion of
"immediate action" as it sound to vague to me and I believe that there
are enough actions listed to address the issue under the framework
rather than suspension of domain name - again, "till the matter is
resolved" looks too vague. I don't think it's acceptable when it comes
to such a matter as a suspension of domain name. I know enough cases of
mistakes when due to abuse claims customers went dark, etc. I suggest we
rather be careful here. But if everyone is comfortable with this
suggestion, I'll surrender.
Warm regards,
Tanya
On 04/08/17 09:39, Rafik Dammak wrote:
> Dear PC members,
>
> any comment on the draft? we got an extension till 6th August, we
> should review quickly and make a decision.
>
> Best,
>
> Rafik
>
> 2017-07-31 19:33 GMT+09:00 Rafik Dammak <rafik.dammak at gmail.com
> <mailto:rafik.dammak at gmail.com>>:
>
> Hi Ayden,
>
> Yes it is for PC review. We worked on it the last days with Juan,
> Dina and Niels. James cannot response since is off for the coming
> days. I was going to send email to related ICANN staff to inform
> that we will make a late submission, hopefully by end of this week.
>
> Best,
>
> Rafik
>
>
> On Jul 31, 2017 7:18 PM, "Ayden Férdeline" <icann at ferdeline.com
> <mailto:icann at ferdeline.com>> wrote:
>
> I believe the PC is being asked to review this comment which
> has been drafted by Dina and Juan. The submission deadline for
> comments on this issue is today, but I suspect we will not be
> able to meet that, so let's try for this Friday? I think we
> need to bring in a topic expert, James Gannon (cc'd), to get
> his opinion on this comment, too -- because I am happy to
> raise my hand and say I do not know anything about this topic.
>
> Best, Ayden
>
>
>> -------- Original Message --------
>> Subject: [NCUC-DISCUSS] Suggested Comment: Draft Framework
>> for Registry Operators to Respond to Security Threats
>> Local Time: July 30, 2017 11:24 PM
>> UTC Time: July 30, 2017 10:24 PM
>> From: thomascovenant at thomascovenant.org
>> <mailto:thomascovenant at thomascovenant.org>
>> To: NCUC-discuss <ncuc-discuss at lists.ncuc.org
>> <mailto:ncuc-discuss at lists.ncuc.org>>
>>
>> Hello,
>>
>> the comment proposal is underneath, what are your thoughts?
>>
>> https://docs.google.com/document/d/1TfgHuMqzD660_CHLQMXMW4phnBtLSP94j6X5riY2Ko4/edit
>> <https://docs.google.com/document/d/1TfgHuMqzD660_CHLQMXMW4phnBtLSP94j6X5riY2Ko4/edit>
>>
>> Note from Security Framework Drafting Team wiki workspace:
>>
>> - Is Public Comment required for the draft Framework?
>> - This is not a policy implementation nor a contractual
>> requirements document; therefore, a public comment proceeding
>> would not be required. However, SFDT has decided to conduct a
>> public comment for broader community feedback prior to
>> finalization of the Framework.
>>
>> Main points:
>>
>> - Framework should be expanded
>> - Several minor details are to be clarified, restructuring
>> proposal
>> - as a small step in response to proposed detailed report
>> examination, I suggest we include a recommendation on
>> Responsible Threat Disclosure.
>>
>> Finally, I quote Point 3 from the Comment:
>>
>> "Since the following examination of threat report is
>> identified in the Framework, we strongly suggest including a
>> recommendation on Responsible Threat Disclosure to be
>> included in the document:
>>
>> "Each RO should scrutinize, question or otherwise inquire
>> about the legitimacy of the origin
>> of a request, in accordance with their own internal policies
>> and processes."
>>
>> We have seen a broad variation in handling security threat
>> reports, varying from constructive actions addressing the
>> issues to punishment of the reporting party. Benefits of
>> responsible threat submission are obvious.
>>
>> In this context, it is important to underline benefits and
>> importance of responsible threat disclosure. We request
>> recommendation to extend goodwill and not cause harm to the
>> reporting party whenever possible:
>>
>> When applicable, RO should provide:
>>
>> - an easy way to report security threats and violation
>> - encrypted ways of communication
>> - option of anonymous submission"
>>
>> Other:
>>
>> - This is my first comment drafted with input from Juan
>> Manuel Rojas (thank you for commenting). Access to shared
>> document and request for review was given to those who
>> expressed interest in working on it. All input from the list
>> is very welcome. Please let me know what needs to be
>> corrected and I will promptly do it.
>> - Comment is a bit late, I will request an extra week to
>> discuss the proposal with my humble excuses.
>>
>> BR,
>> Dina Solveig Jalkanen
>> --
>> * * *
>> Friendly geek in Amsterdam, FSFE Fellow
>> https://wiki.techinc.nl/index.php/User:Thomascovenant
>> <https://wiki.techinc.nl/index.php/User:Thomascovenant>
>>
>>
>> _______________________________________________
>> Ncuc-discuss mailing list
>> Ncuc-discuss at lists.ncuc.org <mailto:Ncuc-discuss at lists.ncuc.org>
>> http://lists.ncuc.org/cgi-bin/mailman/listinfo/ncuc-discuss
>> <http://lists.ncuc.org/cgi-bin/mailman/listinfo/ncuc-discuss>
>
>
> _______________________________________________
> NCSG-PC mailing list
> NCSG-PC at lists.ncsg.is <mailto:NCSG-PC at lists.ncsg.is>
> https://lists.ncsg.is/mailman/listinfo/ncsg-pc
> <https://lists.ncsg.is/mailman/listinfo/ncsg-pc>
>
>
>
>
>
> _______________________________________________
> NCSG-PC mailing list
> NCSG-PC at lists.ncsg.is
> https://lists.ncsg.is/mailman/listinfo/ncsg-pc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncsg.is/pipermail/ncsg-pc/attachments/20170804/663c0a16/attachment.htm>
More information about the NCSG-PC
mailing list