Hi DB-WG, (Disclaimer: I can only speak on behalf of one CSIRT, the CSIRT i work for. I would like to read views from other CSIRTs on this) Havard has precisely touched the issues that a CSIRT often faces -- the whois information is a dead-end. And most of the time everyone knows the information was "cooked" to be a dead-end. Quoting Havard: "In other words, a bad-faith actor could already very well hide in plain sight, using the RIPE DB as a "privacy tax haven"." I don't think the correct word is "could": They do it as part of their "process" and everyone knows about it. Some do it poorly. Some do it to be obvious to everyone that the data is bogus. These actors shouldn't even be inside the system to start with!!!!!!! I'm pessimistic about the current level of abuse on the numbers registration ecosystem. If we want to be optimistic, then OK, the domain regitration ecosystem is a lot worse. But that dirt on the other side doesn't mean our side is clean. How to solve or improve this? No magic here! But focusing on "transparency" would be a good start, and if people really worry about "privacy" and "personal data", then a new rule about "only insert professional data on the RIPEdb" comes to mind. If one doesn't have any professional data, well, maybe that person shouldn't be part of the ecosystem. Regards, Carlos On Thu, 4 Feb 2021, Havard Eidnes via db-wg wrote:
Note that the task force has already published an incomplete draft of the requirements, so you can see what we have in mind:
https://www.ripe.net/resolveuid/ec75a6eb21684150bbcf6cd53917629c
I've read this with interest and also the discussion in this thread.
I wish to make a comment in this context.
The above quoted document doesn't really discuss what tools should be available to discourage undesireable actions on "the fringes" of our environment, typically actions which don't enjoy the light of day. One aspect to discourage such actions is "transparency", and that's hardly mentioned or discussed as a goal.
I would dislike for the usefullness of the RIPE DB to devolve to the same state of affairs the domain registry business has done. As a random example:
Domain Name: WHOISTHAT.COM Registry Domain ID: 85429666_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.enom.com Registrar URL: http://www.enom.com Updated Date: 2020-03-31T08:22:02Z Creation Date: 2002-04-09T21:59:54Z Registry Expiry Date: 2021-04-09T21:59:54Z Registrar: eNom, LLC Registrar IANA ID: 48 Registrar Abuse Contact Email: Registrar Abuse Contact Phone: Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Name Server: NS1.DSREDIRECTION.COM Name Server: NS2.DSREDIRECTION.COM DNSSEC: unsigned URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
Last update of whois database: 2021-02-04T13:22:21Z <<<
There's not exactly many hooks to grab onto in this information to know who or which organization actually stands behind this domain.
There also isn't a lot of discussion about what tools are already available if one wants to "hide in plain sight" in the RIPE DB. E.g. a "role" only has the following mandatory elements:
role: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] nic-hdl: [mandatory] [single] [primary/lookup key] mnt-by: [mandatory] [multiple] [inverse key] created: [generated] [single] [ ] last-modified: [generated] [single] [ ] source: [mandatory] [single] [ ]
...and... I guess the e-mail address isn't validated as being a working e-mail address, or leading to "the right place" either; and phone and fax# are both optional, and quite a bit of the other information isn't really verified either, so could very well be falsified.
And ... for an inetnum, all the mandatory fields are:
inetnum: [mandatory] [single] [primary/lookup key] netname: [mandatory] [single] [lookup key] country: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] status: [mandatory] [single] [ ] mnt-by: [mandatory] [multiple] [inverse key] created: [generated] [single] [ ] last-modified: [generated] [single] [ ] source: [mandatory] [single] [ ]
If the admin-c and tech-c can all be populated with a reference to a role with more-or-less anonymized contents, we're really not very far from the awful domain whois listing above.
In other words, a bad-faith actor could already very well hide in plain sight, using the RIPE DB as a "privacy tax haven".
I miss a discussion of what impact this push for ever more privacy has on transparency, and whether it is relevant to discuss the weighing of transparency on the one hand and privacy on the other.
Regards,
- Håvard