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

From: Mario Loffredo <[email-masked]>
Date: Wed, 23 Dec 2020 13:43:01 +0100

Hi Ali,

please find my comments inline.

Il 22/12/2020 07:33, Ali Hussain ha scritto:
> Hi Dr. Mario,
[ML] please simply 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.?

[ML] The WG has already adopted a document written by Scott Hollenbeck 
(i.e. https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid 
<https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid>) about 
how to implement a federated authentication in RDAP context. OpenId is 
based on tokens exchanged between the various actors involved (e.g. RDAP 
client, RDAP server, Authorization Server). In particular, the ID Token 
is provided according the JWT format and contains information regarding 
the user identification and a set of claims describing the user. The 
RDAP server can then make identification, authorization, and access 
control decisions based on local policies and the information included 
in the ID Token.

Furthermore, the rdap-openid document defines RDAP specific claims in 
addition to the standard ones. In my opinion, the combination of OpenId 
and RDAP specific claims are appropriate to make an authorization 
decision for a client submitting a reverse search. Especially the set of 
values defined for the "purpose" claim seems to me comprehensive enough 
to include purposes which might be used to legitimate a reverse search 
request. Note also that the set of admissible "purpose" values can be 
extended.

Therefore, it seems to me that your requirements/solutions have been 
addressed by rdap-openid.

Definitively, reverse search is only one of the possible queries clients 
can submit and servers can authorize so I don't think we need to add in 
the reverse-search draft anything beyond what is stated by RFC7481 and 
rdap-openid.

Neither we must explicitly require an RDAP provider to accept always a 
reverse search only if previously authorized. As it is stated in section 
7, we can only require that this capability must be compliant with the 
rules about privacy protection each RDAP provider is subject to and each 
RDAP provider is responsible for pursuing this objective.

Best,

Mario

>
> Thanks,
>
> Regards,
> Ali Hussain
>
>
> On Fri, Dec 4, 2020 at 1:27 AM Mario Loffredo 
> <[email-masked] <mailto:[email-masked]>> 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
>>     [email-masked]  <mailto:[email-masked]>
>>     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: +39.0503153497
>     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: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo

---

From: Mario Loffredo <[email-masked]>
Date: Wed, 23 Dec 2020 13:43:17 +0100

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 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Dr. Mario,
>
>     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.
>
>         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.
>
>         everyone but the access to possible sensitive response data
>         are reserved only to authenticated users, right?
>
>         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?
>
>         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
>
>
>>         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
>>