<div><div><div dir="auto">Rubens,</div></div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">If any registrat would be open to this, please let me know. I am not speaking for the FIRST here in any respect.</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Jonathan</div><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 26, 2018 at 12:48 AM Rubens Kuhl <<a href="mailto:rubensk@nic.br">rubensk@nic.br</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On 25 Jul 2018, at 13:11, Rod Rasmussen <<a href="mailto:rod@rodrasmussen.com" target="_blank">rod@rodrasmussen.com</a>> wrote:</div><br class="m_7920602704554268492Apple-interchange-newline"><div><div class="m_7920602704554268492protected-part"><div class="m_7920602704554268492protected-title">Signed PGP part</div></div></div></blockquote></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div><div class="m_7920602704554268492protected-part"><div class="m_7920602704554268492protected-content"><div style="word-wrap:break-word">Jonathan,<div><br></div><div>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</div></div></div></div></div></blockquote></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div><div class="m_7920602704554268492protected-part"></div></div></blockquote><div><br></div><div><br></div>Rod,</div><div><br></div><div>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. </div><div><br></div><div><br><blockquote type="cite"><div><div class="m_7920602704554268492protected-part"><div class="m_7920602704554268492protected-content"><div style="word-wrap:break-word"><div>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.  ]</div></div></div></div></div></blockquote><div><br></div>This is something to ask web hosting companies for, I believe... not related to ICANN gTLD policies, since ICANN is not a content regulator. </div><div>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. </div><div><br></div><div><br></div><div><br></div><div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><br><blockquote type="cite"><div><div class="m_7920602704554268492protected-part"><div class="m_7920602704554268492protected-content"><div style="word-wrap:break-word"><div>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. </div></div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div>One challenge with logging requestor identities is scale. So anything having that consideration will also be severely throttled. </div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><br><blockquote type="cite"><div><div class="m_7920602704554268492protected-part"><div class="m_7920602704554268492protected-content"><div style="word-wrap:break-word"><div> 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.</div></div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div>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. </div><div>The privacy threat vector is like this:</div><div>Domain A is registered by registrant Activist-A ; data is not published about Activist-A, but hash ID hash-A is. </div><div>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. </div><div><br></div><div>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</div><div><a href="https://rdap.registrar.example/domains?searchtype=domain-a.tld" target="_blank">https://rdap.registrar.example/domains?searchtype=domain-a.tld</a>  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. </div><div><br></div><div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><br><blockquote type="cite"><div class="m_7920602704554268492protected-part"><div class="m_7920602704554268492protected-content"><div style="word-wrap:break-word"><div><br></div><div>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.  </div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div>Having lived thru the EPDP Charter writing exercise, I have to be very skeptical of this, unfortunately. Data addicts are still behaving like addicts. </div><div>(<a href="https://blacknight.blog/icann-panama-will-be-all-about-gdpr-and-data-addiction.html" target="_blank">https://blacknight.blog/icann-panama-will-be-all-about-gdpr-and-data-addiction.html</a>)</div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><br><blockquote type="cite"><div class="m_7920602704554268492protected-part"><div class="m_7920602704554268492protected-content"><div style="word-wrap:break-word"><div><br></div><div>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.</div></div></div></div></blockquote><br></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div>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. </div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><br></div><div><br></div><div>Rubens</div><div><br></div><div><br></div><br></div></blockquote></div></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Jonathan Matkowsky</div>

<br>
<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;background-color:rgb(255,255,255)">******************************</span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;background-color:rgb(255,255,255)"><wbr>******************************</span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;background-color:rgb(255,255,255)"><wbr>*******<br></span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;background-color:rgb(255,255,255)">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.</span><p style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;background-color:rgb(255,255,255)"></p><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;background-color:rgb(255,255,255)">******************************</span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;background-color:rgb(255,255,255)"><wbr>******************************</span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;background-color:rgb(255,255,255)"><wbr>*******</span>