<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">Comments inline.</font></font></p>
<p>Stephanie<br>
</p>
<br>
<div class="moz-cite-prefix">On 2016-07-20 13:49, Mark Svancarek
wrote:<br>
</div>
<blockquote
cite="mid:CO2PR03MB21352903B153A95716FAE20FD1080@CO2PR03MB2135.namprd03.prod.outlook.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<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]-->
<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 moz-do-not-send="true"
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">
<a class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg-bounces@icann.org">gnso-rds-pdp-wg-bounces@icann.org</a>
[<a class="moz-txt-link-freetext" href="mailto:gnso-rds-pdp-wg-bounces@icann.org">mailto:gnso-rds-pdp-wg-bounces@icann.org</a>]
<b>On Behalf Of </b>Stephanie Perrin<br>
<b>Sent:</b> Wednesday, July 20, 2016 9:42 AM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><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></p>
</div>
</blockquote>
<i><b>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.
</b></i><br>
<blockquote
cite="mid:CO2PR03MB21352903B153A95716FAE20FD1080@CO2PR03MB2135.namprd03.prod.outlook.com"
type="cite">
<div class="WordSection1">
<p><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?</span></i></b></p>
</div>
</blockquote>
<i><b>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? <br>
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. <br>
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
<a class="moz-txt-link-freetext" href="http://harvardlpr.com/wp-content/uploads/2013/06/Gagged-Sealed-and-Delivered.pdf">http://harvardlpr.com/wp-content/uploads/2013/06/Gagged-Sealed-and-Delivered.pdf</a>.
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]<br>
</b></i>
<blockquote
cite="mid:CO2PR03MB21352903B153A95716FAE20FD1080@CO2PR03MB2135.namprd03.prod.outlook.com"
type="cite">
<div class="WordSection1">
<p><b><i><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><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.</span></i></b></p>
</div>
</blockquote>
<i><b>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. </b></i><br>
<blockquote
cite="mid:CO2PR03MB21352903B153A95716FAE20FD1080@CO2PR03MB2135.namprd03.prod.outlook.com"
type="cite">
<div class="WordSection1">
<p><b><i><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><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?</span></i></b></p>
</div>
</blockquote>
<i><b>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......]<br>
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.<br>
</b></i>
<blockquote
cite="mid:CO2PR03MB21352903B153A95716FAE20FD1080@CO2PR03MB2135.namprd03.prod.outlook.com"
type="cite">
<div class="WordSection1">
<p><b><i><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><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>
</blockquote>
<br>
</body>
</html>