[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
Tue Aug 8 11:40:32 EEST 2017
Hi Rafik,
As I said - I do not quite get what the first statement means in terms
of issues raised so I can't come up with any suggestion. I wish I could.
As this statement doesn't really contribute to anything and doesn't
raise any issue (although it's supposed to as it is placed in the
"issue" section) I suggest we just remove it for the sake of clarity.
Unless the drafters are ready to clarify or rephrase. But I don't think
removal will change anything in the document except making it clearer.
I am totally supporting your suggestion for removal of anotehr statement
- let's not send the mix messages especially with vague wording proposals.
Thanks!
Tanya
On 08/08/17 08:08, Rafik Dammak wrote:
> Hi Tatiana,
>
> Thanks for the comments,
> while we are late by our deadline to submit a comment, I think we can
> solve the concerns.
> 1/ do you have a proposal of rephrasing for the first statement?
> 2/ I understand your concerns and indeed doesn't seem aligned with our
> previous stances regarding domain suspension. probably we can remove that.
>
> really looking forward to solving this within the next 24hours.
>
> Best,
>
> Rafik
> 2017-08-05 6:56 GMT+09:00 Dr. Tatiana Tropina <t.tropina at mpicc.de
> <mailto:t.tropina at mpicc.de>>:
>
> 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 <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 <mailto:NCSG-PC at lists.ncsg.is>
> https://lists.ncsg.is/mailman/listinfo/ncsg-pc
> <https://lists.ncsg.is/mailman/listinfo/ncsg-pc>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncsg.is/pipermail/ncsg-pc/attachments/20170808/43612d7a/attachment.htm>
More information about the NCSG-PC
mailing list