[db-wg] The DBTF needs your feedback!

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
>