Volker,

Your concern is noted.

We will discuss submitted early inputs in one of the next plenary meetings.

I would like to use this opportunity to encourage team members raise their voice during the meetings if you are not sure about the proposal of the Chair. Without seeing body language, it is hard to say if proposal is acceptable. I take silence as approval.

Best regards

JK

From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Volker Greimann
Sent: Friday, July 26, 2019 6:20 PM
To: gnso-epdp-team@icann.org
Subject: Re: [Gnso-epdp-team] Notes and action items from EPDP Meeting #12 - 25 July 2019

Hi Ariel,

we are concerned with your assumption under Action Item 1.

We were working under the understanding that this would be subject to another plenary session and we did not have sufficient time to deliberate the eqarly input document with the entire group.  Also, just because no clarifying questions have been raised does not mean that the contents of the document are a consensus position agreed by all. No questions means just that, no questions. But not necessarily agreement.

We may very well end up agreeing with the contents of the document, but we are not there yet.

We therefore respectfully request that this not be taken as basis for drefting the initial report quite just yet.

Best regards,

Volker Greimann

Am 26.07.2019 um 17:10 schrieb Ariel Liang:

Dear EPDP Team:

Below, please find the notes and action items from yesterday’s EPDP Team Meeting.

As a reminder, the next EPDP Team Meeting will be Thursday, 1 August at 14:00 UTC.

Best regards,

Marika, Caitlin, Berry (and Ariel – assisted with notetaking)

EPDP Phase 2 - Meeting #12

Thursday, 25 July 2019 at 14:00 UTC

Action Items: 

1. If no further clarifying questions are submitted in response to the early input document by the deadline (25 July 2019), staff to consider the comments in the development of the draft policy recommendations and draft Initial Report. 
2. Staff to set up survey for the EPDP Team to rank and identify the most representative case in each group of the use case categorization. EPDP Team to complete the survey by COB Monday, 29 July. 
3. Staff to compile the input submitted on automation/accreditation to assist the EPDP Team in its substantive discussions during next week’s call and future calls. Leadership team to develop initial thoughts paper on accreditation to kick start discussions.
4. Chris Lewis-Evans to incorporate input received from the EPDP Team and continue fine tuning the use case (GAC LEA1-13719-1), which is expected to be attached in the annex to the Initial Report. Updated version to be posted on the Wiki and the leadership to make a further recommendation for how to finalize the use case. 
5. In meeting on Thursday, 1 August, the EPDP Team to devote part of the meeting to discuss initial reaction from members on the SSAC Crime-Abuse Investigation Use Case. EPDP Team to provide input by writing no later than 14:00 UTC on Monday, 29 July. More detailed discussion about this use case will take place in the meeting on 8 August. 

Notes 

These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/l6ajBg

1. Roll Call & SOI Updates (5 minutes)

• Attendance will be taken from Zoom
• Remember to mute your microphones upon entry to Zoom, which is typically the first icon on the left on the bottom toolbar.
• Please state your name before speaking for transcription purposes.
• Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team

2. Confirmation of agenda (Chair)

• No objections 

3. Welcome and housekeeping issues (Chair) (10 minutes)

a) Update from Legal Committee

• Started out by reviewing prior session’s action items and questions 
• Reviewed the remaining questions, narrowed down the scope, and those questions will be evaluated based on the needs of Phase 2. Near term goal is to understand all the legal requirements and try to develop sizing for requesting additional resources from the Board. 
• Next LC meeting is 6 August. 

b) Early input review status (deadline 25 July)

• A number of groups responded to the EPDP Team’s request for early input. This input was subsequently organized by staff in the form of an early input review tool. 
• Following EPDP Team discussion, input regarding SSAD has been incorporated into SSAD worksheet for EPDP Team review. In addition, the EPDP Team agreed to review the input received and document any clarifying questions in the google doc that was created.
• Deadline for clarifying questions on the early input was Thursday 25 July. No comments/questions were received at the time of the call. 
• ACTION ITEM: If no further clarifying questions are submitted in response to the early input document by the deadline (25 July 2019), staff to consider the comments in the development of the draft policy recommendations and draft Initial Report. 

