Denis,
On 02/12/2020 23.39, denis walker via db-wg wrote:
Personally I don't think MNTNER objects should be visible at all to
the public. I don't know of any other service on the internet where
details of how you secure your data are open to the public. Being able
to query for someone else's MNTNER object is a throw back to the days
when only nice people used the internet :)
My understanding of why MNTNER is public is quite different. Many years
ago (like 19 or 20 years ago) I was told that the RIPE Database was
completely open because of the benefits that transparency brings. Among
these were:
* Not having to trust that the RIPE NCC was properly managing the data.
No data leaks are possible if all data is published at the start!
* Being able to make a copy of the database and have the entire public
registry available for archive or backup purposes (for example if
Holland was flooded and all RIPE NCC servers were destroyed).
If I recall correctly two main factors changed this philosophy:
1. Publishing encrypted passwords using CRYPT-PW was vulnerable to brute
force attacks, and even when updated to MD5-PW still vulnerable to
dictionary attacks.
2. PERSON objects became a huge privacy problem as more and more contact
data was published for people who had never even heard of RIPE.
As far as I know there is no suggestion that this complete openness is a
good idea today. Certainly I don't remember this being raised in the
RIPE Database Requirements Task Force discussions - quite the opposite!
There is a strong desire to collect and publish the minimum amount of
data possible.
As for whether MNTNER objects should be public... I always felt that the
MNTNER concept conflated authentication and authorization and identity,
and really the world would be better off without it.
When I was looking at the requirements for the ARIN database back in the
20th century I proposed that authentication should always be tied to a
human being, since any access to a database was always done on behalf of
a person (even when done via an automated tool). Authorization should
proceed based on role-based access controls (RBAC). At the time there
was not a strong privacy requirement (and since ARIN is in the USA
probably there still is no strong privacy requirement), so the idea was
to collect a complete history of all changes for all time, allowing
audits and rollback. Today I'd probably propose that policy for
historical data be a first class object that was something that could be
tweaked by users within system-defined limits.
Cheers,
--
Shane
