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
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Thank you to Tero Kivinen for the SECDIR review.
I support Lars Eggert's DISCUSS position.
** Section 1.
The first objection concerns the potential risks of privacy
violation.
Where are these privacy concerns summarized? Could a reference be provided?
[ML] The potential privacy risks are summarized in the Privacy
Considerations section.
Could it be sufficient to add a reference to that section from Section 1 ?
As an aside note, would like to outline that all of the privacy concerns
about reverse searches are common to the RDAP searches defined in RFC
9082 and responses defined in RFC 9083:
- the risk to publish information about individuals unless they have
previously given a consent for publishing. This risk is common to both
lookups and searches as well as to Whois responses
- the risk to detect facts (a.k.a. correlation) from the results as well
as to mis-use the RDAP service. These risks are mainly connected to the
submission of searches which can generate a large amounts of data but
also to a huge submission of lookups, especially for those registries
providing the zone file.
Best,
Mario
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
[email protected]
https://www.ietf.org/mailman/listinfo/regext
