<html><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";}
/* 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">Thanks, Benedict, and please pass on my thanks to Joe St Sauver.</p><p class="MsoNormal"> </p><p class="MsoNormal">This is probably the best summary:</p><p class="MsoNormal">> [it seems like much is pending policy development/policy decisions,<br> rather than technical considerations]</p><p class="MsoNormal"> </p><p class="MsoNormal">We knew this, of course!</p><p class="MsoNormal"> </p><p class="MsoNormal">-Ram</p><p class="MsoNormal"> </p><p class="MsoNormal"> </p><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b>From:</b> Benedict Addis <<a href="mailto:bee@theale.co.uk">bee@theale.co.uk</a>> <br><b>Sent:</b> Thursday, May 16, 2019 7:23 AM<br><b>To:</b> Technical Study Group RD <<a href="mailto:tsg-access-rd@icann.org">tsg-access-rd@icann.org</a>><br><b>Cc:</b> SSAC-EPDP-WP <<a href="mailto:ssac-epdp-wp@icann.org">ssac-epdp-wp@icann.org</a>><br><b>Subject:</b> [TSG-Access-RD] Fwd: Technical Model for Access to Non-Public Registration Data</p></div></div><p class="MsoNormal"> </p><p class="MsoNormal">Feedback on the TSG report from Joe St Sauver of Farsight.</p><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">He’d like me to make clear that the opinions below are his own.</p></div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">Benedict.</p><div><p class="MsoNormal"><br><br></p><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><div><p class="MsoNormal">Begin forwarded message:</p></div><p class="MsoNormal"> </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></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></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></p></div></blockquote><p class="MsoNormal"><br><br></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</p></div></blockquote></div><p class="MsoNormal"> </p></div></div></body></html>