4. Use Cases Categorization (10 minutes)

a) Review proposed categorization put forward by small team

• A small group of volunteers agreed to work with staff. Based on the original staff categorization and incorporating input from NCSG, BC and IPC, staff/volunteers went through a number of iterations to review the use cases. Important to note that no use case has been eliminated as a result of this exercise. Objective is to identify the most representative case for each category as a starting point for the deliberations. Following review of the most representative use case in each category, the EPDP Team can then decide whether additional cases need to be reviewed. 
• 5 groups, as noted on the document. 
• Appreciation to Milton, Margie, Chris, and Brian for their contributions to this exercise. 
• Chair’s proposal: Identify in each group, the most representative use case that the EPDP Team should look at first, starting from Group 1. 
• We have already made decisions where to start. First group 1. After that, group 2, move to group 4 and then group 3 or 5. 
• Staff to put in survey format and ask EPDP Team members to respond to the survey by COB Monday, 29 July. 
• Review the representative use case first, and see whether any issue associated other use cases that warrant being reviewed. Not sure whether there is time to do an in depth review of each of them. 
• For the rest of the cases, maybe only look at the differences instead of an in depth review. 
• Would it be useful to map the stages (e.g., a series of questions) that a compliant organization must go through as it determines whether it is a legitimate request for information. Who? What scope? Under what authority? Etc. Left column of the use cases are geared toward answering those questions and providing a framework for discussions. In reality we are talking about rather simple system. Supply is the Registry/Registrar, and they have the building blocks. Going through the use cases is to understand each of the building blocks. 

b) Confirm proposed categorization

• No objection 

c) Confirm new ranking survey & deadline to determine most representative use case in each category

• Staff to set up survey for the EPDP Team to rank and identify the most representative case in each group of the use case categorization. EPDP Team to complete the survey by COB Monday, 29 July. 

5. Use case – first reading: Investigation of criminal activity where domain names are used.  Typical specific example: phishing attack (60 minutes)

• Chair’s proposal: EPDP Team to identify the difficulty in the first reading of the case (SSAC Crime-Abuse Investigation Use Case), present them in writing and share on the mailing list. 
• Defer the discussion of the use case till 8 Aug due to Greg’s absence during next week’s meeting? Provide initial overview during today’s meeting with ability for EPDP Team to share initial observations during today’s and next week’s meeting, followed by in depth review during 8 August EPDP Team meeting.
• Review a set of tasks / purposes that occur in a number of cyber crime cases. Some are done by investigators in private realm. Some steps are done by law enforcement due to the same goal. Purpose here is to explain how things work practically and see what issues would surface. 
• Start with practical instances (i.e., recital 49) about the processing of data. Then compromised/malicious registrations. 
• Section A, law enforcement may also rely on these parties and techniques. 
• Section B, Tasks 1-2: reasons why the data are requested and used. Maliciously registered means somebody uses the domain name to commit a crime. If a domain name is maliciously registered, suspending the domain name is an option. If a domain name is compromised, you don’t want to suspend the domain. Reputational providers do not generally block domains. Some just list domain names and say don’t have anything to do with them. You need to determine what additional domains may be related. The issue is dealing with ongoing harm. You can determine what other domain names are on the same IP address, which may not be operated by the same bad actor. 
• Section B, Task 3: If the contact data is bogus, it is a sign of bad faith. Sometimes criminals do a poor job of faking the data. Accessing accuracy is important. Comment from EPDP Team members: Bogus data is not automatically a sign of bad faith. And your accuracy check has to be done by compliance. 
• Section B, Task 4: Need to document the case and preserve the reason why you made the decision of suspending the domain name and substantiate why the domain name is problematic.  Be responsible and give decision makers the information they need. 
• Section B, Task 5: law enforcement and private parties do this. Private parties may want to avoid associated assets. 
• Section B, Task 6: many aspects involve automation. Some block lists use algorism. The system that protects people involve a high degree of automation. 
• So how does 49 relate to domain names?  When domains are as the mechanism for the cybercrime attack, the “ability of a network to resist…” will largely be based on the ability to continue to allow traffic from said domain, or (as Greg is explaining) to block / reject any further traffic from or access to said domain.

