<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><font size="+1"><font face="Lucida Grande">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:</font></font></p>
<p><font size="+1"><font face="Lucida Grande">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.<br>
</font></font></p>
<p><font size="+1"><font face="Lucida Grande">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?</font></font></p>
<p><font size="+1"><font face="Lucida Grande">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 material on robotics that I have seen.</font></font></p>
<p><font size="+1"><font face="Lucida Grande">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.</font></font></p>
<p><font size="+1"><font face="Lucida Grande">Stephanie Perrin<br>
</font></font></p>
<div class="moz-cite-prefix">On 2016-07-20 6:08, Andrew Sullivan
wrote:<br>
</div>
<blockquote cite="mid:20160720100850.GA48306@mx2.yitter.info"
type="cite">
<pre wrap="">On Wed, Jul 20, 2016 at 11:24:37AM +0200, Volker Greimann wrote:
</pre>
<blockquote type="cite">
<pre wrap="">my concern with re-using the mechaisms offered by http(s) is that to my
knowledge it does not support differentiated or tiered access.
</pre>
</blockquote>
<pre wrap="">
I'm not sure this attends to how the layers work in this protocol.
Https in the case of RDAP is just the protocol by which you carry the
bits. RDAP is an application protocol. So https provides the
TLS-based authentication mechanism of the accessing application. Once
you have the TLS credential, your RDAP server is in a position to
examine the presented credentials and make a decision about what data
to return. This is part of the RDAP server application. But RDAP has
the capability to do that _built in_ by virtue of having access to
authentication credentials that are not available as part of the whois
protocol.
</pre>
<blockquote type="cite">
<pre wrap="">Say I am a Turkish "law enforcement official" (whatever that means in these
days) and have access to certain data fields because we decided that this is
the level of access given to law enforcement. I can now access this level of
information for anything. So we need not only authentication, but also
protection from abuse of such authenticated users. We need granulatity to
be able to not only to say that user A has access to information level B,
but also ensure that this information can only be requested for purpose C
and prevent any access to the same information for abusive use D.
</pre>
</blockquote>
<pre wrap="">
I think this conflates policies that are amenable to technical
imposition, and policies that are not.
For a given authenticated user, that authenticated user has access to
certain data. The data fields in question are available to the user,
and other data fields are not. That's something that can be imposed
technically: for any login that meets the same profile, the
restrictions in question yield the same access controls.
There is literally nothing technically possible to do about someone
using data they obtain this way for purposes for which the data were
not intended. It may be that ICANN ought to have additional policies
about what happens if someone uses data outside the scope that the
data was supposed to be used -- the classic example is people using
privileged information access to dig up info on former romantic
partners. Normally, the way we solve that is that we fire people who
abuse their credentials when we catch them. So, ICANN could have a
policy about suspending credentials, similarly.
</pre>
<blockquote type="cite">
<pre wrap="">If for example law enforcement has the ability to access certain information
based on a court order, we would have to ensure that this access level can
only be used if such a court order is present, otherwise how to shoield
users from abuse of the access we grant by policy?
</pre>
</blockquote>
<pre wrap="">
It _might_ be possible to do something technical about one off cases
like this. For instance, it might be possible to create special-use
permissions for data related to a specific kind of request -- say, for
instance, some mechanism that allows communication of the terms of a
subpoena so that the request can get access to data related to that
subpoena, but can't re-use the credential for access to data that are
unrelated to the case in question. This sort of thing would probably
require some development of the federated authentication systems we've
talked about, and might be too complicated to be bothered
implementing. But it is not technically impossible, just expensive.
</pre>
<blockquote type="cite">
<pre wrap="">I hope we will get to ask these questions further down the road and find a
workable solution to them. In the meantime, I just wanted to note that
authentication is not the solution, but only a step on the way towards the
solution. The solution must be broader.
</pre>
</blockquote>
<pre wrap="">
Obviously, authentication isn't magic: you need to decide what to do
on the basis of the credential that's presented. But the general
point is that, in the presence of authentication, you have a whole
bunch of policy options that were simply not available with whois,
because whois is too primitive a protocol.
Best regards,
A
</pre>
</blockquote>
<br>
</body>
</html>