[Accred-Model] Codes of conduct

Thu Jul 26 09:16:43 UTC 2018

+1.

Any response framework that does not at least acknowledge the mechanisms of
malfeasance - in this case bad domain names that are availabe almost
realtime - would not be fit for purpose.

-Carlton

On Wed, 25 Jul 2018, 2:41 pm Rod Rasmussen, <rod at rodrasmussen.com> wrote:

> 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-scale, 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.  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.  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.
>
> 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.
>
> 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.
>
> My 2 cents.
>
> Cheers,
>
> Rod Rasmussen
> Speaking personally and not on behalf of any organization I am part of.
>
> On Jul 16, 2018, at 3:54 PM, jonathan m <jonathan.matkowsky at riskiq.net>
> wrote:
>
> All,
>
> Any model that doesn’t take into account for transparency of processing
> that a data subject has the right to typically object and freeze the
> processing is not compliant with GDPR. I think the registrar as a
> controller must also have the right to object. That doesn’t mean that the
> processing won’t eventually continue if it is compelling and overrides the
> rights and freedoms of the individual but subject to Chapter 7 of the GDPR.
>
> When safety is a concern, then as long as the data subject knows which
> supervisory authority is overseeing the code of conduct under which the
> request is being made, it’s possible to protect the identity of the
> requestor. This should be relatively rare.
>
> Not every legitimate interest outweighs the rights and freedoms of the
> data subject, and a privacy impact assessment is required. Not every
> legitimate interest is entitled to the same weight under GDPR, and the
> risks and severity of harm to the person must be considered especially when
> certain interests at stake aren’t the same as those of the controller.
>
> We need RDAP to accommodate these concerns. When law enforcement has
> legitimate interests, they can use the same RDAP tier of access, but when
> pursuing a criminal offense or investigation, a different model of access
> must be accommodated under the LED etc.
>
> Ignoring these issues won’t make them go away.  I hope that truly
> consensus-building voices participate in the EPDP, because it’s time we
> stop trying to keep Whois to the greatest extent possible and instead
> design the next generation to be better—more accurate, with more
> accountability and integrity but also consistent with data protection laws
> and internationally recognized norms. It makes sense to generally treat all
> people — regardless of where they reside, with the same inherent rights and
> freedoms that European laws are attempting to protect.
>
> Jonathan Matkowsky
> VP - Cybersecurity, Privacy & IP
> JD, CIPT, CIPP/EU
> RiskIQ, Inc.
>
>
>
>
>> --
> 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.
>
> *******************************************************************
> _______________________________________________
> Accred-Model mailing list
> Accred-Model at icann.org
> https://mm.icann.org/mailman/listinfo/accred-model
>
>
> _______________________________________________
> Accred-Model mailing list
> Accred-Model at icann.org
> https://mm.icann.org/mailman/listinfo/accred-model
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accred-model/attachments/20180726/0fba99c7/attachment-0001.html>