[gnso-rds-pdp-wg] An important technical consideration about nature of the service (was Re: The overflowing list )

[Stephanie Perrin]

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:

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.

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?

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.

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.

Stephanie Perrin

On 2016-07-20 6:08, Andrew Sullivan wrote:
> On Wed, Jul 20, 2016 at 11:24:37AM +0200, Volker Greimann wrote:
>> my concern with re-using the mechaisms offered by http(s) is that to my
>> knowledge it does not support differentiated or tiered access.
> 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.
>
>> 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.
> 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.
>
>> 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?
> 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.
>
>> 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.
> 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160720/0cb19602/attachment.html>