<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@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:"Helvetica Neue";
panose-1:2 0 5 3 0 0 0 2 0 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
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:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
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>
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Thank you Benedict. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Typically when we receive comments, we publish them here: <a href="https://www.icann.org/resources/pages/gdpr-comments-2018-04-04-en">
https://www.icann.org/resources/pages/gdpr-comments-2018-04-04-en</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Can you let us know if Joe wants his comments published or if they were for internal review only?
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best,<o:p></o:p></p>
<p class="MsoNormal">Diana<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">TSG-Access-RD <tsg-access-rd-bounces@icann.org> on behalf of Benedict Addis <bee@theale.co.uk><br>
<b>Date: </b>Thursday, May 16, 2019 at 07:23<br>
<b>To: </b>Technical Study Group RD <tsg-access-rd@icann.org><br>
<b>Cc: </b>SSAC-EPDP-WP <ssac-epdp-wp@icann.org><br>
<b>Subject: </b>[TSG-Access-RD] Fwd: Technical Model for Access to Non-Public Registration Data<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Feedback on the TSG report from Joe St Sauver of Farsight. <o:p>
</o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">He’d like me to make clear that the opinions below are his own.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Benedict.<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Begin forwarded message:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><b><span style="font-family:"Helvetica Neue"">From: </span></b><span style="font-family:"Helvetica Neue"">Joe St Sauver</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-family:"Helvetica Neue"">Subject: Re: Technical Model for Access to Non-Public Registration Data</span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-family:"Helvetica Neue"">Date: </span></b><span style="font-family:"Helvetica Neue"">4 May 2019 at 04:05:02 BST</span><o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><br>
Hi,<br>
<br>
Carlos wrote:<br>
> For those interested on how non-public registration data (aka WHOIS)<br>
> will be technically accessed in the future:<br>
><br>
> <a href="https://www.icann.org/news/blog/technical-study-group-publishes-tsg01-technical-model-for-access-to-non-public-registration-data">
https://www.icann.org/news/blog/technical-study-group-publishes-tsg01-technical-model-for-access-to-non-public-registration-data</a><br>
<br>
Thanks for passing this along. After a first reading, some quick highlights from the new document [my personal comments below are in square brackets]:<br>
<br>
<br>
-- Goal/purpose (See Executive Summary on page 6):<br>
<br>
"The TSG's work is not an effort to replace the ICANN community's<br>
policy development process. Rather, the work of the Group is<br>
intended to help ICANN org determine whether such a model would<br>
diminish the legal liability for gTLD Contracted Parties (CPs), who<br>
would provide access to non-public gTLD domain name registration<br>
data."<br>
<br>
[framing the question in terms of "risk minimization for contracted<br>
parties," rather than in terms of facilitating public access for the<br>
historical Whois users (such as the anti-cyber-crime community)<br>
predictably skews the mission and output of this working group]<br>
<br>
<br>
-- The Solution WILL Be RDAP based (also from the Executive Summary):<br>
<br>
"Building on the technology available via the Registration Data<br>
Access Protocol (RDAP) and its extensions, the TSG recommends a<br>
technical model for authenticating, authorizing, and providing<br>
access to non-public gTLD domain name registration data to third<br>
parties with legitimate interests based on existing technologies."<br>
<br>
[not surprising, by taking RDAP as a "given," this predetermines a<br>
number of other outcomes, as highlighted below; I'd also note<br>
that RDAP deployment is still very limited per<br>
<a href="https://data.iana.org/rdap/dns.json">https://data.iana.org/rdap/dns.json</a> ]<br>
<br>
<br>
-- Punting On Some Key Questions (Section 1 ("Background") on 7):<br>
<br>
"The TSG [Technical Study Group on Access to Non-Public Registration<br>
Data], by design, has not made decisions or recommendations on<br>
purely policy questions, e.g., which users get access, to which data<br>
fields and under what conditions should access be given, and what is<br>
a legitimate interest for requesting such data."<br>
<br>
[failing to consider these key issues ignores the extent to which<br>
these issues potentially drive a successful technical solution,<br>
e.g., imagine a scenario where some users get access to "full" data<br>
while others are only eligible for a subset of that data -- how<br>
those entitlements get communicated represents a key part of the<br>
technical design. Nonetheless, noted as "punt to policy"]<br>
<br>
<br>
-- Identity Management Choice (see Section 6.1 ("Functional<br>
Requirements Mapping and Analysis") on page 16):<br>
<br>
"The TSG considered two technologies as candidates for inclusion in<br>
its Technical Model proposal. The first candidate is authentication<br>
and authorization using OpenID Connect and OAuth 2.0. [...] The<br>
second candidate is mutual Transport Layer Security (TLS)<br>
authentication using a digital certificate issued to the end user<br>
by a Certification Authority (CA). [...] The TSG believes that<br>
OpenID Connect/OAuth authentication meets all of the identified<br>
functional requirements."<br>
<br>
[I'm very supportive of federated authentication, but I'd note that<br>
federated auth doesn't necessarily foreclose cert based solutions<br>
at the same time -- the "CILogon" model is a compelling example<br>
of how the two can be bridged, see <a href="https://www.cilogon.org/">https://www.cilogon.org/</a> ]<br>
<br>
<br>
-- Section 7 ("Out of Scope Requirements") on page 17:<br>
<br>
<br>
"The TSG identified several functional requirements that it decided<br>
were out of scope. These requirements are listed below, and the<br>
rationale for placing them out of scope is outlined.<br>
<br>
<br>
"7.1. Reverse Search<br>
<br>
"In the context of domain name registration data, “reverse search”<br>
refers to the ability to identify domains based on common attributes<br>
such as a nameserver IP address or registrant email address. This is<br>
in contrast to the traditional model of accessing registration data<br>
by means of a direct lookup of a resource by an already-known<br>
identifier (e.g., a domain name). A reverse search query may be sent<br>
to a specific CP’s RDAP server, but may also be sent to an RDAP<br>
gateway service, which “fans out” the same query to multiple CPs’<br>
RDAP servers, and aggregates the responses into a single result.<br>
<br>
While RDAP already supports limited search capabilities, and an<br>
Internet-Draft extending these capabilities exists, the TSG does not<br>
believe that consideration of a reverse search system - and<br>
especially a cross-TLD reverse search system - is within its remit.<br>
The technical feasibility of such a system (in which a single client<br>
query could result in thousands of search queries to CPs’ RDAP<br>
servers), and the policy developments required to allow such a<br>
system to exist, are too great for it to be considered at this point<br>
in time.<br>
<br>
Should reverse search become feasible (from a technical and/or<br>
policy perspective) in the future, the TSG believes that the<br>
solution proposed in this document provides a platform in which it<br>
could be implemented."<br>
<br>
[this dismissive treatment of an important capability is reflective<br>
of a significant disconnect between how the ICANN TSG views<br>
information about domains vs how LEOs and other cyber crime fighters<br>
use that information; the legitimacy of "needs" are being determined<br>
by the current state of RDAP; also note another "punt to policy"]<br>
<br>
<br>
"7.2. Pseudonymity of Registrants<br>
<br>
As an alternative to reverse search, some have proposed that CPs add<br>
pseudonymous, hash-based identifiers to RDDS records, which would<br>
allow third parties to correlate domains with common registrants,<br>
without disclosing the personal information from which the<br>
identifiers are derived.<br>
<br>
The TSG believes that this proposal is out of scope, since it<br>
proposes a change to the basic data elements collected and processed<br>
by CPs: such a proposal is best addressed in the policy domain<br>
first, with a technical implementation to follow afterwards.<br>
<br>
As with reverse search, the TSG believes that registrant<br>
pseudonymity could be supported by the Technical Model in the future.<br>
<br>
[the hash-based approach that was proposed does not require any<br>
"additional data elements to be collected", it merely proposes a<br>
transform on how those elements are processed and shared; "punt to<br>
policy" yet again]<br>
<br>
<br>
"7.3. Bulk Queries and Bulk Access<br>
<br>
The TSG defines “bulk queries” and “bulk access” as follows:<br>
<br>
● “Bulk queries” is defined as a single transaction, containing<br>
multiple discrete queries, which produces multiple responses.<br>
<br>
● “Bulk access” is defined as requestors gaining access to entire<br>
datasets in an encapsulated format such as a CSV, XML or<br>
relational database file.<br>
<br>
The TSG believes that neither feature is within scope since neither<br>
feature is currently possible within RDAP."<br>
<br>
[it is a shame that the current state of RDAP is again being used<br>
as the justification for dismissing valid requirements, rather than<br>
serving to highlight required protocol development work]<br>
<br>
<br>
-- Who's Going To Handle Identity Management and Authorization?<br>
(8. "Actor Models" on pages 18-20):<br>
<br>
"The TSG takes no position on which of these models is ideal for<br>
selection to be deployed but is merely presenting possible<br>
combinations of actors and responsibilities that meet the stated<br>
requirements."<br>
<br>
[nonetheless, if you read the four models, Model 2 is clearly the<br>
most favorably characterized "child" from this "family" of models.<br>
It reads:<br>
<br>
"Actor Model 2: ICANN Gateway Using Multiple Identity Providers<br>
with ICANN as Sole Authorizer<br>
<br>
"In this model, ICANN delegates identity management to third-party<br>
Identity Providers, including for example national or regional law<br>
enforcement bodies and civil legal organizations, where vetting and<br>
credentialing of requestors may be already in-use, and natural.<br>
By keeping ICANN as the sole Authorizer, this model lowers the<br>
number of interactions, at least in regards to the authorization<br>
steps. Similar to model one, it does not suffer from potential<br>
inconsistencies in implementing the authorization policy."]<br>
<br>
<br>
-- A Rather Dismissive Note I'm Surprised To See Included (Section 9,<br>
"Implementation Considerations", page 20)<br>
<br>
"Given the nature of a system of this type, there will be<br>
complexity. Therefore, burdensome complexity should be pushed, when<br>
possible, to the fewest and most capable actors.<br>
<br>
"The largest contingent of actors in this system will be the<br>
requestors, for example law enforcement agents. Any proposed<br>
solution should attempt to keep burdensome, complex and technical<br>
matters from impacting their primary duties."<br>
<br>
[This sure SOUNDS like, "Don't you worry 'bout all this complex<br>
technical stuff, we'll take care of those burdensome details for<br>
you non-techy LEOs" -- sheesh. Really?]<br>
<br>
<br>
-- And The Answer Is... (Section 10.1 "System Components" at page 21):<br>
<br>
"10.1 System Components<br>
<br>
"This document proposes two parallel systems for processing requests<br>
for non-public gTLD domain name registration data: a browser-based<br>
Web portal, which allows asynchronous, manual submission, review,<br>
authorization and (optionally) completion of requests for non-public<br>
registration data through an ICANN browser-based RDAP client, and an<br>
RDAP Gateway, which allows synchronous, automated machine-to-<br>
machine requests for non-public registration data. Either or both of<br>
these systems may be deployed, according to policy development<br>
outcomes."<br>
<br>
[sounds like another non-decision, punted to "policy" (again)]<br>
<br>
<br>
-- SLAs are "Critical" But... (Section 11.2 "Service Level Agreements"<br>
on page 26):<br>
<br>
"In order to ensure a reliable system, Service Level Agreements<br>
(SLAs) MUST be established for each of the parties that operate the<br>
elements of the system. These SLAs would define the service<br>
performance levels expected of each party and the penalties for<br>
failing to meet them. [...] The TSG believes that defining the<br>
service level performance requirements for each party and the manner<br>
in which they are established, audited, and enforced, as well as<br>
whether SLA performance should be reported publicly is outside the<br>
scope of its remit and should be determined at the policy level."<br>
<br>
[punted to policy (again)]<br>
<br>
<br>
-- Risks (Sections 11.4 (Risk to ICANN Org) and 11.5 (Risk to<br>
Contracted Parties) on page 27):<br>
<br>
<br>
"11.4 Risk to ICANN Org<br>
<br>
"The TSG notes that ICANN org will function as the coordinating<br>
party of the system in the gTLD space and, depending on the policy<br>
development outcome, may result in ICANN org shouldering the burden<br>
of vetting and credentialing requestors. This may expose ICANN org<br>
to significant operational and legal risks. It is recommended that<br>
ICANN org identify, assess, and where possible take steps to<br>
mitigate these risks."<br>
<br>
[wait, wasn't this study supposed to be all about risk assessment?]<br>
<br>
<br>
<br>
"11.5 Risks to Contracted Parties<br>
<br>
"The TSG was established to determine the feasibility of a system<br>
that would mitigate some or all of the legal risks to CPs from the<br>
disclosure of non-public registration data. The TSG cannot comment<br>
on the validity of this assumption, and expects that the CPs will<br>
come to their own determination based on their own legal advice."<br>
<br>
[wasn't this the precise charge to the group?]<br>
<br>
<br>
-- "More Work is Required" (Section 12.1 (Future Work) on page 30):<br>
<br>
"The TSG’s Technical Model (TSG01) should be considered a proposal.<br>
The Technical Model (TSG01) should be considered the start of some<br>
work, rather than the end and is not sufficient to be directly<br>
applicable for implementation. Future technical work is necessary to<br>
complete the technical and specification process. [continues]"<br>
<br>
[it seems like much is pending policy development/policy decisions,<br>
rather than technical considerations]<br>
<br>
I encourage all to read the entire document.<br>
<br>
Regards,<br>
<br>
Joe<o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>