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