Re: [regext] Opsdir last call review of draft-ietf-regext-rdap-reverse-search-24

[Tim Chown]

Hi,

On 22 Aug 2023, at 10:50, Mario Loffredo  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.

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.


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.

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.

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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Last-Call] Opsdir last call review of draft-ietf-regext-rdap-reverse-search-24

[Tim Chown]

Hi Andy,

On 22 Aug 2023, at 16:41, Andrew Newton  wrote:

[You don't often get email from a...@hxr.us. Learn why this is important at 
https://aka.ms/LearnAboutSenderIdentification ]

On Tue, Aug 22, 2023 at 4:54 AM Mario Loffredo
 wrote:

[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.

The email addresses and full names are not necessarily PII. They can
be, but they can also be related to role accounts and organizations as
a whole.

I think the issue (to me) is that the SHOULD is blurring the two types of 
access into one.  If it’s PII, then I’d have hoped that there MUST be access 
control, but if there is no PII, it’s not such an issue.  But the SHOULD just 
says "In general, given the sensitivity of this functionality, it SHOULD be 
accessible to authorized users only, and for specific use cases only.”

Again, something for the IESG to consider.

Tim
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Roman Danyliw's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS and COMMENT)

[Mario Loffredo]

Hi Roman,

thanks a lot for your review.

Please find my comments inline.

Il 22/08/2023 21:20, Roman Danyliw via Datatracker ha scritto:

Roman Danyliw has entered the following ballot position for
draft-ietf-regext-rdap-reverse-search-24: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
for more information about how to handle DISCUSS and COMMENT positions.



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/



--
DISCUSS:
--

** Section 13
In general, given the sensitivity of this functionality, it SHOULD be
accessible to authorized users only, and for specific use cases only.

If this data is considered sensitive, why would unauthorized users be permitted
to access it (as permitted by use of SHOULD and not a MUST).


[ML] The point is that it's not always sensisitive.  Therefore, I cannot 
write MUST because there might be cases where this functionality could 
also be accessible to anonymous users without causing a privacy violation.


Providing this feature to unauthorized users when it's based on a 
sensitive information would result in breaking a law rather than 
breaking a protocol.


Therefore, I'm absolutely sure that no RDAP provider will make it 
available to users who are not legitimate to use it.


Anyway, would it sound better if I changed that sentence into the 
following ?


/In those cases where this functionality makes use of sensitive 
information, it MUST be accessible to //authorized users only, and for 
specific use cases only./




** Section 13
Providing reverse search in RDAP carries the following threats as
described in [RFC6973]:

*  Correlation
*  Disclosure
*  Misuse of information

Therefore, RDAP providers need to mitigate the risk of those threats
by implementing appropriate measures supported by security services
(see Section 14).

Thank you for explicitly including a privacy considerations section to outline
the associated risks.  Can the text please be more specific in linking these
real threats with the proposed mitigations referenced in Section 14?

For example, if one is mitigating against “misuse of information” is that by an
authenticated/authorized or authenticated user?  Is some kind of
authentication/authorization required for this class of invocation of RDAP?
RFC7481 presents options but not much MTI.

How is “correlation” being mitigated?

What is “disclosure” in this case?  How is it mitigated?



[ML] Correlation and disclosure can be mitigated by minimizing 
functionalities and data within identity management (i.e. Role-Based 
Access Control) and keeping data opaque to unauthorized users by redaction.


Mis-use can be mitigated by requiring the purpose of the request (i.e. 
Purpose-Based Access Control). Two approaches can be followed:


- Full Trust: the registry trusts the fairness of an accredited user 
(e.g. a police officer, an authority). The requestor is always 
legitimated to submit his requests for a legal purpose but it might also 
be required to clearly specify the purpose as either an attribute of the 
user (e.g. a specific OpenID claim) or a query parameter


- Zero Trust: the registry requires documents assessing that the 
requestor is legitimated to submit a given request no matter the 
declared purpose. It can be implemented by assigning the requestor with 
temporary OpenID credentials linked to the given request and describing 
the request as an attribute of the user (i.e. Time-Based & 
Attribute-Based Access Control)


Could the text above work for you ?

If you need more information about such mitigation measures, please see 
the presentation I gave at IETF110 
(https://datatracker.ietf.org/meeting/110/materials/slides-110-regext-5i-mario-loffredo-draft-ietf-regext-rdap-reverse-search-00).


If it's worthwhile, I can also add text extracted from the conclusions 
of that presentation:


- To mitigate privacy threats, RDAP providers MUST set up an AAA 
infrastructure
operating in compliance with regulations about privacy protection in 
force in their

countries

- Consequently, RDAP providers SHALL implement authorization rules 
increasingly
stringent: from a policy based merely on roles, to requiring the request 
purpose, till to
assigning the user with temporary credentials and related grants that 
are scope limited


- Even if searches on contacts’ information might be made publicly 
available on those

contacts who gave the consent for publishing, RDAP providers are RECOMMENDED
to allow those searches only to authorized users


---

Re: [regext] John Scudder's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS)

[Mario Loffredo]

Hi John,

thanks a lot for your review.

Please find my comments below.

Il 22/08/2023 22:55, John Scudder via Datatracker ha scritto:

John Scudder has entered the following ballot position for
draft-ietf-regext-rdap-reverse-search-24: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/



--
DISCUSS:
--

Thanks for this document. I have one concern, which should be easy to address.

It looks as though draft-ietf-jsonpath-base should be a Normative reference. In
fact, this is explicitly mentioned in the shepherd writeup (thank you!):

 > 15. Should any informative references be normative or vice-versa? See
 the [IESG > Statement on Normative and Informative References][16].

 JSON Paths are depended on normatively in the document, but the
 reference for them is to I-D.ietf-jsonpath-base, which is why that
 reference is informative.  (This is in keeping with e.g. RFC 8977,
 though in that case the reference was to the original description of
 the JSON Path behaviour at https://goessner.net/articles/JsonPath/.)

However, that rationale doesn't make sense to me. If a normative reference is a
downref, "just stick it in the informative references section instead" is not
the appropriate fix, the usual thing is to keep it in the normative references
and then the RFC Editor deals with the mismatch by holding off on publication
of the dependent document, until the dependency is published (a so-called
"cluster").  In this case, draft-ietf-jsonpath-base is on the same IESG agenda
as draft-ietf-regext-rdap-reverse-search is, so there isn't even much reason to
worry that draft-ietf-regext-rdap-reverse-search will be stalled for long if at
all, the two will likely move together.

The easiest way to resolve this DISCUSS would be to change the reference to
Normative. If for some reason that's considered unacceptable, I'd appreciate a
discussion explaining why, and why "make it an informative reference" should be
acceptable.



[ML]  I fully agree with you.

That reference is informative because I literally interpreted Note 4 but 
it should be normative.


I'll move it to the Normative References.


Best,

Mario





--
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

Re: [regext] Robert Wilton's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS and COMMENT)

[Mario Loffredo]

Hi Robert,

thanks a lot for your review.

Please find my comments inline.

Il 23/08/2023 15:06, Robert Wilton via Datatracker ha scritto:

Robert Wilton has entered the following ballot position for
draft-ietf-regext-rdap-reverse-search-24: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
for more information about how to handle DISCUSS and COMMENT positions.



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/



--
DISCUSS:
--



Hi,

Flagging part of the IANA considerations as a DISCUSS, but I think that this
should be easy to resolve:

(1) p 11, sec 12.2.1.  Creation of the RDAP Reverse Search Registries

These registries follow the Specification Required process as defined
in Section 4.5 of [RFC8126].

The designated expert should prevent collisions and confirm that
suitable documentation, as described in Section 4.6 of [RFC8126], is
available to ensure interoperability.  References are not limited
only to RFCs and simple definitions could be described in the
registries themselves.

I'm not sure that "simple definitions could be described in the registries
themselves" is consistent with the "Specification Required" policy chosen above.


[ML] You are right. I'll change that sentence as in the following:

   References are not limited
   only to RFCs but can also locate document published outside of the RFC path, 
including informal
   documentation.

Does it work for you ?




--
COMMENT:
--

[I support John's discuss on normative references.]

I also have some other comments that you may wish to consider:

(2) p 14, sec 12.2.4.2.  Initial Content

   +==+==+
   | Property | Property Path|
   +==+==+
   | fn   | $.entities[*].vcardArray[1][?(@[0]=='fn')][3]|
   +--+--+
   | handle   | $.entities[*].handle |
   +--+--+
   | email| $.entities[*].vcardArray[1][?(@[0]=='email')][3] |
   +--+--+
   | role | $.entities[*].roles  |
   +--+--+

Would it be helpful for this table to include the "Description" and "Reference"
properties?


[ML] Do you mean the "Description" and "Reference" related to the 
specific mapping for the reverse search property or those related to the 
reverse search property ?


In the latter case they are already included in Table 2 and Table 1 
respectively.


In the first case, they are missing and must be first added to the "RDAP 
Reverse Search Mapping Registry".


Since there might be specifications proposing a diffierent maping for an 
existing reverse search property it sounds reasonable to me to add both 
of them.




Minor level comments:

(3) p 3, sec 1.  Introduction

The protocol described in this specification aims to extend the RDAP
query capabilities and response to enable reverse search based on the
relationships defined in RDAP between an object class for search and
a related object class.  The reverse search based on the domain-
entity relationship is treated as a particular case of such a generic
model.

This introduction text seems to immediately jump into a defense as to why it is
okay to standardize this functionality in an RDAP extension.  This is okay, but
I wonder whether it wouldn't be better if the introduction only included the
last paragraph (i.e., that is stating what extension is defined in this
document), and the rest of the text was moved into a "Background" subsection of
the introduction.


[ML]  Sounds reasonable to me. Then, the new Introduction section should 
be arranged as into the following:


1. Introduction

The protocol described in this specification aims to extend the RDAP
   query capabilities and response to enable reverse search based on the
   relationships defined in RDAP between an object class for search and
   a related object class.  The reverse search based on the domain-
   entity relationship is treated as a particular case of such a generic
   model.

1.1 Background

   Reverse Whois is a service provided by many 

Re: [regext] Éric Vyncke's No Objection on draft-ietf-regext-rdap-reverse-search-24: (with COMMENT)

[Mario Loffredo]

Hi Éric,

thanks a lot for your review.

Best,

Mario

Il 23/08/2023 16:15, Éric Vyncke via Datatracker ha scritto:

Éric Vyncke has entered the following ballot position for
draft-ietf-regext-rdap-reverse-search-24: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/



--
COMMENT:
--

Thank you for the work put into this document.

While my review did not identity any issues, I am supporting Lars' & John's
DISCUSS points.

Special thanks to Tom Harrison for the shepherd's detailed write-up including
the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric



___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


--
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

Re: [regext] Lars Eggert's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS and COMMENT)

[Murray S. Kucherawy]

On Tue, Aug 22, 2023 at 6:11 AM Mario Loffredo 
wrote:

> > ### Outdated references
> >
> > Document references `draft-ietf-jsonpath-base-17`, but `-19` is the
> latest
> > available revision.
>
> [ML] The document makes use of the citation
>
> https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-jsonpath-base.xml
> that properly shows '-19' as the last revision of jsonpath-base.
>
> Version '-17' is reported instead when the document is rendered.
>
> Could it be a bug of the rendering tool ?
>

I think this is minor, and the RFC Editor will fix it anyway because the
normative reference will cause this document to wait for that one, and then
both will be RFCs.

-MSK
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] John Scudder's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS)

[Murray S. Kucherawy]

On Thu, Aug 24, 2023 at 3:33 AM Mario Loffredo 
wrote:

> > It looks as though draft-ietf-jsonpath-base should be a Normative
> reference. In
> > fact, this is explicitly mentioned in the shepherd writeup (thank you!):
> >
> >  > 15. Should any informative references be normative or
> vice-versa? See
> >  the [IESG > Statement on Normative and Informative
> References][16].
> >
> >  JSON Paths are depended on normatively in the document, but the
> >  reference for them is to I-D.ietf-jsonpath-base, which is why
> that
> >  reference is informative.  (This is in keeping with e.g. RFC
> 8977,
> >  though in that case the reference was to the original
> description of
> >  the JSON Path behaviour at
> https://goessner.net/articles/JsonPath/.)
> >
> > However, that rationale doesn't make sense to me. If a normative
> reference is a
> > downref, "just stick it in the informative references section instead"
> is not
> > the appropriate fix, the usual thing is to keep it in the normative
> references
> > and then the RFC Editor deals with the mismatch by holding off on
> publication
> > of the dependent document, until the dependency is published (a so-called
> > "cluster").  In this case, draft-ietf-jsonpath-base is on the same IESG
> agenda
> > as draft-ietf-regext-rdap-reverse-search is, so there isn't even much
> reason to
> > worry that draft-ietf-regext-rdap-reverse-search will be stalled for
> long if at
> > all, the two will likely move together.
> >
> > The easiest way to resolve this DISCUSS would be to change the reference
> to
> > Normative. If for some reason that's considered unacceptable, I'd
> appreciate a
> > discussion explaining why, and why "make it an informative reference"
> should be
> > acceptable.
> >
> >
> [ML]  I fully agree with you.
>
> That reference is informative because I literally interpreted Note 4 but
> it should be normative.
>
> I'll move it to the Normative References.
>

Thanks John for noticing this (and pardon my amazement that I missed this
detail, which is something I normally look for), and Mario for the fix.

-MSK
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] Robert Wilton's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS and COMMENT)

[Mario Loffredo]

Hi Amanda,


Il 23/08/2023 19:51, Amanda Baber ha scritto:

Regarding the use of a brief description in the registry itself as the "Specification" in 
"Specification Required": I missed it this time, but we ran into this same question with 
draft-ietf-calext-jscalendar-21, and FWIW, Barry Leiba recommended to the author that the 
registration procedure be changed to Expert Review.


Please see my response to Robert Wilton's remarks.

Think that changing the text as I proposed could solve the problem.

I'm sure that Andy and Scott as DEs would like to receive a 
specification supporting a request for the registration of new reverse 
search properties or new mappings.


Therefore, I would like to make the IANA Considerations section 
compliant to the Specification Required policy.



Best,

Mario



Thanks,
Amanda

On 8/23/23, 6:07 AM, "iesg on behalf of Robert Wilton via Datatracker" 
 wrote:

 Robert Wilton has entered the following ballot position for
 draft-ietf-regext-rdap-reverse-search-24: Discuss

 When responding, please keep the subject line intact and reply to all
 email addresses included in the To and CC lines. (Feel free to cut this
 introductory paragraph, however.)


 Please refer to 
https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!PtGJab4!_Nbv4aqGp36yMsh4urjgozBK2A_rIEY2i19RDAgHNiDersZRIlzMkjluoUFmtpZqiPm4XoiUsqnZRMTv8R0bod8$
 [ietf[.]org]
 for more information about how to handle DISCUSS and COMMENT positions.


 The document, along with other ballot positions, can be found here:
 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/__;!!PtGJab4!_Nbv4aqGp36yMsh4urjgozBK2A_rIEY2i19RDAgHNiDersZRIlzMkjluoUFmtpZqiPm4XoiUsqnZRMTvYBEfpd4$
 [datatracker[.]ietf[.]org]



 --
 DISCUSS:
 --



 Hi,

 Flagging part of the IANA considerations as a DISCUSS, but I think that 
this
 should be easy to resolve:

 (1) p 11, sec 12.2.1.  Creation of the RDAP Reverse Search Registries

These registries follow the Specification Required process as defined
in Section 4.5 of [RFC8126].

The designated expert should prevent collisions and confirm that
suitable documentation, as described in Section 4.6 of [RFC8126], is
available to ensure interoperability.  References are not limited
only to RFCs and simple definitions could be described in the
registries themselves.

 I'm not sure that "simple definitions could be described in the registries
 themselves" is consistent with the "Specification Required" policy chosen 
above.


 --
 COMMENT:
 --

 [I support John's discuss on normative references.]

 I also have some other comments that you may wish to consider:

 (2) p 14, sec 12.2.4.2.  Initial Content

   +==+==+
   | Property | Property Path|
   +==+==+
   | fn   | $.entities[*].vcardArray[1][?(@[0]=='fn')][3]|
   +--+--+
   | handle   | $.entities[*].handle |
   +--+--+
   | email| $.entities[*].vcardArray[1][?(@[0]=='email')][3] |
   +--+--+
   | role | $.entities[*].roles  |
   +--+--+

 Would it be helpful for this table to include the "Description" and 
"Reference"
 properties?

 Minor level comments:

 (3) p 3, sec 1.  Introduction

The protocol described in this specification aims to extend the RDAP
query capabilities and response to enable reverse search based on the
relationships defined in RDAP between an object class for search and
a related object class.  The reverse search based on the domain-
entity relationship is treated as a particular case of such a generic
model.

 This introduction text seems to immediately jump into a defense as to why 
it is
 okay to standardize this functionality in an RDAP extension.  This is 
okay, but
 I wonder whether it wouldn't be better if the introduction only included 
the
 last paragraph (i.e., that is stating what extension is defined in this
 document), and the rest of the text was moved into a "Background" 
subsection of
 the in

Re: [regext] Opsdir last call review of draft-ietf-regext-rdap-reverse-search-24

[Mario Loffredo]

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  
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 
 
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 Telematic

Re: [regext] [Ext] Robert Wilton's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS and COMMENT)

[Amanda Baber]

Hi Mario,

I see that the new text is "References are not limited only to RFCs but can 
also locate document published outside of the RFC path, including informal 
documentation." For IANA's purposes, this sentence isn't necessary, as the 
Specification Required policy was specifically meant to encompass non-RFC 
documentation (see Section 4 of RFC 8126 for registration procedure 
definitions), but no problem at all with including it.

Thanks,
Amanda

On 8/24/23, 9:18 AM, "iesg on behalf of Mario Loffredo"  wrote:

Hi Amanda,


Il 23/08/2023 19:51, Amanda Baber ha scritto:
> Regarding the use of a brief description in the registry itself as the 
"Specification" in "Specification Required": I missed it this time, but we ran 
into this same question with draft-ietf-calext-jscalendar-21, and FWIW, Barry 
Leiba recommended to the author that the registration procedure be changed to 
Expert Review.

Please see my response to Robert Wilton's remarks.

Think that changing the text as I proposed could solve the problem.

I'm sure that Andy and Scott as DEs would like to receive a 
specification supporting a request for the registration of new reverse 
search properties or new mappings.

Therefore, I would like to make the IANA Considerations section 
compliant to the Specification Required policy.


Best,

Mario

>
> Thanks,
> Amanda
>
> On 8/23/23, 6:07 AM, "iesg on behalf of Robert Wilton via Datatracker" 
 wrote:
>
>  Robert Wilton has entered the following ballot position for
>  draft-ietf-regext-rdap-reverse-search-24: Discuss
>
>  When responding, please keep the subject line intact and reply to all
>  email addresses included in the To and CC lines. (Feel free to cut 
this
>  introductory paragraph, however.)
>
>
>  Please refer to 
https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!PtGJab4!_Nbv4aqGp36yMsh4urjgozBK2A_rIEY2i19RDAgHNiDersZRIlzMkjluoUFmtpZqiPm4XoiUsqnZRMTv8R0bod8$
 [ietf[.]org]
>  for more information about how to handle DISCUSS and COMMENT 
positions.
>
>
>  The document, along with other ballot positions, can be found here:
>  
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/__;!!PtGJab4!_Nbv4aqGp36yMsh4urjgozBK2A_rIEY2i19RDAgHNiDersZRIlzMkjluoUFmtpZqiPm4XoiUsqnZRMTvYBEfpd4$
 [datatracker[.]ietf[.]org]
>
>
>
>  
--
>  DISCUSS:
>  
--
>
>
>
>  Hi,
>
>  Flagging part of the IANA considerations as a DISCUSS, but I think 
that this
>  should be easy to resolve:
>
>  (1) p 11, sec 12.2.1.  Creation of the RDAP Reverse Search Registries
>
> These registries follow the Specification Required process as 
defined
> in Section 4.5 of [RFC8126].
>
> The designated expert should prevent collisions and confirm that
> suitable documentation, as described in Section 4.6 of [RFC8126], 
is
> available to ensure interoperability.  References are not limited
> only to RFCs and simple definitions could be described in the
> registries themselves.
>
>  I'm not sure that "simple definitions could be described in the 
registries
>  themselves" is consistent with the "Specification Required" policy 
chosen above.
>
>
>  
--
>  COMMENT:
>  
--
>
>  [I support John's discuss on normative references.]
>
>  I also have some other comments that you may wish to consider:
>
>  (2) p 14, sec 12.2.4.2.  Initial Content
>
>+==+==+
>| Property | Property Path|
>+==+==+
>| fn   | $.entities[*].vcardArray[1][?(@[0]=='fn')][3]|
>+--+--+
>| handle   | $.entities[*].handle |
>+--+--+
>| email| $.entities[*].vcardArray[1][?(@[0]=='email')][3] |
>+--+--+
>| role | $.entities[*].roles  |
>+--+--+
>
>  Would it b

Re: [regext] [Ext] Robert Wilton's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS and COMMENT)

[Mario Loffredo]

Hi Amanda,

thanks a lot for your quick reply.

You're right. I can remove that sentence.

Thanks a lot,

Mario

Il 25/08/2023 00:17, Amanda Baber ha scritto:

Hi Mario,

I see that the new text is "References are not limited only to RFCs but can also 
locate document published outside of the RFC path, including informal 
documentation." For IANA's purposes, this sentence isn't necessary, as the 
Specification Required policy was specifically meant to encompass non-RFC documentation 
(see Section 4 of RFC 8126 for registration procedure definitions), but no problem at all 
with including it.

Thanks,
Amanda

On 8/24/23, 9:18 AM, "iesg on behalf of Mario Loffredo"  wrote:

 Hi Amanda,


 Il 23/08/2023 19:51, Amanda Baber ha scritto:
 > Regarding the use of a brief description in the registry itself as the 
"Specification" in "Specification Required": I missed it this time, but we ran 
into this same question with draft-ietf-calext-jscalendar-21, and FWIW, Barry Leiba recommended to the 
author that the registration procedure be changed to Expert Review.

 Please see my response to Robert Wilton's remarks.

 Think that changing the text as I proposed could solve the problem.

 I'm sure that Andy and Scott as DEs would like to receive a
 specification supporting a request for the registration of new reverse
 search properties or new mappings.

 Therefore, I would like to make the IANA Considerations section
 compliant to the Specification Required policy.


 Best,

 Mario

 >
 > Thanks,
 > Amanda
 >
 > On 8/23/23, 6:07 AM, "iesg on behalf of Robert Wilton via Datatracker" 
 wrote:
 >
 >  Robert Wilton has entered the following ballot position for
 >  draft-ietf-regext-rdap-reverse-search-24: Discuss
 >
 >  When responding, please keep the subject line intact and reply to 
all
 >  email addresses included in the To and CC lines. (Feel free to cut 
this
 >  introductory paragraph, however.)
 >
 >
 >  Please refer to 
https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!PtGJab4!_Nbv4aqGp36yMsh4urjgozBK2A_rIEY2i19RDAgHNiDersZRIlzMkjluoUFmtpZqiPm4XoiUsqnZRMTv8R0bod8$
 [ietf[.]org]
 >  for more information about how to handle DISCUSS and COMMENT 
positions.
 >
 >
 >  The document, along with other ballot positions, can be found here:
 >  
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/__;!!PtGJab4!_Nbv4aqGp36yMsh4urjgozBK2A_rIEY2i19RDAgHNiDersZRIlzMkjluoUFmtpZqiPm4XoiUsqnZRMTvYBEfpd4$
 [datatracker[.]ietf[.]org]
 >
 >
 >
 >  
--
 >  DISCUSS:
 >  
--
 >
 >
 >
 >  Hi,
 >
 >  Flagging part of the IANA considerations as a DISCUSS, but I think 
that this
 >  should be easy to resolve:
 >
 >  (1) p 11, sec 12.2.1.  Creation of the RDAP Reverse Search 
Registries
 >
 > These registries follow the Specification Required process as 
defined
 > in Section 4.5 of [RFC8126].
 >
 > The designated expert should prevent collisions and confirm that
 > suitable documentation, as described in Section 4.6 of 
[RFC8126], is
 > available to ensure interoperability.  References are not limited
 > only to RFCs and simple definitions could be described in the
 > registries themselves.
 >
 >  I'm not sure that "simple definitions could be described in the 
registries
 >  themselves" is consistent with the "Specification Required" policy 
chosen above.
 >
 >
 >  
--
 >  COMMENT:
 >  
--
 >
 >  [I support John's discuss on normative references.]
 >
 >  I also have some other comments that you may wish to consider:
 >
 >  (2) p 14, sec 12.2.4.2.  Initial Content
 >
 >
+==+==+
 >| Property | Property Path
|
 >
+==+==+
 >| fn   | $.entities[*].vcardArray[1][?(@[0]=='fn')][3]
|
 >
+--+--+
 >| handle   | $.entities[*].handle 
|
 >
+--+--+
 >| email| $.entities[*].vcardArray[1][?(@[0]=='email')][3] 
|
 >
+