• How can you describe things generally and then go to nitty gritty issues like automation. you need to be very specific in other fields as well. Don’t see a Use Case here. Need clear explanation on how all those recitals and all the clauses apply to these issues. 
• It is an issue with the law but not what ICANN/EPDP Team can fix. We still have to apply the law as best as possible, but EPDP Team cannot make any effort to change the law. 
• The EPDP Team needs to work on how to deal with the balance of the law. 
• The internet will die far faster if people are advocating breaking it because people did not involve themselves in the crafting of such law. For example the e-privacy regulations were stalled because an affected party advocated on how the law would have an unintended consequence. Again ICANN cannot fix the way it is, we can only figure out a way of making the "new" post GDPR world better .... including shaping future legislative endeavors - not by ICANN policy supporting a bending of that law.
• They should be reported to law enforcement. Not like Brian Krebs just putting out info of the attackers wife on a public blog. https://krebsonsecurity.com/2017/07/who-is-the-govrat-author-and-mirai-botmaster-bestbuy/
 security researchers need to do their research diligently without harming those who are not involved.

• Suggest that people do their research on how investigations by private actors are managed under DP law in the meantime, and talk about the case the following week. While cybercrime is a good example of rampant regulatory avoidance, it is not the only one.  However, it does not work well under data protection law (competition law also being relevant but not in our remit).

• The need is to stop the harmful activity, it is not to identify the guilty party. You don’t need redacted data to substantiate the domain. There will be a lot of information that won’t be redacted. Support efforts by private actors to sweep through the information to stop attacks, but we don’t need to open up the data. 
• The practical issue is that the vast majority of the cases do not involve law enforcement or are being reported. Law enforcement does not have the resources. A lot is done by relying on contract. 
• Phone number is relevant when its relevant. This use case doesn't cover those instances where passive DNS (for example) was sufficient. They do exist, but not relevant to this use case
. 
• ACTION ITEM: In the meeting on Thursday, 1 August, the EPDP Team to devote part of the meeting to discuss initial reaction from members on the SSAC Crime-Abuse Investigation Use Case. EPDP Team to provide input by writing no later than 14:00 UTC on Monday, 29 July. More detailed discussion about this use case will take place in the meeting on 8 August.  

6. Use case – final reading: Investigation of criminal activity against a victim in the jurisdiction of the investigating EU LEA requesting data from a non-local data controller (30 minutes)

• Chair’s Proposal: deal with this item before the first reading of item #5
• Starting from g) Safeguards (requirements) applicable to the Entity Disclosing the Nonpublic Registration Data 
• See responses from Chris Lewis-Evans to comments submitted by RrSG on this use case. Chris agrees with Registrar group’s suggestion re Section C, as it gives an increasing level of accuracy. Agree with the suggested change in Section D by the registry group. Section F, agree with the suggested change.
• Chris Lewis-Evans will also consider additional registrars’ comments/questions. Registrar reps indicated that they will need a couple of days to review the responses Chris provided and may respond further on the list once they have had a chance to do that. Don’t take silence as complete agreement.
• Re 6(1)F, the legal authority needs to be identified. EPDP Team is not expert to verify that. Ensure that LEA establishes the legal authority itself. 
• Section H: 

• Clarify the comments from registrars, add safeguards under automated system which may be different. 
• Need to have a discussion about how the automated system works. 
• Probably useful to drop a footnote in the template to provide the explanation Chris just gave so it’s clear on its face and avoids later confusion and uncertainty. 

