<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:"\@MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
{font-family:"Lucida Grande";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">Comments inline<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><o:p> </o:p></span></a></p>
<span style="mso-bookmark:_MailEndCompose"></span>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"> gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org]
<b>On Behalf Of </b>Stephanie Perrin<br>
<b>Sent:</b> Wednesday, July 20, 2016 9:42 AM<br>
<b>To:</b> gnso-rds-pdp-wg@icann.org<br>
<b>Subject:</b> Re: [gnso-rds-pdp-wg] An important technical consideration about nature of the service (was Re: The overflowing list )<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p><span style="font-size:13.5pt;font-family:"Lucida Grande",serif">I realize that this discussion is premature but it is very important. Despite our reliance in this group on the work of the EWG, it is important to note a few things that we addressed in a
very insufficient manner in that report, and in my view they are deal-breakers:</span><o:p></o:p></p>
<p><span style="font-size:13.5pt;font-family:"Lucida Grande",serif">1) How to authenticate law enforcement, private cybersecurity actors, and lawyers/paralegals when they are requesting access to greater levels of detail. Court orders cover only certain cases,
most are not covered. Who are they, what do they get, why do they get it, and how do you audit what they actually did? THese are to my non technical mind, separate authentication issues. The actors need to be authenticated, the request needs to be signed
and authenticated as coming from an appropriate authority, the scope needs to be established and signed, the trail needs to be auditable (and thus authenticated). Guys like Brad Malin who have done interesting work on anonymization of hospital records have
tackled these problems, but I cannot imagine how we apply it to this honking big global system.<o:p></o:p></span></p>
<p><b><i><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">[Mark Svancarek] As Volker mentions, the technical aspects of authorization (differential or otherwise) are pretty straightforward and well understood. It’s nice that
he’s investigating right now but this isn’t an area I am particularly worried about implementing if and when the time comes. Likewise, I’m not worried about implementing the audit capabilities either. IMO the tough parts will be (1) agreeing on the policies
which define what data can be seen by which actors under which circumstances and (b) ensuring that actors are assigned the correct levels of access defined in (1) in the first place. So I request we focus on the policy aspects now and the technical details
later.</span></i></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><o:p></o:p></span></p>
<p><span style="font-size:13.5pt;font-family:"Lucida Grande",serif">2) Nation states do not sign MLATS with all countries. Why would ICANN engineer a system that overrides national sovereignty and permits actors in untrusted jurisdictions to request data
they could not get through another country's justice department?</span><o:p></o:p></p>
<p><b><i><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">[Mark Svancarek] I don’t recall anyone actually advocating for this, and I am not aware of any proposals which imply such a situation, either. Can you clarify?<o:p></o:p></span></i></b></p>
<p><span style="font-size:13.5pt;font-family:"Lucida Grande",serif">3) Limiting the scope of data search. Given the nature of cybercrime and intellectual property abuse/crime, is it not the case that requests will be very expansive in scope? If I understand
Scott's intervention, he is working on a standard that will actually limit data elements to those relevant. The problem is, how does one determine what is relevant? As mentioned in this thread, some things lend themselves to technical intervention better
than others. I have spoken to a former federal court judge in our own jurisdiction who admitted it was impossible to tell from the applications for Court orders what was actually being requested, and one of our Federal Court judges was actually recently taking
our Solicitor General to court for not telling the truth in its applications. Bottom line, it is hard to limit scope in human space, let alone on a system. Furthermore, the examples I mention here are from Canada, where despite the protests of those of us
in civil society, the degree of abuse of surveillance is somewhat limited. We have to build a system that is resilient in all possible cases where abuse might be expected (Please do not tell me I am catastrophizing here, we are talking about fundamental human
rights and due process, it is important to be cautious.) I would love it if we could figure out how to do this automatically as a request comes in, and there is work on AI in the legal sphere that might be useful....but it is years away from actually working
according to the most recent </span><span style="font-size:13.5pt;font-family:"Lucida Grande",serif;color:windowtext"><o:p></o:p></span></p>
<p><span style="font-size:13.5pt;font-family:"Lucida Grande",serif">material on robotics that I have seen.</span><o:p></o:p></p>
<p><b><i><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">[Mark Svancarek] I have some ideas how we can implement the authorization specific to each level of access (as do Volker and others, of course), which can be defined as
granularly as desired based on the policy decisions we make. As Stephanie notes, we should be very clear what is viewable based on each granular level of access so that a judge can make an informed decision based on which data should be turned as a result
of a court order.<o:p></o:p></span></i></b></p>
<p><span style="font-size:13.5pt;font-family:"Lucida Grande",serif">4) Jurisdiction. There are important recent cases on jurisdiction, some of which found their way on to our massive document list. The EWG gave only a cursory glance at jurisdiction, in my
view, and it is a very hard problem. We discussed location of the RDS in basic terms (eg. does the jurisdiction have privacy law). Human rights are safeguarded in our respective constitutions, criminal procedure, and Charters of rights. Moving data outside
of the individual's jurisdiction usually guts those rights. Data localization is not the answer, assuring a universal high standard of protection of basic rights is the answer. hard to do.</span><o:p></o:p></p>
<p><b><i><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">[Mark Svancarek] As we mention in the draft problem statement, we will be going forward in a pragmatic and practical way while acknowledging that this is in some ways
new territory, legally speaking. However, please note that [PR-D30-R05] & [UP-D30-R06] already attempt to capture this requirement. We don’t need to debate the importance of the issue if it’s already captured in the proposed requirements (and if it’s not,
the process should be to add it, rather than discuss in email)… does that make sense?<o:p></o:p></span></i></b></p>
<p><span style="font-size:13.5pt;font-family:"Lucida Grande",serif">Stephanie Perrin</span><o:p></o:p></p>
<div>
<p class="MsoNormal">On 2016-07-20 6:08, Andrew Sullivan wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>On Wed, Jul 20, 2016 at 11:24:37AM +0200, Volker Greimann wrote:<o:p></o:p></pre>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>my concern with re-using the mechaisms offered by http(s) is that to my<o:p></o:p></pre>
<pre>knowledge it does not support differentiated or tiered access.<o:p></o:p></pre>
</blockquote>
<pre><o:p> </o:p></pre>
<pre>I'm not sure this attends to how the layers work in this protocol.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Https in the case of RDAP is just the protocol by which you carry the<o:p></o:p></pre>
<pre>bits. RDAP is an application protocol. So https provides the<o:p></o:p></pre>
<pre>TLS-based authentication mechanism of the accessing application. Once<o:p></o:p></pre>
<pre>you have the TLS credential, your RDAP server is in a position to<o:p></o:p></pre>
<pre>examine the presented credentials and make a decision about what data<o:p></o:p></pre>
<pre>to return. This is part of the RDAP server application. But RDAP has<o:p></o:p></pre>
<pre>the capability to do that _built in_ by virtue of having access to<o:p></o:p></pre>
<pre>authentication credentials that are not available as part of the whois<o:p></o:p></pre>
<pre>protocol.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>Say I am a Turkish "law enforcement official" (whatever that means in these<o:p></o:p></pre>
<pre>days) and have access to certain data fields because we decided that this is<o:p></o:p></pre>
<pre>the level of access given to law enforcement. I can now access this level of<o:p></o:p></pre>
<pre>information for anything. So we need not only authentication, but also<o:p></o:p></pre>
<pre>protection from abuse of such authenticated users. We need granulatity to<o:p></o:p></pre>
<pre>be able to not only to say that user A has access to information level B,<o:p></o:p></pre>
<pre>but also ensure that this information can only be requested for purpose C<o:p></o:p></pre>
<pre>and prevent any access to the same information for abusive use D.<o:p></o:p></pre>
</blockquote>
<pre><o:p> </o:p></pre>
<pre>I think this conflates policies that are amenable to technical<o:p></o:p></pre>
<pre>imposition, and policies that are not.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>For a given authenticated user, that authenticated user has access to<o:p></o:p></pre>
<pre>certain data. The data fields in question are available to the user,<o:p></o:p></pre>
<pre>and other data fields are not. That's something that can be imposed<o:p></o:p></pre>
<pre>technically: for any login that meets the same profile, the<o:p></o:p></pre>
<pre>restrictions in question yield the same access controls.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>There is literally nothing technically possible to do about someone<o:p></o:p></pre>
<pre>using data they obtain this way for purposes for which the data were<o:p></o:p></pre>
<pre>not intended. It may be that ICANN ought to have additional policies<o:p></o:p></pre>
<pre>about what happens if someone uses data outside the scope that the<o:p></o:p></pre>
<pre>data was supposed to be used -- the classic example is people using<o:p></o:p></pre>
<pre>privileged information access to dig up info on former romantic<o:p></o:p></pre>
<pre>partners. Normally, the way we solve that is that we fire people who<o:p></o:p></pre>
<pre>abuse their credentials when we catch them. So, ICANN could have a<o:p></o:p></pre>
<pre>policy about suspending credentials, similarly.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>If for example law enforcement has the ability to access certain information<o:p></o:p></pre>
<pre>based on a court order, we would have to ensure that this access level can<o:p></o:p></pre>
<pre>only be used if such a court order is present, otherwise how to shoield<o:p></o:p></pre>
<pre>users from abuse of the access we grant by policy?<o:p></o:p></pre>
</blockquote>
<pre><o:p> </o:p></pre>
<pre>It _might_ be possible to do something technical about one off cases<o:p></o:p></pre>
<pre>like this. For instance, it might be possible to create special-use<o:p></o:p></pre>
<pre>permissions for data related to a specific kind of request -- say, for<o:p></o:p></pre>
<pre>instance, some mechanism that allows communication of the terms of a<o:p></o:p></pre>
<pre>subpoena so that the request can get access to data related to that<o:p></o:p></pre>
<pre>subpoena, but can't re-use the credential for access to data that are<o:p></o:p></pre>
<pre>unrelated to the case in question. This sort of thing would probably<o:p></o:p></pre>
<pre>require some development of the federated authentication systems we've<o:p></o:p></pre>
<pre>talked about, and might be too complicated to be bothered<o:p></o:p></pre>
<pre>implementing. But it is not technically impossible, just expensive.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>I hope we will get to ask these questions further down the road and find a<o:p></o:p></pre>
<pre>workable solution to them. In the meantime, I just wanted to note that<o:p></o:p></pre>
<pre>authentication is not the solution, but only a step on the way towards the<o:p></o:p></pre>
<pre>solution. The solution must be broader.<o:p></o:p></pre>
</blockquote>
<pre><o:p> </o:p></pre>
<pre>Obviously, authentication isn't magic: you need to decide what to do<o:p></o:p></pre>
<pre>on the basis of the credential that's presented. But the general<o:p></o:p></pre>
<pre>point is that, in the presence of authentication, you have a whole<o:p></o:p></pre>
<pre>bunch of policy options that were simply not available with whois,<o:p></o:p></pre>
<pre>because whois is too primitive a protocol.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Best regards,<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>A<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>