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

[Diana Middleton]

Thank you Benedict.

Typically when we receive comments, we publish them here: https://www.icann.org/resources/pages/gdpr-comments-2018-04-04-en

Can you let us know if Joe wants his comments published or if they were for internal review only?

Best,
Diana

From: TSG-Access-RD <tsg-access-rd-bounces at icann.org> on behalf of Benedict Addis <bee at theale.co.uk>
Date: Thursday, May 16, 2019 at 07:23
To: Technical Study Group RD <tsg-access-rd at icann.org>
Cc: SSAC-EPDP-WP <ssac-epdp-wp at icann.org>
Subject: [TSG-Access-RD] Fwd: Technical Model for Access to Non-Public Registration Data

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/20190521/a76edd57/attachment-0001.html>