• Section I, no further comments/requests. 
• Section J: 

• First time discussing accreditation. It is a chicken-egg situation, as it depends on the standardized system. Jurisdiction and legal basis would be necessary for an accreditation body to look at. 
• There are differences between accreditation and validation. Some suggested to first discuss validation first, as it has different forms which can or cannot be automated. Accreditation might then be fully automated. 
• “Validation” probably means “authentication” that is covered in Section K. We need to deal with accreditation first before authentication. There may be one exceptional case that one can be authenticated before accreditation, but it does not justify changing the default order.
• This depends on the implementation of the standard system. Even we don’t end up with having a centralized system, we can still do it. A decentralized system can still have value. The same standards can be centralized and also applied in decentralized way.
• The “code of conduct” may not be part of the accreditation. Disclosure / nondisclosure related issues belong more in the safeguard section. 
• EPDP Team can create a special accreditation entity that consists of one group or many groups. There are a number of options. But first need to see whether there is a broad agreement that accreditation as a principle should be introduced in the standard. 
• EPDP Team needs a set of definitions because people are using the terms in different ways, and for accreditation, there are two aspects. Accredditing of a group to be eligible to use a system (or make a manual request) and accrediting an individual requester to be part of that group.
 This is what we currently have in the chair’s working definitions document: “Accreditation – refers to the process or action of recognizing a person as having a particular identity, possibly with an associated affiliation or status.”
• See Chair’s working definitions here: https://community.icann.org/x/-5WjBg. Strongly suggest to flesh out the details when people are using different meanings for the same terms. 
• There is no accreditation body that the EPDP Team needs to define or create. The EPDP Team does not need to determine what the accreditation elements/criteria are. Specifically about the LEA, it is up to the law enforcement and the coalition of law enforcement bodies to do it. Part of this comment will represent part of the policy statement. As a policy matter, there should be accreditation, the accreditation should ensure certain aspects/points, etc. We can develop general policies on accreditation and it is in our work plan. 
• There would be some “approved” list of accredited based on some the set of criteria.
• Another consideration, albeit not an immediate problem, is about authoritarian government, human rights protection, cloud act, etc. We can accredit a law enforcement agency as a legitimate one, but if there is a national law that allows the agency to investigate or harass people that criticize the government, how do we want to handle that? Do we want to have additional human rights protection attached to the accreditation criteria? 
• A lot of those human rights concerns can be addressed by the terms of use, ensuring there is strong enforcement of the terms of use. 
• General policies to keep authoritarian countries away from disclosure and accreditation? Don’t think this group can do that. Also some of these countries are allegedly undertaking cyber attacks. Whatever this LEA accreditation body would be, civil society would definitely have to be involved in the definitions, but this is outside of our remit. 
• Somebody accredited does not mean he/she has a valid request. You have to review each request to ensure it is valid. There is a responsibility for the entity that releases the data to validate the request.  We all agree at this point that accreditation doesn't assume guaranteed access.  A valid form of accreditation is merely a factor in the 6(1)f balance - or in the case of jurisdiction - a confirmation that there is a legal obligation on that controller in that jurisdiction.
• Does every single contracted party need to act as its accreditation body? This may not be implementable. 
• The correct safeguards for both the accreditation and the authentication levels need to be developed. 
• If we are talking about a fully automated accreditation process, law enforcement organizations can be done easily, but not so easy to accredit other kinds of organizations. Need some human intervention. Also need a decision making process, which can be automated possibly. 
• Staff have grouped the input on accreditation together, aligning with the relevant charter questions (but no definition): 

• b) What are the unanswered policy questions that will guide implementation? 

• b1) How will credentials be granted and managed? 

• b2) Who is responsible for providing credentials? 

• b3) How will these credentials be integrated into registrars’/registries’ technical systems?


• Chair’s proposal: When accreditation is discussed next time, Staff to pull out their compilation of everything that has been submitted on accreditation and identification related processes to help inform EPDP Team’s further deliberation on this fundamental building block. 

