A), as written below, still implies that only government entities may receive authority to make urgent requests. It is possible that I am misinterpreting this. Please clarify – how would Microsoft Digital Crime Unit receive authorization to make urgent priority requests? Is this a special type of accreditation? B) and C) are already required in our draft policy, so there should be no controversy here. From: Volker Greimann <vgreimann@key-systems.net> Sent: Wednesday, April 29, 2020 8:18 AM To: Mark Svancarek (CELA) <marksv@microsoft.com> Cc: gnso-epdp-team@icann.org Subject: Re: [EXTERNAL] Re: [Gnso-epdp-team] Regarding Urgent Priority requests by non-LEA Hi, to expand upon my previous mail on the subject I would see the following basic requirements for any framework for urgent requests: a) Requestor is authorised to send urgent request b) Request is made in relation to subject matters where urgent requests are permitted c) Requestor demonstrates urgency is required in this case For a), we will need to define who should have the authority to even be allowed to enter the portal to urgent requests. If you are not a bearer of the special pass, thou shalt not enter these hallowed halls. Basic concepts required for this pass should be special authority, dependability and potentially others. Authority would flow from specific legal powers, such as law enforcement of appropriate jurisdictions. Others may be possible but should still have comparable authority that can be shown in evidence. Dependability would be measured as a track record of previously confirmed urgent requests, e.g. how dependable is the requestor in only using this fast lane for cases where it is actually required. b) Obviously, if you are an operator of a facility that has been granted access to make urgent requests to act quickly in case your site is attacked, you should not be using the queue to request data of someone violating your trade mark. So we will probably down the line have to define what matters can make use of this speed lane. This should probably be an open-ended refinement process as otherwise we will surely forget something or someone. For starters, the content of the draft Rec 9 should be sufficient, but will need some more defining. For example, critical infrastructure could be equated by what is defined by many national laws as critical national infrastructure but the problem here is that such laws do not exist in every country and may be wildly different in scope. Our approach should work across the board. c) Every request with urgency should be accompanied with a statement of why an urgent response is needed and how your request is related to your authority. Fail to make that case and to the back of the regular queue you go. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C6ecc53e535ea45d63e3208d7ec508f53%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637237703064237863&sdata=NeGnvEfCkMzEsL8Hq3jrwZJVNT22FvAvhWUEjiSpSYc%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Wed, Apr 29, 2020 at 4:21 PM Mark Svancarek (CELA) <marksv@microsoft.com<mailto:marksv@microsoft.com>> wrote: Everyone, we will be discussing this topic in plenary soon. Given the business of meetings, it will be good if we can discuss this topic in advance of the meeting. If you have any additional feedback which may be helpful before we meet, please add it here. Thx. /marksv From: Mark Svancarek (CELA) Sent: Thursday, April 23, 2020 6:59 AM To: Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: RE: [EXTERNAL] Re: [Gnso-epdp-team] Regarding Urgent Priority requests by non-LEA Thanks, Volker! My comments are inline below. /marksv From: Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Sent: Thursday, April 23, 2020 1:37 AM To: Mark Svancarek (CELA) <marksv@microsoft.com<mailto:marksv@microsoft.com>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [EXTERNAL] Re: [Gnso-epdp-team] Regarding Urgent Priority requests by non-LEA Thank you Mark, you explanation highlights one of the key issues of this debate: What is an urgent issue for one party may not be the same for another. [Mark Svancarek] Correct. That’s why more than one category of requestor should be allowed to use the system. This is also why a centralized decider would have been nice, to get some consistency. C’est la vie. Ultimately we will need an objective standard to measure urgency. The ones I believe we had already agreed to was life and death situations and imminent terrorist attacks. Another issue is trust in the reporter. [Mark Svancarek] Correction: The latest draft of Rec 9 says, “imminent threat to life, serious bodily injury, critical infrastructure (online and offline) or child exploitation.“ It doesn’t matter who the attacker is – that may not be know at the time – only what is being attacked. Note that “critical infrastructure” is likely a defined term in a jurisdiction. Again, this is something that is easier to attribute to law enforcement of appropriate jurisdiction than to other reporters from the private sector as the latter have no checks and balances and may be motivated by other influences. Handling a request with urgency reduces our ability to verify the accusations made in the request. Many of the issues you describe are not verifiable by contracted parties and need to be believed or taken at face value. So trust is an issue. [Mark Svancarek] Trust is an important aspect throughout SSAD. Reputation can serve as a vehicle for trust. An entity can develop a favorable reputation by being accredited or certified, by having a history of good requests, and by taking extra steps to become a trusted notifier. Favorable reputations shall be lost by having a history of policy-defined bad requests, by failing audits, or by making spurious escalations when denied. Over time these can be factored into the learning system and recommendations of the CG, as in many other systems. All in all, I am open to considering other matters for urgency, but these will have to be carefully considered and weighed against the risks. [Mark Svancarek] Thanks! We also need to consider that these requests will not end the threats you describe. Is it really that urgent to get the registration data for a domain when a private enterprise like a bank is under attack by a ransomware operation? Do the security folks not have more important things to deal with at such times, like stopping the attacks or the domains from resolving? Will knowing the data that the registrant provided at the time of registration really end the attack? It may help, but is it really that urgent to know? [Mark Svancarek] We may have multiple tools in our toolbox. When a domain name record is the tool we need for a specific job, we should be allowed to use it. If not, we would use our other tools. As you say, reputation is important. Finally, if you open the gates too much, the special queue may become useless. [Mark Svancarek] I would rephrase that as “if you open the gates too much, the special queue will be less effective and non-urgent requesters will be impacted". I suspect that no threshold of urgent requests will be deemed acceptable to certain CPs, another reason why I prefer a central decider. But over time we will develop a sense how much volume is to be expected. Until then we risk urgent requestors might negatively impacting non-urgent requestors. I don’t think that reality disqualifies the concept, it’s just one more thing to discuss in Rec 9 or wherever else the issue pops up. I do not subscribe to the opinion of the Texan Lt. Gov that there are more important things than living. Life is the most important to protect. Everything else comes later. [Mark Svancarek] Hopefully there is no confusion that attacks on life are more serious than attacks on banks. But there are definitions of critical infrastructure for a reason, and we should consider that, too. [Mark Svancarek] PS: In USA there are many states. Illinois has a history of electing governors whom they subsequently send to prison. Texas has a recent history of electing governors who say really stupid things. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C6ecc53e535ea45d63e3208d7ec508f53%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637237703064247855&sdata=MAyFYUcn3iRWsTocm3Xi247Uz2tFWRPAxL58nqA9hIY%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Thu, Apr 23, 2020 at 7:22 AM Mark Svancarek (CELA) via Gnso-epdp-team <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> wrote: Although we’ve always discussed urgent priority requests as being available to both LEA and non-LEA, we are regularly asked why non-LEA should be allowed to use this type of request. We’ve seen this again in the public comments, with new suggestions that a non-LEA requestor must route urgent requests through a government agency rather than making such a request themselves. To clarify why it’s not sufficient to limit these requests to law enforcement and government agents, I asked my Digital Crime Unit and state actor cyberdefense teams for details. Here’s what they said. * Law enforcement (LE) and Microsoft priorities do not always overlap such that what we consider an emergency, where this information could be necessary to protect our customers ( such as a threat to our infrastructure or our customer’s infrastructure), is the same as an emergency for LE. * The threshold for what is important to protect our customers is often different or lower than the threshold for a LE emergency as outlined below – but nonetheless just as important. * When a customer or partner is under attack, we would not necessarily engage LE. We would only notify/contact the customer directly since the impact is on their tenant. LE engagement is then at their discretion. * Here are some scenarios where we would likely make urgent data requests separate from LE engagement: * a large banking establishment or school district under ransomware attack * a nation state actor targeting multiple human rights organizations with persistent spear phishing attacks * a nation state actor using a malicious domain to compromise and steal information from members of the United Nations * a nation state actor purchasing large swaths of domains to target multiple organizations in the oil and gas industry, then using them in a large-scale intrusion campaign Remember that abuse of the Urgent Priority request mechanism is already defined as an activity which may lead to loss of accreditation, even for LEA. That safeguard would be certainly be invoked quickly if the privilege were abused by a non-LEA requester. I look forward to discussing this topic soon. /marksv _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C6ecc53e535ea45d63e3208d7ec508f53%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637237703064247855&sdata=f0lLV%2F4zoXY%2B5FXoU7HZH9rhJcDUMEIPirW6TLvCXRg%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C6ecc53e535ea45d63e3208d7ec508f53%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637237703064257851&sdata=QZYSynm%2BKHLzJcy4%2F7FKC2ERBUjP3K34HH5bGzOLzDE%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C6ecc53e535ea45d63e3208d7ec508f53%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637237703064257851&sdata=U90FxczOODksdwjHnIRAPWcjMnDMU49d9ruX5wcznNY%3D&reserved=0>). 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.