[regext] Fwd: Ideas to address the privacy implication of reverse search draft

[Mario Loffredo <[e-mail]>]

Hi Ali,
Il 23/12/2020 00:24, Ali Hussain ha scritto:
> Hi Dr. Mario,
>
> Hope you are fine.
>
> Another area i would like to touch is to limit the server ability to 
> do user profiling. This could be a simple mechanism using HTTP secure 
> header enforcement and users identity proof generation and refreshing.

Sorry but I don't understand what you mean with the term "user 
profiling".  If "user profiling" is the commonly known term to identify 
a process a service can implement to gain knowledge about its users' 
interests, opinions and other characters, my thought is that this topic 
is out of both the reverse search and, more generally, the RDAP context 
for the following reasons:

1. the well known privacy concerns about reverse search regard the 
information about individuals in WHOIS/RDAP responses rather than the 
possible individuals sending requests;

2. supposing that RDAP users might run some risk to be profiled by RDAP 
servers (thing that seems quite unlikely according to my personal 
experience), such a threat would not be specific for reverse searches 
but, in general, for every RDAP query;

3. I interpret your proposal as a general approach to a problem that 
might involve a generic REST service instead of an RDAP server. If so, 
the most suitable forum for discussion would be the new HTTPAPI WG.

Conversely, it makes more sense to me that clients can use the content 
of reverse search responses to profile individuals. For example, clients 
could gain knowledge about registrants by classifying the names of their 
own domains. However, the mechanisms to mitigate this risk have already 
been presented in reverse-search draft (e.g. allowing  only to 
authenticated/legitimated users to request a reverse search)


Best,

Mario

>
> Please share your thought about it.
>
> Looking forward work with you to address these issue and 
> possible start written an publishing the draft spoon before upcoming 
> IETF110.
>
> Thanks,
>
> Regards,
> Ali Hussain
>
> On Mon, Dec 21, 2020 at 10:33 PM Ali Hussain 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Hi Dr. Mario,
>
>     Apologies for replying too late.
>
>     First of all thanks for your detailed comments about the proposed
>     tentative iea to make reverse search more
>     privacy complaints keeping hrpc guidelines as reference.
>
>     One possible new work in giving better privacy to reverse search
>     would be to have privacy by design implementation in addition to
>     federated access using HTTP and limiting the response. The
>     proposed mechanism may use an integrity protection mechanism HMAC
>     or standard authorization mechnaum like JSON web token to bring in
>     additional data confidentiality and privacy benefits. This way we
>     would be able to easily define the custom access control policies.
>
>     What do you think about it.?
>
>     Thanks,
>
>     Regards,
>     Ali Hussain
>
>
>     On Fri, Dec 4, 2020 at 1:27 AM Mario Loffredo
>     <[e-mail] <mailto:[e-mail]>> wrote:
>
>         Hi Ali,
>
>         thanks a lot for your interest.
>
>         Obviously, I'm willing to collaborate with anyone who plans to
>         implement the reverse-search capability and I'm open to any
>         idea that can contribute to make the proposal more comprehensive.
>
>         I'm also available to give my humble contribution to harmonize
>         the reverse-search specification with the concepts described
>         in the hrpc draft.
>
>         That being said, if I interpreted your idea correctly, you are
>         proposing an operation model where the capability is open to
>         everyone but the access to possible sensitive response data
>         are reserved only to authenticated users, right?
>
>         If so, I have a couple of comments:
>
>         - The RDAP servers are already engaged in tailoring their
>         responses on different user profiles due to GDPR. Sensitive
>         data redaction is usually achieved through a combination of
>         practices like not returning optional sensitive data,
>         replacing the value of  mandatory sensitive data (like jCard
>         "fn" for individuals), publishing only those sensitive data
>         which the owner has previously given the explicit consent for.
>         So which additional issues should your proposal address?
>
>         - In the case of a reverse-search, what must be allowed to
>         authenticated users is not the access to the data returned by
>         the capability but rather the capability itself.  Of course,
>         the reverse search is not the only query capability that can
>         be controlled. For example, at .it we don't permit everyone to
>         submit a generic search query.  This can be done either
>         through the well-known HTTP authentication methods as
>         described in RFC7480 or by applying a federated authentication
>         to RDAP as defined by Scott's rdap-openid extension.  To make
>         an ad-hoc access control easy to implement, the reverse-search
>         draft introduces the specific "/reverse" path and lets servers
>         furtherly regulate the access on a per-entiy-role basis.
>
>         Definitively, maybe I'm missing something but do we really
>         need anything other than what already exists?
>
>         Best,
>
>         Mario
>
>
>         Il 04/12/2020 01:47, Ali Hussain ha scritto:
>>         Hi All,
>>
>>         It wa  interesting to see the interest during REGEXT IETF 109
>>         meeting call to address the the privacy aspects of draft
>>         (draft-ietf-regext-rdap-reverse-search).
>>         So far my idea to improve the reverse search to first make
>>         the JSON object for the required level of privacy critical
>>         data. Based on the tag the partial response suppresses the
>>         privacy part of responses by encoding and in order to decode
>>         it, it must present an identity to federated access control.
>>         I am also reviewing the hrpc draft to bring some valuable
>>         input form their guidance.
>>         Please let me know what you think and is anyone else
>>         interested to work on this?
>>         Thanks,
>>         Regards,
>>         Ali Hussain
>>
>>         _______________________________________________
>>         regext mailing list
>>         [e-mail]  <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/regext  <https://www.ietf.org/mailman/listinfo/regext>
>
>         -- 
>         Dr. Mario Loffredo
>         Technological Unit “Digital Innovation”
>         Institute of Informatics and Telematics (IIT)
>         National Research Council (CNR)
>         via G. Moruzzi 1, I-56124 PISA, Italy
>         Phone: [phone]
>         Web:http://www.iit.cnr.it/mario.loffredo  <http://www.iit.cnr.it/mario.loffredo>
>
-- 
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: [phone]
Web:http://www.iit.cnr.it/mario.loffredo