[Accred-Model] Letter to ICANN from RiskIQ

[Rubens Kuhl]

Responses inline:

>>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.

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.

>>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

>>includes registration matters pertaining to WHOIS services (as reflected on SSAC’s homepage).



>>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

>>mitigating expected harm from a fragmented WHOIS leading up to the GDPR enforcement deadline.

Is acting immediately possible considering SSAC procedures ?


>>Because there is no guarantee that ICANN will receive a reprieve from enforcement of GDPR, the

>>Board needs to swiftly approve a Temporary Policy to restore ICANN’s Mission.


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.

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.

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.


>>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,
>> 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.

Not when those provisions are not lawful. No contract can exempt parties from following applicable law, otherwise there would be no laws.

>>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,
>>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.
>>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;

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.

>> (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.

More on these topics below.

>>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.

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.

>>“We recommend that the ICANN Board pass a Temporary Policy to make an accreditation plan a reality as soon as practical.”

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.

>>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:

I'll refer to my response to the FIRST letter and John's follow-up comments.

>>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 >>
>>actually being relied on currently to ensure a reasonable level of security. Such security measures include public WHOIS.

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.
It might be somewhat hampered at first, but how to gauge the individual contribution of WHOIS in the mix is challenging.


>>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.

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.

>>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.

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.

>>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.

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.

>>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
>>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.

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.


Rubens






-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/accred-model/attachments/20180421/57d0bcd6/signature.asc>