<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body dir="auto">
Rubens,
<div><br>
</div>
<div>See some preliminary responses below to your responses. I will likely have additional ones later, but am traveling and these jump out at me:</div>
<div><br>
</div>
<div>
<blockquote type="cite"><span style="-webkit-text-size-adjust: auto; text-decoration: -webkit-letterpress;">No contract can exempt parties from following applicable law, otherwise there would be no laws.</span></blockquote>
<br>
</div>
<div>This is not true in the U.S. In the U.S. Courts may choose to enforce some provisions in contracts even though they violate applicable law. If course I recognize that EU and EU member state law are applicable here in the relevant cases, but are you certain
that the same is not true in all EU and member state courts? Have you done legal research on this or are you just making a logical conclusion? If the latter, often times logical conclusions and how the law is drafted or applied are not the same. I
<span style="background-color: rgba(255, 255, 255, 0);"> would also point out that we do not know that showing registrant name and email violates GDPR and there is no evidence or indication that there is not a sufficient legitimate interest to display such
that doesn't outweigh the data subject's interest in privacy. </span></div>
<div><br>
</div>
<div>
<blockquote type="cite"><span style="-webkit-text-size-adjust: auto; text-decoration: -webkit-letterpress;">While WHOIS was an useful correlation tool, other techniques such as Passive DNS(2004) have been providing real good intelligence from actual attempts
at bypassing security... so it's not fair to say that without WHOIS, everything falls apart.</span></blockquote>
<br>
</div>
<div>This could only be said by someone who does not do online enforcement on an everyday or even regular basis. As someone who does, I can assure you that WhoIs is the foundation and starting point for all online investigation and enforcement and without
it those conducting such efforts to protect everyone, including you, like law enforcement, researchers, and intellectual property owners, will be blind. This is particularly the case that the majority of attacks now are not content (i.e.) website based. Without
WhoIs that shows registrant name and email there is no effective online investigation and enforcement, plain and simple. </div>
<div><br>
</div>
<div>
<blockquote type="cite"><span style="text-decoration: -webkit-letterpress; background-color: rgba(255, 255, 255, 0);">"force majeure" clause that, among othe</span><span style="-webkit-text-size-adjust: auto; text-decoration: -webkit-letterpress;">r things,
prevents liability from change of applicable law.</span></blockquote>
</div>
<div><br>
</div>
<div>Most force majeure clauses I have seen in contracts, including those governed by EU member state law do not include change in law as a trigger. Rather they refer to things like "Acts of God", strikes, and natural disasters. But even if such clauses do
cover change in law, as I mentioned above, <span style="background-color: rgba(255, 255, 255, 0);">
we do not know that showing registrant name and email violates GDPR and there is no evidence or indication that there is not a sufficient legitimate interest to display such that doesn't outweigh the data subject's interest in privacy. </span></div>
<div><br>
<br>
<div id="AppleMailSignature">
<div><br>
</div>
<div>Best Regards,</div>
<b>
<div><b><br>
</b></div>
Marc H.Trachtenberg</b>
<div>
<div>Shareholder</div>
<div>Greenberg Traurig, LLP</div>
<div>77 West Wacker Drive</div>
<div>Chicago, IL 60601</div>
<div>Office (312) 456-1020</div>
<div>Mobile (773) 677-3305</div>
</div>
</div>
<div><br>
On Apr 20, 2018, at 11:20 PM, Rubens Kuhl <<a href="mailto:rubensk@nic.br">rubensk@nic.br</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div><span></span><br>
<span>Responses inline:</span><br>
<span></span><br>
<blockquote type="cite">
<blockquote type="cite"><span>With respect to the draft IPC/BC Accreditation and Access Model for Non-Public Whois Data, RiskIQ notes that the fact that security interests are being represented by some organizations whose >>representatives happen to be SSAC
members is not the same thing as saying that SSAC members are representing security interests in the community discussion.</span><br>
</blockquote>
</blockquote>
<span></span><br>
<span>Exactly, but it does not seem the discussion group is lacking security conscious vocal participants, such as yourself, John Levine, Maarten Van Horenbeck, Tim Chen... they don't represent SSAC and SSAC doesn't represent all security practitioners, but
I don't feel a gap here.</span><br>
<span></span><br>
<blockquote type="cite">
<blockquote type="cite"><span>SSAC is responsible under the Bylaws to make policy recommendations to the ICANN Community and Board relating to, amongst other things, the security of the Internet’s naming system.1 This</span><br>
</blockquote>
</blockquote>
<span></span><br>
<blockquote type="cite">
<blockquote type="cite"><span>includes registration matters pertaining to WHOIS services (as reflected on SSAC’s homepage).</span><br>
</blockquote>
</blockquote>
<span></span><br>
<span></span><br>
<span></span><br>
<blockquote type="cite">
<blockquote type="cite"><span>SSAC should immediately weigh in for the ICANN Community, and so advise the Board to approve a Temporary Policy with a sense of urgency to preserve the security of the Internet’s name system by</span><br>
</blockquote>
</blockquote>
<span></span><br>
<blockquote type="cite">
<blockquote type="cite"><span>mitigating expected harm from a fragmented WHOIS leading up to the GDPR enforcement deadline.</span><br>
</blockquote>
</blockquote>
<span></span><br>
<span>Is acting immediately possible considering SSAC procedures ?</span><br>
<span></span><br>
<span></span><br>
<blockquote type="cite">
<blockquote type="cite"><span>Because there is no guarantee that ICANN will receive a reprieve from enforcement of GDPR, the</span><br>
</blockquote>
</blockquote>
<span></span><br>
<blockquote type="cite">
<blockquote type="cite"><span>Board needs to swiftly approve a Temporary Policy to restore ICANN’s Mission.</span><br>
</blockquote>
</blockquote>
<span></span><br>
<span></span><br>
<span>That's not how legal risk management works. Conscious people don't try pushing the limits of the law, they are conservative and advance only with proper care.</span><br>
<span></span><br>
<span>Which is quite similar to how IT risk management works; people don't deploy untested systems just to see if they are vulnerable, they do testing or rely on previous 3rd party tests before moving forward.</span><br>
<span></span><br>
<span>That's why it keeps surprising me that people in their own areas of expertise act in a way, but keep telling others to be reckless.</span><br>
<span></span><br>
<span></span><br>
<blockquote type="cite">
<blockquote type="cite"><span>As background, Registrars must comply with and implement all specifications or policies established by the Board on a temporary basis, if adopted by the Board by at least two-thirds of its members,</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>so long as the Board reasonably determines that such modifications or amendments are justified and that immediate temporary establishment of a specification or policy on the subject is necessary to maintain the stability or security
of Registrar >>Services, Registry Services or the DNS or the Internet.</span><br>
</blockquote>
</blockquote>
<span></span><br>
<span>Not when those provisions are not lawful. No contract can exempt parties from following applicable law, otherwise there would be no laws.</span><br>
<span></span><br>
<blockquote type="cite">
<blockquote type="cite"><span>Under the ICANN Bylaws, the Chair of the Board or the President or at the request of one-quarter of the Directors may call for a Special meeting made by the Secretary.3 We strongly recommend that SSAC weigh in to this community
discussion,</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>and advise whether it agrees that the Board should utilize this provision to establish an enforceable Temporary Policy to preserve the security of the Internet’s name system by mitigating harm from a fragmented WHOIS.</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>In our view, such a Temporary Policy would cover three general areas: (1) the criteria for accessing the non-public data set for security or stability of the Internet’s naming system;</span><br>
</blockquote>
</blockquote>
<span></span><br>
<span>The security or stability of the Internet naming system is not determined by WHOIS. That's why even ICANN is not considering that argument for the temporary policy.</span><br>
<span></span><br>
<blockquote type="cite">
<blockquote type="cite"><span>(2) IP whitelisting security parameters and rate limiting restrictions associated with such access; and (3) the format for contracted parties to use for the WHOIS output.</span><br>
</blockquote>
</blockquote>
<span></span><br>
<span>More on these topics below.</span><br>
<span></span><br>
<blockquote type="cite">
<blockquote type="cite"><span>All three areas must be narrowly tailored as feasible for purposes of preserving the security or stability of the Internet’s name system until a community PDP will endeavor to formulate a permanent compliance model for WHOIS, or
its replacement, within what will inevitably turn into a one-year temporary policy period.</span><br>
</blockquote>
</blockquote>
<span></span><br>
<span>One of the challenges is that security is not the only field with issues with a slimmed-down WHOIS, and ICANN needs to address all the best way they can in a single temporary policy. And if business interests and security interests play prisoner's dilemma
on this, they both loose. Because I come from a security background I'm more fond of the security aspects of this problem, but I have to recognise that for each person, their favorite problem matters more.</span><br>
<span></span><br>
<blockquote type="cite">
<blockquote type="cite"><span>“We recommend that the ICANN Board pass a Temporary Policy to make an accreditation plan a reality as soon as practical.”</span><br>
</blockquote>
</blockquote>
<span></span><br>
<span>From the current pace of discussions, I don't think we are close to a point of baking the accreditation system into a temporary policy. I believe we are close, although not there yet, for what will become the new public WHOIS.</span><br>
<span></span><br>
<blockquote type="cite">
<blockquote type="cite"><span>With respect to (2) IP whitelisting security parameters and rate limiting restrictions, RiskIQ, like the FIRST, M3AAWG, and APWG, supports the proposal to enforce use of an interim IP Whitelist for access to the registrant contact
information in >>WHOIS data for anti-abuse, threat intelligence, and incident response while a more mature accreditation plan is being implemented. As The FIRST stated:</span><br>
</blockquote>
</blockquote>
<span></span><br>
<span>I'll refer to my response to the FIRST letter and John's follow-up comments.</span><br>
<span></span><br>
<blockquote type="cite">
<blockquote type="cite"><span>In our view, temporary disruption of continuous access for security purposes such as incident response, abuse reporting, threat intelligence and anti-abuse is otherwise likely to impair the technical and organizational security
measures that are >></span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>actually being relied on currently to ensure a reasonable level of security. Such security measures include public WHOIS.</span><br>
</blockquote>
</blockquote>
<span></span><br>
<span>While WHOIS was an useful correlation tool, other techniques such as Passive DNS(2004) have been providing real good intelligence from actual attempts at bypassing security... so it's not fair to say that without WHOIS, everything falls apart.</span><br>
<span>It might be somewhat hampered at first, but how to gauge the individual contribution of WHOIS in the mix is challenging.</span><br>
<span></span><br>
<span></span><br>
<blockquote type="cite">
<blockquote type="cite"><span>With respect to the (3) format for contracted parties to use for the WHOIS output, RiskIQ believes it is practical at this point to take a two-tiered approach: records for newly registered domains versus what to do with the existing
records. For newly >>registered organizational domains, it is critical to instruct the contracted parties in the Temporary Policy not to collect personal data that is not required to be collected and that otherwise should remain in the public data set from
a security >>perspective. A requirement that the registrant org email be in the format of “Admin” or “Manager” [at] second level domain would avoid GDPR concerns all together, and keep the registrant org email address for newly registered domains in the >>public
data set for security, which serves ICANN’s Mission. Without this information in the public data set, organizations have less visibility into their own organization’s digital footprint. If an organization cannot see which domains were registered >>from its
corporate accounts, then these overlooked sites will not end up having vulnerability scanning, and makes them more susceptible to targeted exploits.</span><br>
</blockquote>
</blockquote>
<span></span><br>
<span>I don't see GDPR making a distinction between data collected before the enforcement date, and since it was passed 14 April 2016, even if a cut-off date could be established, that would be more like it.</span><br>
<span></span><br>
<blockquote type="cite">
<blockquote type="cite"><span>With respect to existing WHOIS records for organisational domains, a Temporary Policy should allow the contracted parties to obfuscate or mask only the local part of the registrant organizational email address in the public data
set to the extent >>they deem it necessary or advisable from a privacy perspective. The local part is the only part of the organizational email address that poses any possible risk of containing information relating to a natural data subject that arguably
should not >>have been collected. There should be a conspicuous notice that goes out allowing registrant organizations to opt-out from masking the local part of the organizational email in existing records, explaining the upside and downside from a privacy
>>and security perspective.</span><br>
</blockquote>
</blockquote>
<span></span><br>
<span>One more e-mail template to have fakes and phonies sent to registrants ? No thanks. Domain control panel warnings sound more of a solution to me.</span><br>
<span></span><br>
<blockquote type="cite">
<blockquote type="cite"><span>We want to close by taking this opportunity to express our concern that by not getting adequate consent from individual registrants to mask their existing data from public WHOIS, GDPR is being used to unilaterally change the security
>>environment under which registrants agreed to process their data to begin with. Individual registrants should be given the opportunity to opt- in to continuing to disclose their information in public WHOIS, as to mask it without their permission >>changes
the technical and organisational measures used to ensure a level of security appropriate to the risk.</span><br>
</blockquote>
</blockquote>
<span></span><br>
<span>This will take a bit of time but a disclose option will likely be implemented by contracted parties, for reasons including market forces. This his been addressed in a CPH letter to ICANN.</span><br>
<span></span><br>
<blockquote type="cite">
<blockquote type="cite"><span>Many that have registered domains did so subject to the understanding that public WHOIS is in place, and available for the threat >>intelligence, anti-abuse and incident response. This transparency and open directory is part of
the checks and >>balances used to ensure the security of domains because the contracted parties can always be notified using this public</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>WHOIS directory and services that they have been compromised, and the registrants could expect public WHOIS contact information to be leveraged to contact them if their domains have been compromised. The current threat landscape
is >>premised on this information being available publicly and used to mitigate threats.</span><br>
</blockquote>
</blockquote>
<span></span><br>
<span>That's an interesting angle, but most agreements have some kind of "force majeure" clause that, among other things, prevents liability from change of applicable law. But as soon as registrars willing to provide such disclose options start getting more
market share from registrants concerned with this, such feature will likely spread like wildfire. The registrar-registry integration in thick registries will take longer, unfortunately; while protocol designers have thought of privacy regulations from the
inception of the EPP protocol, full data publication was taken for granted so it was seldom implemented.</span><br>
<span></span><br>
<span></span><br>
<span>Rubens</span><br>
<span></span><br>
<span></span><br>
<span></span><br>
<span></span><br>
<span></span><br>
<span></span><br>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>Accred-Model mailing list</span><br>
<span><a href="mailto:Accred-Model@icann.org">Accred-Model@icann.org</a></span><br>
<span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accred-2Dmodel&d=DwMGaQ&c=2s2mvbfY0UoSKkl6_Ol9wg&r=r5rx-kI5Cxza1vQgpUa9uXTHEPmarcD6Ch-F3m5O9fQ&m=sHHmCZTDXdmHlgaHFiRxc8WBeG5ny4N6XjSymFG0tQI&s=3K8KA4qgEfMke2_mGqatcn_7GaAhxP1ZeKuEHna5s80&e=">https://mm.icann.org/mailman/listinfo/accred-model</a></span><br>
</div>
</blockquote>
</div>
<HR>If you are not an intended recipient of confidential and privileged information in this email, please delete it, notify us immediately at postmaster@gtlaw.com, and do not use or disseminate such information.<BR>
</body>
</html>