Colleagues You beat me to it Shane. I was thinking the same (and more) last night.
There are several issues to consider here that have not yet been mentioned, as Shane pointed some of them out. First of all let me suggest that we drop this thought that this is simply a matter of moving the public RIPE Database to a different platform. It is much more than that. The RIPE Database is a complex system. It is not just the data the public sees. So what else is it? Shane mentioned the 'log files'. Every operation on the RIPE Database is logged in fine detail. So for an update details are stored of who did what to which bit of data, at what time, from where, using which authorisation method and whose specific authentication tokens and the outcome of that update request. I am not sure if the clear text password is still logged in email updates containing them or if the passwords are stripped out. Who is notified of these changes is also logged. None of this data is public and a court order is needed to access it. For queries details of who queries for what and when is also logged. This is also not public information. The RIPE NCC's proposals and impact analyses make no mention of these log files. Will they all be stored on the cloud in this future scenario? Will updates still be sent to the RIPE NCC for logging and pre processing with only the database changes sent to the cloud? Even if logs are downloaded by the NCC daily and deleted from the cloud they may still exist in cloud backups. Any kind of disassociation between the object data and these log files would be complex. Then there is data history. This is built into the fundamental database design and architecture. Every version of every object ever created in the last 20 years is an integral part of the database. Historical queries only allow public access to limited amounts of operational data. The full history of all personal data, organisational data, security management, even forward domains still exists as an integral part of the database. To separate this out would require significant and major re-design of the database structure and operation. The RIPE Database never forgets anything or anyone. Many domain registries used the database as their primary domain registry in the past. They may think all that data has long since gone. But the database never forgets. I have had domains for 20+ years. If that data was in the database it is still there and still correct. Any new features or purposes added to the RIPE Database in the future would also have to take into account the legal jurisdiction of the data. Moving the 'RIPE Database' into a legal jurisdiction outside of the EU has many consequences if foreign governments have powers to access this data. So this is not just a matter of moving public data to 'someone else's computer'. It is not a matter of trying to micro manage the technical operations of the RIPE NCC. This proposal has significant legal, political and policy consequences. cheers denis co-chair DB-WG On Wed, 23 Jun 2021 at 09:19, Shane Kerr <[email protected]> wrote: > > Nick, > > On 22/06/2021 23.50, Nick Hilliard wrote: > > Patrik Fältström wrote on 22/06/2021 21:23: > > > > With regard to the ripe database and the rpki repo, it doesn't look like > > there are any specific legal issues that haven't been considered. All > > of this information is publicly accessible anyway. There may well be a > > different set of considerations for other types of data. > > I don't think that is is okay to say "this information is publicly > accessible anyway". On a RIPE Database or RPKI server there is meta-data > about *who* is accessing the database, including timestamps, source > addresses, and possibly other data. There is also meta-data about *what > queries* are made to the database. There also things to be learned about > replication delays between servers, and surely a lot more that might be > of interest to creative folks. > > I don't know about now, but at one point there were firewalls and/or > intrusion-detection systems that would query the RIPE Database to give > the admin information about the source of suspicious traffic. An > attacker trying to penetrate a network might be able to identify which > security products were in use if given unrestricted access to WHOIS > query logs. I'm not saying this is a likely scenario, I'm saying we > should be cautious about declaring access to data safe. Humans (and > increasingly AI) are ingenious about ways to use systems in unintended ways. > > As a thought experiment to try to demonstrate the idea, how would you > feel about a proposal to provide public access to complete system logs > of all RIPE Database servers? If that makes you nervous in any way - and > I think that it should! - then this is exactly why we should consider > the operators hosting RIPE Database (and RPKI) resources important. > > Cheers, > > -- > Shane
