Hi Tim,
again my responses below.
Il 24/08/2023 10:02, Tim Chown ha scritto:
Hi,
On 22 Aug 2023, at 10:50, Mario Loffredo <mario.loffr...@iit.cnr.it>
wrote:
Hi Tim,
thanks a lot for your review.
Please find my comments inline
I’ll answer the privacy point in response to Andy’s email.
Il 21/08/2023 20:27, Tim Chown via Datatracker ha scritto:
Reviewer: Tim Chown
Review result: Not Ready
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.
I would assume one aspect of the concern is the larger volume of
queries that is likely to follow, and in particular efforts to recover
potential PII (whether it is actually available or not). So both a
general higher volume of queries, but also a level of additional
‘harvesting’ activity. I think that’s where some text could be added,
and covered by similar protections as described for existing queries.
[ML] The largest volume of queries will likely be towards the public
endpoints of the RDAP services. In general, the endpoints protected by
authorization mechanisms, as reverse searches are expected to be, are
not accessed frequently.
But if protected and public resources coexist in the same service, this
may result in increasing the risk of attacks to the protected resources
and decreasing the efficiency of the service for accredited users.
One solution is to dedicate a specific path segment to the authenticated
endpoints (e.g. https://example.com/rdap/auth/... instead of
https://example.com/rdap/...).
It permits:
- to easily implement the support for authentication/authorization
since, for example, most known OpenID implementations offers some kind
of software adapters protecting a given path (or all the paths starting
with a given prefix);
- to configure a proxy routing the requests to two different backend
servers, one serving the anonymous requests to public endpoints and one
serving the authenticated requests to the protected endpoints, and
eventually adding to the latter server some security services provided
by other protocol layers such as certificates and IP whitelisting.
Does the considerations above address your remark ?
Should I add them to the Implementation Considerations section ?
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.
The text further into the document helps, but the text I the Intro
ignores this; it should forward point to that.
[ML] Does it work for you if I add text in the Introduction section
stating that the implementation of a reverse search feature might
request additional effort in processing the queries and making them
sustainable for the server (see Implementation Considerations) and
improving the security level (see Security Considerations) ?
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.
OK, thanks.
This seems to boil down to a solution that is technically fine, from
my level of knowledge of RDAP, but where the use cases need to be
considered by the IESG in their evaluation.
[ML] The possible use cases are reported in the Introduction section.
Best,
Mario
Tim
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
--
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
