Subject: [regext] on RDAP milestones

From: "Wilhelm, Richard" <[email-masked]>
Date: Fri, 26 Jul 2019 12:48:49 +0000

Capturing/elaborating on my comments at the mic the WG meeting in Montreal…
 
Related to these three drafts:
	https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-response/
	https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/
	https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/
 
I offer that the number of RDAP server implementations is about to go (perhaps ‘undergoing’) a significant increase due to the Aug 26 deadline for ICANN gTLD registries and registrars to launch their own RDAP servers (see https://www.icann.org/rdap ).  Consequently, the RDAP community is in the process of both rapidly expanding and gaining valuable implementation experience with ‘basic’ RDAP implementation capabilities.
 
As it relates to the partial-response and sorting-and-paging drafts, I think that the emerging implementation work will be providing an opportunity for both the drafts to be exposed to experience gained on both the client and server.
 
As it relates to the reverse-search draft, the privacy considerations related to this are subtle/complex within the context of recent/current IETF discussions and are also related to legal/policy considerations outside the IETF sphere.  The outcome of forthcoming IETF discussions and incorporation of relevant legal/policy discussions will (presumably) need to be taken into consideration by this I-D.
 
I recognize and agree that ICANN gTLD policy work need not be a key dependency for REGEXT work.  But in this case, ICANN gTLD policy work is not the only policy question that is being considered.  There are also national legislation/regulations that are emerging in this area and the EU GDPR is in effect for just over a year (i.e GDPR is still relatively new).  Consequently, these EU/national policy considerations could have relevant impact.
 
Thus, for all three of these I-Ds, I would suggest that the milestone dates be extended in order to allow for more experience (partial-response and sorting-and-paging), more discussion (reverse-search), and for the relevant policy work to be completed/incorporated (reverse-search).  I think that the extensions will allow for the documents to evolve/mature based on these items, thus leading to more stable and long-lived documents.

Thanks,
Rick

---

From: George Michaelson <[email-masked]>
Date: Fri, 26 Jul 2019 09:26:11 -0400

I believe a proper response to Stephane and Peters stated concerns in
privacy, is for a "Privacy in RDAP" document to be written which
becomes a reference back into the patterns like reverse search. I do
not believe we can expect to go forward without reverse-index lookup:
it is a fundamental tool in LEA, but is (in that context)
circumscribed by GDPR, probably to be authenticated user only: It
depends on OpenID or Oauth or some other wide ranging model of access
control we can agree to (given that registries do 302 redirect, you
would expect a client to need to present a federated auth token) Or,
when invoked, it has limits. Or some combination. The issues are not
something which should just be an addendum or appendix in another
document. They should be addressed first-class. Unlike EPP, this is
about privacy of data in public view, not about the maintenance of
records inside registry, its about the access to that data from the
public globally-connected space.

I fundamentally believe that there is a huge role for "what are
related records from this person" queries. I do this from personal
experience, dealing with a hacked WHOIS account and seeking to find
the related resource records which showed signs of having been
tampered with from the maintainers rights. I am sure there are other
use cases.

I also think we need to distinguish between individual,
organisational, and corporate-entity rights here. I am happy to see
individual rights to privacy defended. I am concerned we are walking
into a world where we routinely extend personal rights to corporate
rights and I do not take it as axiomatic the GDPR rules mean that
registered and incorporated entities have some assumed right to
privacy.

If we do that, If we separate things out, we can progress
partial-response and sorting/paging in one strand, and reverse-index
query in another, with the latter the only one affected by new work on
privacy in narrow sense. In wide, all work in RDAP has to consider the
privacy issue.

I would invite Stephane (and Peter) to write. They have the most
direct statements of concern, I think they are able to document the
concerns.

-G

---

From: Roger D Carney <[email-masked]>
Date: Mon, 29 Jul 2019 14:16:26 +0000

+1 to extensions of these milestones

-----Original Message-----
From: regext <[email-masked]> On Behalf Of Wilhelm, Richard
Sent: Friday, July 26, 2019 7:49 AM
To: [email-masked]
Subject: [regext] on RDAP milestones

Notice: This email is from an external sender.

Thanks,
Rick

_______________________________________________
regext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/regext

---

From: Roger D Carney <[email-masked]>
Date: Mon, 29 Jul 2019 14:27:42 +0000

Good Morning,

Thanks George, I like this thought process. One additional thing I would like to add is the discussions of privacy at a higher level. For those that did not attend the Plenary Wednesday, there were some good privacy presentations and shows that privacy is an issue that needs to addressed across many protocol/standards development. Maybe George's suggested "Privacy in RDAP" is a good first step to take and might even be helpful outside the RDAP concept.

Does anyone know of current work at IETF specifically addressing privacy that could be leveraged by REGEXT? Additionally, is there a larger privacy effort going on within the IETF that the suggested "Privacy in RDAP" should be aware of and possibly get direction from?

Thanks

Roger

-----Original Message-----
From: regext <[email-masked]> On Behalf Of George Michaelson
Sent: Friday, July 26, 2019 8:26 AM
To: [email-masked]
Subject: Re: [regext] on RDAP milestones

I believe a proper response to Stephane and Peters stated concerns in privacy, is for a "Privacy in RDAP" document to be written which becomes a reference back into the patterns like reverse search. I do not believe we can expect to go forward without reverse-index lookup:

it is a fundamental tool in LEA, but is (in that context) circumscribed by GDPR, probably to be authenticated user only: It depends on OpenID or Oauth or some other wide ranging model of access control we can agree to (given that registries do 302 redirect, you would expect a client to need to present a federated auth token) Or, when invoked, it has limits. Or some combination. The issues are not something which should just be an addendum or appendix in another document. They should be addressed first-class. Unlike EPP, this is about privacy of data in public view, not about the maintenance of records inside registry, its about the access to that data from the public globally-connected space.

I fundamentally believe that there is a huge role for "what are related records from this person" queries. I do this from personal experience, dealing with a hacked WHOIS account and seeking to find the related resource records which showed signs of having been tampered with from the maintainers rights. I am sure there are other use cases.

I also think we need to distinguish between individual, organisational, and corporate-entity rights here. I am happy to see individual rights to privacy defended. I am concerned we are walking into a world where we routinely extend personal rights to corporate rights and I do not take it as axiomatic the GDPR rules mean that registered and incorporated entities have some assumed right to privacy.

If we do that, If we separate things out, we can progress partial-response and sorting/paging in one strand, and reverse-index query in another, with the latter the only one affected by new work on privacy in narrow sense. In wide, all work in RDAP has to consider the privacy issue.

I would invite Stephane (and Peter) to write. They have the most direct statements of concern, I think they are able to document the concerns.

-G

regext mailing list

[email-masked]<mailto:[email-masked]>

---

From: Mario Loffredo <[email-masked]>
Date: Tue, 30 Jul 2019 13:57:19 +0200

Hi all,

I agree with Rick about the opportunity to extend the milestones of all 
the three drafts in order to collect further technical feedbacks and, 
consequently, have most comprehensive documents at the end of the 
standardization process. Soon I will publish new versions considering 
the feedbacks from Tom Harrison and others updates from me. Tom has done 
a basic not yet publicly available implementation that will be hopefully 
added to the "Implementation Status" section in the next future. Anyway, 
I don't think that the number of implementations reported in that 
section could be considered a good measure for estimate the 
exhaustiveness of a proposal because otherwise some recent documents 
would have not been exhaustive enough. Surely, the general feeling 
within the WG is a better estimator.

With regards to the possibility to expand the "Privacy Considerations" 
section of the reverse-search draft, I have no objections but, at the 
same time, I'm sure that the technical solution described in the draft 
will remain compliant with one of the basic GDPR concepts (Art.1) 
stating that personal data can be processed when supported by an 
appropriate lawful basis. I believe that any possible privacy violation 
is due to a data processing uncompliant with that statement and it is 
common to all the applications/protocols dealing with personal data. We 
have recently discussed about a possible EPP registry lock mechanism in 
the light of the recent attacks to registration interfaces and the 
conclusion was to think about new measures enforcing security. Despite 
the (more or less assessed) risk of a possible privacy violation, we 
didn't conclude to drop EPP!! And what about the privacy risks inherent 
to other EPP/RDAP operations which involve the delivery of contact 
sensitive information??

As it is clearly outlined in the "Privacy Considerations" section of the 
reverse-search draft, allowing only authorized users to access and 
process personal data is the key constraint for reverse-search 
availability. For the sake of clarifying the meaning of "legitimated 
user" concept, the section also includes three examples of potential 
users which are legitimated to execute a reverse search by three of the 
six GDPR lawful basis:

1) Registrars can execute a reverse search only on their own contacts by 
the "contract" basis

2) Offical authorities can execute a reverse search by the "public task" 
basis

3) Reverse search on information undisclosed by the owner can be 
executed by the "consent" basis

Honestly, unless the WG requires to add more samples, I don't see how 
this section could be furtherly expanded without saying something which 
is already covered by its incipit.

I would like to outline as well that some of the examples above 
correspond to as many examples of current reverse WHOIS services. There 
are examples available on the web taking into account public contact 
information and some registries already provide their registrars with a 
reverse lookup on their own contacts. As far as I know, no privacy 
objections have been raised to those services so far and I would be 
surprised to know that a data provider is so fool to make sensitive 
information available to everyone indiscriminately when this causes the 
infringement of some law.

Finally, RDAP has been designed to provide different users with 
different profiles which means not only to let servers to return 
different views of the same response but also to diversify the query 
capabilities. Reverse search is a scenario of applicability of a 
profile-based capability supported by the security measures as described 
in RFC7481. An RDAP provider can implement additional security services 
by leveraging other measures, for example IP whitelisting, but this is 
something related to security not to privacy.

In conclusion, I agree to extend for a limited time period the 
milestones of the three RDAP documents just because of going more deeply 
into the technical aspects.

I apologise for the long mail.
Regards,

mario

-- 
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: [email-masked]
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo