[TSG-Access-RD] Fwd: Technical Model for Access to Non-Public Registration Data

[Benedict Addis]

Feedback on the TSG report from Joe St Sauver of Farsight.

He’d like me to make clear that the opinions below are his own.

Benedict.

> Begin forwarded message:
> 
> From: Joe St Sauver
> Subject: Re: Technical Model for Access to Non-Public Registration Data
> Date: 4 May 2019 at 04:05:02 BST

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tsg-access-rd/attachments/20190516/fb553d98/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 528 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/tsg-access-rd/attachments/20190516/fb553d98/signature-0001.asc>