• Section L: 

• Come back to “credentialing” in a more structured way when reviewing the next case. 
• We add a footnote to note it.


• Section M:  

• it is up to the LEA whether there is any urgency. In certain cases, a specific quick turn around may be necessary, but 2 days across the board may be too restrictive. 
• There is concept of acknowledging the requests, whether the data will be delivered. Some requests have higher priority and some requests demand different levels of confidentiality. Need to accommodate these concepts. 
• If you have a lot of requests, you have to staff up too.
• Maybe Section M and Section O should be different. The level of requests is just for the LEA’s consideration, and that level is generally lower than other kinds of requests. Maybe 4 business days would be more than reasonable? Some exceptions can be made and listened to. 
• We cannot apply go daddy standards to all Registrars. It is a long tail data set, and many registrars may have one request/day, aligning with their size of business. There is a natural balancing. Also need to factor in that not all registrars will receive the same volume of requests - this may be aligned with the # of domain names under management. 

• Section N:

• Is it possible to have an automated decision? How determinations are made when there is disagreement? We can automate processes, but not all processes can be automated. Need to evaluate all the information received before moving forward. 
• If an LEA makes a request for 10,000 records all based on the same legal basis and investigation, could the request be manually reviewed but once approved the delivery of the data automatic? 
• There may be instances that some data fields can be released safely for bona fide parties. Automated does not mean all the way to finish, it can be 80% of the process. This is important to know by the practitioner. 
• All the details regarding use cases are relevant to what can be automated or not. Focus on the use cases first and then circle back to this question. Automation is one of the charter questions and building blocks. 

• Section N: 

• Suggest removing the word “possible” and leaving “desirable”. A “possible" question should remain in the template, though we may want to separate it from "desirable"
 Data retention would be subject to legal requirements in the jurisdiction of the LEA would it not? Might be better to ask whether automation is consistent with legal requirements/legal basis
.

• Section P: not so clear, suggest the same language used in the previous section for retention. There is no blanket answer. 
• ACTION ITEM: Staff to compile the input submitted on automation/accreditation to assist the EPDP Team in its substantive discussions during next week’s call and future calls. Leadership team to develop initial thoughts paper on accreditation to kick start discussions.
• ACTION ITEM: Chris Lewis-Evans to incorporate input received from the EPDP Team and continue fine tuning the use case (GAC LEA1-13719-1), which is expected to be attached in the annex to the Initial Report. Updated version to be posted on the Wiki and the leadership to make a further recommendation for how to finalize the use case.

7. Any other business (5 minutes)

a) Priority 2 small team meetings update

(1) Accuracy and WHOIS ARS (see https://docs.google.com/document/d/1pS9Pibanj-Hp6LztZpeERtxdoLsnp4y_-do0vU5VJuw/edit[docs.google.com])

(2) Input received on other priority 2 items from RrSG (seehttps://mm.icann.org/pipermail/gnso-epdp-team/2019-June/002174.html)

(3) Leadership to recommend next steps via mailing list

b) Council request for input on org letter requesting clarification on Data Accuracy and Phase-2 (see https://gnso.icann.org/sites/default/files/file/field-file-attach/marby-to-drazek-21jun19-en.pdf[gnso.icann.org]). EPDP Team to provide input on the mailing list. Confirm deadline for input.   

• The EPDP Team did not address these agenda items 

8. Wrap and confirm next EPDP Team meeting on Thursday 1 August 2019 at 14.00 UTC (5 minutes)

a) Confirm action items

b) Confirm questions for ICANN Org, if any

_______________________________________________
Gnso-epdp-team mailing list
Gnso-epdp-team@icann.org
https://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

--
Volker A. Greimann
General Counsel and Policy Manager
KEY-SYSTEMS GMBH

T: +49 6894 9396901
M: +49 6894 9396851
F: +49 6894 9396851
W: www.key-systems.net

Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835
CEO: Alexander Siffrin

Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.