Hi Tim,
thanks a lot for your review.
Please find my comments inline.
Reviewer: Tim Chown Review result: Not Ready Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. The document describes Registration Data Access Protocol (RDAP) reverse search functionality that allows queries on entity information to return corresponding domain lists. The document is well-written, clear, and includes helpful examples. I consider that the document is close to being ready for publication, subject to the below caveats. General comments I am not an expert in RDAP, but the technical solution proposed in this document for a reverse search capability seems reasonable. My two concerns are not technical, rather related to the ‘objections’ mentioned at the start of the draft’s Introduction section on privacy and server processing. I note that the draft has been marked as ‘Ready’ after a security area review, so perhaps these concerns are not warranted, but I feel I should raise them and at least let the Ops AD look at them. One concern is privacy. Paragraph two of the Introduction appears to be waving away privacy concerns based on new registration directory services that are being considered, and thus may become reality at some point (this is not clear). I’d hope that the controls on such new services would be more clearly articulated, rather than the services being presented as being at an early ‘consideration’ stage. Are privacy protections guaranteed to be there? I understand the potential benefit of this new service compared to Whois, but I would like to see the text say more. The Privacy Considerations section also quite rightly talks about HTTPS being required for reverse search. But I’m curious as to why the reverse search functionality SHOULD only be accessible to authorised users for specific use cases, rather than MUST? And is that ‘should’ in paragraph two of the Privacy Considerations a SHOULD?
[ML] Firstly, would say at the outset that the authors and the WG have never thought of this feature as uncontrolled whereas it is based on the use of sensitive information.
But, if on one side there are the privacy concerns to consider,
on the other side there are some legitimate interests to pursue.
The reasonable compromise is to make the RDAP reverse search based on PII accessible only to authorized users who are supported by lawful basis.
For example, allowing the reverse search based on domain-entity relationship to registrars users but solely on their own domains and contacts.
Such a concept is summarized in the following sentence of Section 13:
In general, given the sensitivity of this functionality, it SHOULD be accessible to authorized users only, and for specific use cases only.
SHOULD has been used instead of MUST for two main reasons:
1) The document describes a generic reverse search query model.
Therefore, there might be reverse searches that are based on
public information.
2) Provided that I don't have a legal background but, either when PII is used, think we can't exclude implementations of this feature that are publicly accessible and are still compliant with laws or regulations that restrict the use of PII.
An example might be allowing a public reverse search based on
those contacts for which the RDAP provider have previously
obtained an out-of-band consent for publishing the sensitive
information and using it in a reverse search process.
With regard to the cases where "should" is used instead of
"SHOULD", they are in the introductory sentences of Section 11
that don't provide guidance about how to operationally make this
feature accessible only to some users.
Indeed, such a sentence states that it should be accessible through an authentication/authorization mechanism. The same goes for the requirement about using HTTPS.
Additional notes about how to enforce access control on reverse
search are presented in Appendix A.
Anyway, if you still think that it would be more appropriate to change 'should' into "SHOULD" in paragraph two of Section 11, I'll do it :-)
I wonder also here whether as per other RDAP specs I’ve looked at as part of this review there is the privacy of the querier to be considered, but I suppose if specific authorisation is required then that is an unrealistic expectation? The other concern is the way the server processing aspect is presented. It seems the text in paragraph 3 of the Introduction is saying it’s not an issue as RDAP search queries already exist. But looking at related RFCs I see examples where specific controls (rate limiting, response codes for too many queries, etc) are described. So I think the concern is clear, rather the text should state that controls can be implemented, or indeed SHOULD be, later in the document.
[ML] The concern is about RDAP searches in general, not specifically about the reverse searches.
In addition, the reverse search is not new in RDAP. RFC 9082 defines queries to search for domains starting for a detail of the associated name servers.
This document just aims to describe a formal query model
addressing every kind of reverse search based on the relationships
between the RDAP objects.
RFC 8977 and RFC 8982 already provide guidance to implementers on
how to make searches more sustainable for both clients and servers
but, obviously, RDAP providers can implement additional measures
with the same purpose.
That said, Section 10 already includes text recommending to use
techniques speeding up the data retrieval and mitigating the risks
of performance degradation.
Hence, IMO, it already addresses your remark.
Finally, related, I welcome the details of implementations in the draft, but I note they are ‘alpha’ state. I’m curious as to their potential progression, and what testing at any scale may have bene done.
[ML] At .it, we have implemented only the reverse search based on domain-entity relationship and it's unaccessible to public users.
Presently it's available to registrar users under the conditions explained in my first comment and we plan to make it available to authorities soon.
ARIN and APNIC have described in draft-ietf-regext-rdap-rir-search
a potential usage of the reverse search in their own RDAP servers.
Best,
Mario
Best wishes, Tim
-- Dott. Mario Loffredo Senior Technologist Technological Unit “Digital Innovation” Institute of Informatics and Telematics (IIT) National Research Council (CNR) via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Web: http://www.iit.cnr.it/mario.loffredo
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
