Hi Tim,
thanks a lot for your review.
Please find my comments inline.
Il 21/08/2023 20:27, Tim Chown via Datatracker ha scritto:
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
<https://datatracker.ietf.org/doc/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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext