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

[Stephanie Perrin]

Comments inline.

Stephanie


On 2016-07-20 13:49, Mark Svancarek wrote:
>
> 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./*
>
/*SP:  As Lisa has clarified in her response to you, pointing to the EWG 
report, the technical end is not really the hard part, it is the 
criteria for accreditation, and the entity that has the authority to 
accredit, which is a problem as yet unsolved. */
>
> 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?/*
>
/*SP:  LEAs have repeatedly said that the MLAT system is broken, does 
not help with cybercrime, takes too long (6-8 months I have heard).  We 
have many LEA reps on this committee, perhaps they would be kind enough 
to come forward and say this so I don't have to dredge up voice 
recordings of panels that I have been on.  I can review the GAC 
Communiques and see if there was ever a straightforward statement that 
MLATS do not work in most cases, and why.  I doubt it because of the 
nature of GAC communiques in general, but will look.  However, the GAC 
requests for open access to data, while retaining confidentiality, 
support my rather blunt contention above.  Part of the reason MLATs dont 
work is that rogue actors operate in multiple jurisdictions, operate 
globally, and are likely to be resident in jurisdictions where there are 
no MLATs that would facilitate their prosecution.  Now, getting the data 
via other channels (ie through a potential new RDS with richer data, 
operated by ICANN, rather than by attempting to serve an order for 
production of information on a registrar in the said country) is not the 
equivalent of securing cooperation in investigating and prosecuting a 
suspect, but it is a way of reaching into other jurisdictions without 
complex legal agreements, is it not?  Let me be clear here, I realize 
that only the registrar will have the most useful data that is required 
to be retained under the RAA (billing info, credit card info, metadata 
concerning all domain registration transactions) at least under the 
models the EWG contemplated.  I would presume (hope) that some kind of 
court order would still be required to get that data, but of course 
jurisdictions vary significantly in the rigour that they apply here.  
Getting that court order is difficult without an MLAT, correct?
With respect to the request from law enforcement (good recent example 
being the Public Safety committee comments on the Privacy Proxy issue) 
that investigations and any requests for data related to those 
investigations be kept confidential, this is of course natural and to 
the extent permitted by law (DP law, criminal procedure, constitutional 
protections etc) must be respected.  This will make auditing more 
complex.  This in turn makes accreditation much more critical, if LEAS 
have to have disappearing or invisible access.
For a good discussion on how difficult managing secret access request is 
in practice, and how problematic for a justice system in democracies, 
see this recent article in the Harvard Law Review by a Texas judge 
http://harvardlpr.com/wp-content/uploads/2013/06/Gagged-Sealed-and-Delivered.pdf. 
I cite this even though it relates to ECPA proceedings, because he has a 
proposal for a simple disclosure process that could be useful to unseal 
the records in our situation without necessarily jeopardizing any 
ongoing investigations or future work.  Rod Rasmussen has pointed out 
how stupid and careless some of the bad actors are, but there is no 
reason to provide a road map for them, and the judge has come up with a 
form that merits investigation.  [note this does not solve the audit log 
problem]
*/
>
> *//*
>
> 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./*
>
/*The case I cite above indicates that at least one judge has 
reservations about the ability of the judicial system to evaluate the 
validity of ECPA requests, and the utter failure of the appellate and 
Supreme Courts to perform their usual role in the case of ECPA.  Is it 
the same in the case of data released by registrars?  I honestly dont 
know, do we have data on the number of warrants served on registrars, 
and the number of cases appealed?  How is this system working at the 
moment?  do we have documents we can refer to?  I could have missed some 
in our haystack. */
>
> *//*
>
> 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?/*
>
/*Makes sense, I have to look up your numbered items and will get back 
to you on this.  [I guess I will have to print up a few pocket cheat 
sheets to decipher our discussions:  doc list and code, requirements 
code, and groupings code so far......]
thanks for your thoughtful response and apologies to those who do not 
want to have this discussion at this time.  For those of us who find our 
current workplan crazy-making, discussion of substance is necessary to 
maintain a semblance of sanity.
*/
>
> *//*
>
> 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/b41e454b/attachment.html>