[DBWG] Possible solutions to the changed attribute issue

[Ben Maddison]

Hi all,

On 08/24, Nishal  Goburdhan wrote:

> On 24 Aug 2020, at 11:05, Simon Seruyinda wrote:

> 

> > Dear DBWG

> > 

> > We have had discussions internally regarding the changed attribute and

> > we acknowledge the challenges sorrounding its effectiveness and accuracy

> > as a reliable source of who made the changes and when.

> > Current WHOIS behaviour does not force the addition of a changed

> > attribute during an update if one already exists.

> 

> this is not my experience.  but i might be an anomaly.

> 

> 

> > Besides validating that the email address the user provides is a valid

> > one,

> 

> to be clear, this validation does not occur;  you probably mean that there

> is check for something resembling email syntax.

> that is not the same as a valid email address ..

> 

> 

> > the changed attribute is for the users own reference.

> > Nothing can be determined by a third party by looking at the email

> > address provided here.


Since no (real) validation is performed, and the address does not (even
in theory) identify the authoriser of the change, I don't think *anyone*
can determine *anything* from it!


> > As pointed out by Frank, currently the date is not validated to confirm

> > that it matches the date when update is being done, but we can change

> > this to make it auto-generated.

> 

> timestamping in UTC seem to be the rational thing to do..

> 

> 

> > In our internal discussions, the following options were considered:

> > 

> > 1. Eliminate other avenues of creating and updating WHOIS objects such

> > as webupdate and auto-dbm and leave only myafrinic.

> 

> NO!


N, you missed at least 6 "NO"s.

> 

> do you really mean to trade my pgp-signed updates, where *i* control my

> private key, for a system that sends out passwords in plain text, and fails

> basic best practices for web security [1]  despite being warned repeatedly?

> i am all for securing access to the db;  please explain how removing my

> access to pgp-signed mail, promotes that notion?

> 

This would be a huge step backwards. PLEASE DO NOT EVEN CONSIDER THIS!

> 

> > Allow non-registered contacts to register on the portal with limited

> > access to specific functionality so that when a change or creation of an

> > object is done, we know exactly who is making the updates. This would

> > enable us to auto-generate the changed attribute. This would be possible

> > in myafrinic v2 which is currently under development.

> 

> i can understand why it is easy to think that myafrinic2 will be a panacea.

> but with no release date, or upcoming feature list, or [..]  (i looked on

> both your website, and your portal, and could not see a release/feature

> schedule), i feel less comfortable about expecting anything from this

> project.  also - whilst your portal is likely fine for folks that want to

> click-through-to-make-irregular-changes, and i applaud efforts to make this

> as easy to use as possible for them, you’re forgetting:

> # ben’s quite reasonable request for an API for larger networks that need

> the automation to scale

> # “email” .. is just another API ..   (well, loosely ;-))

> 

Yes, just a particularly bad one. Email, however, is still better than
clicky, clicky, click through a GUI.
Forcing operators through a web interface will significantly worsen the
data quality of the whois.


> 

> > 2. Slowly deprecate the changed attribute and replace it with two

> > auto-generated attributes namely created and last-updated or

> > last-modified both of which would take the date whose format we can

> > discuss and agree upon here.

> 

> i think most people don’t care what you call it;  the principles are simple:

> # lock in maintainers for everything;  make these immutable (do *NOT* allow

> people to remove them (even intentionally) 


+1


> and if it means that you need to

> make the time during the Great StayHome of 2020 to schedule 1-on-1 telephone

> calls with those, fewer than ten[2], users that removed their auto-generated

> maintainer, then *DO IT* for the sake of better security for all;


+1


> # generated the timestamp for changed / last-updated / call-it-what-you-want

> based on $transaction_time authenticated by $authorised_mnter;

> # generated the “who changed it” (call it what you want) from the mnter.

> 

> at least this is how i read ben’s quite sensible suggestion earlier.

> what, from the above, do you need this working group to help with?

> community consensus around mandatory maintainerS?  :-)

> 

That is exactly what I was suggesting, yes.

> 

> > How have other RIRs handled this?

> > 

> > RIPE:

> > Began deprecation of the changed attribute in 2015, and replaced it with

> > created and last-modified attributes.

> > https://labs.ripe.net/Members/tim/deprecating-the-changed-attribute-in-the-ripe-database

> > 

> > APNIC:

> > Replaced the changed attribute with the last-modified attribute

> > https://www.apnic.net/get-ip/faqs/last-modified-attribute/

> 

> i admit i didn’t think of the anti-spam thing;  so yeah, i have no issue

> hiding the email address in a regular query, as long as it can be retrieved

> via a  --history option (-B ?) or something similar.

> 

Perhaps easier to use the mnter name rather than trying to grep an email
address associated with that mntner? Then no extra attributes with email
addresses in it to send spam to.

I think the solutions implemented at RIPE and APNIC fail to recognise
that attribution is important.

Cheers,

Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/dbwg/attachments/20200825/a07b7d3f/attachment.sig>