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

Wed Jul 20 17:49:12 UTC 2016

Comments inline

From: gnso-rds-pdp-wg-bounces at icann.org [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Stephanie Perrin
Sent: Wednesday, July 20, 2016 9:42 AM
To: gnso-rds-pdp-wg at icann.org
Subject: Re: [gnso-rds-pdp-wg] An important technical consideration about nature of the service (was Re: The overflowing list )

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.

[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.

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?

[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?

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.

[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.

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.

[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?

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/1730d8fc/attachment.html>