[Accred-Model] Codes of conduct

Tue Jul 31 00:13:48 UTC 2018

Rubens,

Rod is correct here that incident responders need to work in tandem to
mitigate compromised sites, and not only rely on the hosting providers.
Please see the correspondence in this regard posted previously to the GDPR
correspondence list regarding technical and admin contacts.

RiskIQ has seen negative impact in this regard from having to work with
registrars to get this information manually, and we need this to scale.
There are definitely many compromised sites staying up longer than they
otherwise would be prior to GDPR. I predicted this in the RDS WG in a
discussion with Greg Aaron--Krebs on Security discussed it in an article
pre-GDPR, and warned about it. And it *has* happened. So, while my views
have significantly changed in many respects, this is one area that
everybody should pay close attention to if they care about protecting the
rights and freedoms of individuals. They are the ones most impacted here by
the privacy interference. And its a relatively easy fix once we have codes
of conduct as approved by the Commission. In the short term, any member of
FIRST (and similar incident response organizations) should for now be able
to use RDAP or a special email alias from a registrar to obtain these
fields when strictly necessary to mitigate compromised sites that have not
been patched within 6 hours, subject to adequacy mechanisms in my opinion,
as FIRST computer emergency response teams already have gone through
vetting, onsite inspections, etc.

If any registrat would be open to this, please let me know. I am not
speaking for the FIRST here in any respect.

Cheers,
Jonathan

On Thu, Jul 26, 2018 at 12:48 AM Rubens Kuhl <rubensk at nic.br> wrote:

>
>
> On 25 Jul 2018, at 13:11, Rod Rasmussen <rod at rodrasmussen.com> wrote:
>
> Signed PGP part
>
> Jonathan,
>
> Thank you very much for your thoughts here!  To me, this analysis of yours
> screams for standards so that this can scale, otherwise we will end up with
> a system that is far too much dependent upon manual determination of issues
> by all parties to be useful in the real world of abuse that moves at
> automated speeds (i.e. the bad guys registering or compromising domains at
> scale (each using thousand of domains per day via automation).  My thesis
> is that you need a well-defined taxonomy of abuse types, domain abuse
> scenarios (e.g. abusively registered, compromised in-part, compromised
> in-full), and threat level (e.g. ongoing mass attack, ongoing targeted
> attack, potential attack).  From that you can build a matrix of what
> information is required, what information about requestors can be readily
> revealed, and who is requested to make what kind of actions and in what
> timeframe.  For example, for a wide-scal
>
>
>
> Rod,
>
> Note that compromised sites are not related to domain registration, but to
> web hosting. A domain registrar or registry can only possibly have a role
> in abusively registered domains. The RIRs/NIRs WHOIS is still mostly
> unredacted even after GDPR, and that's information that can help either in
> abuse tracking or abuse take-down.
>
>
> e, current phishing attack using a compromised website, a very timely
> response (within minutes or hours) of a technical contact and registrant
> contact e-mail and phone number would facilitate solving both the phishing
> attack and the potential for the registrant to be exposing PII of its own
> users given that their website tied to a domain is compromised.  ]
>
>
> This is something to ask web hosting companies for, I believe... not
> related to ICANN gTLD policies, since ICANN is not a content regulator.
> i2Coalition has shown a keen interest in making reporting and acting on
> reports as smooth and reliable as possible, so it might be a forum for such
> requests.
>
>
>
>
> The identity of the requestor would not need to be confidential in such a
> scenario since they *want* the registrant to know that the registrant has a
> serious problem to solve that could put the registrant in dire straits
> vis-a-vis GDPR.
>
>
> One challenge with logging requestor identities is scale. So anything
> having that consideration will also be severely throttled.
>
>  Separately, a detection of potentially malicious set of domain
> registrations that have a high probability that they will be used to launch
> various fraudulent and illegal scams based on prior observed behavior could
> result in a longer-term response (day/days) with full information about the
> registrant of the domain(s) and even other domains registered at near the
> same time, being provided with the requestor’s information not being
> revealed to the registrant without them going through process themselves.
> The main thing is to agree on what information is appropriate to reveal and
> how long the responses should take. From there, all parties can build
> automated systems to create and accept responses for contact information
> requests, with attestation of the harms driving the actual process that
> ensues.
>
>
> I believe the cross-reference of registered domains is better served by
> pseudonimization than by full data requests. The problem with it is that
> due to the risk that of revealing PII, at this point I don't see this
> flying by DPAs or courts.
> The privacy threat vector is like this:
> Domain A is registered by registrant Activist-A ; data is not published
> about Activist-A, but hash ID hash-A is.
> Domain B is also registered by Activist-A, but data on it is published,
> showing both Activist-A data and hash-A. Now the privacy attacker knows who
> registered Domain A.
>
> So, the only possible request for this kind information I see as not
> violating GDPR is a search by domain that only returns domain data in a
> similar redaction level. For instance, something like
> https://rdap.registrar.example/domains?searchtype=domain-a.tld  that
> would return other domains by the same registrant that also doesn't reveal
> PII. In answering that request, registrar would have to verify that all the
> domains in the result has the same redaction level as domain-a, and only
> return those in that redaction level. No registry-level or cross-registrar
> query would allow that verification so only that listing query would be
> possible.
>
>
>
> It’s all about proportionality and the ability for various harms to be
> balanced in a non-biased fashion.  I think that if we can approach the
> various scenarios dispassionately and scientifically, we could provide
> solid guidance on how any request for registration contact information is
> dealt with across all registrar/registry players *and* requestors.  The key
> is putting together a good matrix that all stakeholders can live with, and
> then making sure people involved in this in all roles understand how to
> work within the system properly and *do*so.
>
>
> Having lived thru the EPDP Charter writing exercise, I have to be very
> skeptical of this, unfortunately. Data addicts are still behaving like
> addicts.
> (
> https://blacknight.blog/icann-panama-will-be-all-about-gdpr-and-data-addiction.html
> )
>
>
> The current ad-hoc situation on both the requestor and provider sides is
> untenable and is already on the path to major negative consequences for
> all.  Beyond the waste of manpower and unintentional abetting of crime that
> we’re already seeing, my major fear is that these negative consequences
> eventually draw the attention of various national governments whose
> citizens are being abused, who then decide how things should work instead
> of the parties actually involved.  That scenario historically doesn’t work
> out well for the affected parties.
>
>
> Most privacy/proxy are already hiding registrants in jurisdictions this is
> not allowed (like Brazil), so people only seem to care about legislation
> when it comes from markets above a certain part of revenue or depending on
> how costly fines are. As of now, only USA, Europe and China meet those
> thresholds... any other national government legislating on it will simply
> make the gTLD industry move elsewhere.
>
>
> Rubens
>
>
>
> --
Jonathan Matkowsky

-- 
*******************************************************************
This 
message was sent from RiskIQ, and is intended only for the designated 
recipient(s). It may contain confidential or proprietary information and 
may be subject to confidentiality protections. If you are not a designated 
recipient, you may not review, copy or distribute this message. If you 
receive this in error, please notify the sender by reply e-mail and delete 
this message. Thank you.

*******************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accred-model/attachments/20180731/7d4fd63d/attachment.html>