Forward DOMAIN Object Cleanup and Syntax Changes
[Apologies for duplicate emails] Dear colleagues, At RIPE 57, the RIPE NCC was asked to remove all forward domain data from the RIPE Database. The last two ccTLD operators' data was removed today, 31 January 2011. The RIPE NCC can now confirm the completion of action point AP57.2 from the RIPE Database Working Group. At RIPE 62, the RIPE NCC was asked to look at the attributes in DOMAIN objects. With the removal of any hierarchy in reverse delegations and the removal of forward domain data, we no longer see any use case for the "mnt-lower:" attribute. Other attributes that it has been suggested were used only for forward domains are: - "refer:" - "sub-dom:" - "dom-net:" The statistics listed at the bottom of this email show how many of these attributes have been added to ENUM and reverse delegation DOMAIN objects. It has also been suggested that the "nserver:" optional attribute could be made a "required" attribute in reverse delegation DOMAIN objects. It could remain optional in ENUM DOMAIN objects or it could be disallowed. The RIPE NCC asked the community in July 2011 if anyone saw any justification for the use of these attributes in ENUM or reverse delegation DOMAIN objects. We did not receive any feedback on this. If there is no justification, the syntax of the DOMAIN object can be adjusted to deprecate these attributes. Then all current DOMAIN objects in the RIPE Database can be "cleaned" to remove this data. Business rules can be added to make the "nserver:" attribute required or disallowed in different types of DOMAIN objects, if this is considered useful. To keep the discussion focused, please send any comments or feedback to the DNS Working Group mailing list. Regards, Denis Walker Business Analyst RIPE NCC Database Group Statistics (as at July 2011) ---------- Number of each attribute used in reverse delegations or ENUMs and the number of unique maintainers who manage these objects. "refer:" = 6 unique maintainers = 1 "sub-dom:" = 271 unique maintainers = 23 "dom-net:" = 2,219 unique maintainers = 140 "mnt-lower:" = 46,485 unique maintainers = 4,208
Hi! On 01/31/2012 05:17 PM, Denis Walker wrote:
If there is no justification, the syntax of the DOMAIN object can be adjusted to deprecate these attributes. Then all current DOMAIN objects in the RIPE Database can be "cleaned" to remove this data. Business
The justification question also comes to mind regarding the zone-c attribute, which should be deprecated (or "de-duped" as it is in the SOA anyway) in the same step. Regards, Chris
Hi there, We just had a problem with the RFC3068-MNT object, from what I can see, if you have an object with at least one auth: MD5 ... Only people that have one of the passwords can see the object in the webupdater and get the full object to manipulate the object. So now, instead of having a chance to get rid of shared passwords/passphrases, everybody needs to have one, because of the way objects are filtered. Only idea I've had so far, would be that there should be a way to request an object in a way where I can authenticate with my PGPKEY, for instance using email and not a webbrowser, so I'd sign a mail requesting an object, with a key that would be listed as authentication in the object I request, and that would return the unfiltered object to me. Of course, the other solution is to just get hold of all the people with an auth: MD5 line and make them take it out, that way you can get the full object without authenticating on the webupdater. I'm not sure if my thought here is useable, good or practical. But it someone can come up with a brilliant way to make shared objects of this kind smoothly, I suspect the people implementing the database will be eager to hear about it, and at the very least the people behind RFC3068-MNT will be gratefull. /Anders Forskningsnettet dk.denet
Hi, and thanks for bringing this up. This isn't particularly directed at you, I'm sure you can see...
So now, instead of having a chance to get rid of shared passwords/passphrases, everybody needs to have one, because of the way objects are filtered.
I'd say that's the wrong direction to lead people.
Of course, the other solution is to just get hold of all the people with an auth: MD5 line and make them take it out, that way you can get the full object without authenticating on the webupdater.
Do you need to specify any special options to whois to get the auth: lines from the maintainer object? We have a maintainer object where I'm pretty sure that all the auth: lines are of PGP- style, but whois is still not displaying those lines. Trying to use https://apps.db.ripe.net/webupdates/search.html it asks me for "password". What password?!? No, I have not used webupdates before, and have no particular desire to start using it now. Is there no way around this? I really, Really, dislike this change in behaviour, since we are now effectively cut off from updating our maintainer object -- we keep no local copy of the object, and want to use the one stored in the RIPE database as the authoritative data source. Now we can't do that. Argh! Regards, - Håvard
Do you need to specify any special options to whois to get the auth: lines from the maintainer object? We have a maintainer object where I'm pretty sure that all the auth: lines are of PGP- style, but whois is still not displaying those lines. Trying to use
https://apps.db.ripe.net/webupdates/search.html
it asks me for "password". What password?!? No, I have not used webupdates before, and have no particular desire to start using it now. Is there no way around this?
I really, Really, dislike this change in behaviour, since we are now effectively cut off from updating our maintainer object -- we keep no local copy of the object, and want to use the one stored in the RIPE database as the authoritative data source. Now we can't do that. Argh!
what he said sigh randy
Do you need to specify any special options to whois to get the auth: lines from the maintainer object? We have a maintainer object where I'm pretty sure that all the auth: lines are of PGP- style, but whois is still not displaying those lines. Trying to use
https://apps.db.ripe.net/webupdates/search.html
it asks me for "password". What password?!? No, I have not used webupdates before, and have no particular desire to start using it now. Is there no way around this?
I really, Really, dislike this change in behaviour, since we are now effectively cut off from updating our maintainer object -- we keep no local copy of the object, and want to use the one stored in the RIPE database as the authoritative data source. Now we can't do that. Argh!
Ditto. The one time I tried to use webupdates (3 days ago), I hit a bug. See the comments at the end: https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database -Hank
Hi, I'm following up on the "how to get at your complete maintainer object" case which was the subject of this thread. I've had a private discussion with the people manning the ripe-dbm@ripe.net role, and this is the information which has been revealed so far: The current implementation of the filtering in the RIPE whois server is such that *all* auth: attributes are removed from all maintainer objects, as we have all seen. As a LIR in the category who only use PGP auth: lines in our maintainer object (we're one of the 16% of all maintainers who are in the category "have either not used MD5-passwords or have abolished doing so"), I may still get at my full maintainer object without using any password. However, it has been confirmed that now I *do* have to use the web interface. I have to visit http://www.ripe.net/webupdates/ and activate the "Modify object in single text area" option before looking up my maintainer object. I'll then have to cut and paste this into whatever I use to update my maintainer object (in my case: my e-mail client). So... It is confirmed: this is forcing us to use the web interface to look up our maintainer object, where we could use the whois protocol earlier, something I'm unhappy about. I suggested to the RIPE NCC that instead of following the current implementation strategy, they could have followed the following strategy: In the whois server, if a maintainer object *only* contains auth: lines using currently deemed to be secure methods (currently PGP or X.509), then reveal all the auth: lines to the whois client. Otherwise, if the maintainer object contains one or more lower-security auth: attribute (currently MD5-based passwords), filter out *all* the auth: attributes. This would not require a behavioural change from those LIRs who have "done the right thing" and abolished MD5-encrypted passwords (or never even used them), instead of punishing us by forcing us to use the web interface when updating our maintainer objects. The complication that the RIPE NCC sees with this solution is that this would make it more difficult to explain what procedures need to be followed to update a maintainer object. My claim is that whois + e-mail if you do the right thing (only use PGP or X.509) and use web-updates if you do the wrong thing and use MD5 passwords is no more difficult to explain than the current situation, and as a bonus it does not punish LIRs who have already done the right thing and abolished MD5-based passwords. The RIPE NCC also basically said "this is what the community agreed to at the RIPE-63 meeting", and that if a change should come, the community should agree to it. Therefore I am bringing this matter to the RIPE database working group for discussion. My proposal is the alternative implementation strategy quoted above. Best regards, - Håvard
also a long-term pgp user. darn hard to use over some web thing when i do not have or want an account on it. yet another ncc full employment project that complicates my life. randy
Dear Colleagues, To clarify one point, use of Webupdates does not require any account or membership. It is a free to use tool for anyone to update the RIPE Database over secure https. For MNTNER objects with only PGP authentication, no authentication is asked for when using Webupdates to view the MNTNER object. The alternative suggestion for not filtering "auth:" attributes in MNTNER objects with PGP only would still fit with the community requirements for security of password hashes. The RIPE NCC implemented a proposal that had consensus from the community at the time. If there is a new consensus to change this, the RIPE NCC will implement the change. Regards, Denis Walker Business Analyst RIPE NCC Database Group
Denis, On Wednesday, 2012-03-07 15:36:26 +0100, Denis Walker <denis@ripe.net> wrote:
The alternative suggestion for not filtering "auth:" attributes in MNTNER objects with PGP only would still fit with the community requirements for security of password hashes. The RIPE NCC implemented a proposal that had consensus from the community at the time. If there is a new consensus to change this, the RIPE NCC will implement the change.
I support the proposal of leaving "auth:" attributes in the WHOIS output if no passwords would be published doing so. So, +1. :) Cheers, -- Shane
Hi Denis+all, Am 07.03.2012 um 15:36 schrieb Denis Walker:
Dear Colleagues,
To clarify one point, use of Webupdates does not require any account or membership. It is a free to use tool for anyone to update the RIPE Database over secure https. For MNTNER objects with only PGP authentication, no authentication is asked for when using Webupdates to view the MNTNER object.
The alternative suggestion for not filtering "auth:" attributes in MNTNER objects with PGP only would still fit with the community requirements for security of password hashes. The RIPE NCC implemented a proposal that had consensus from the community at the time. If there is a new consensus to change this, the RIPE NCC will implement the change.
since i'm one of the guys who still loves his password authentication as last resort, it doesn't really matter to me (until i can finally overcome my fear of not being able to update the database when i only have my not-so-smartphone with me or something :-> ). But anyways, i do support this change, since it makes much more sense for those who feel more secure with only key authentication. If it's possible to implement that without too much hassle, this suggestions has my support. -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect
Hi Håvard, All,
In the whois server, if a maintainer object *only* contains auth: lines using currently deemed to be secure methods (currently PGP or X.509), then reveal all the auth: lines to the whois client. Otherwise, if the maintainer object contains one or more lower-security auth: attribute (currently MD5-based passwords), filter out *all* the auth: attributes.
I would like to see this implemented, as it involves the least amount of disruption to our existing practices. Indeed, when I first read the documentation of the change, I thought this was in fact how the RIPE-NCC had planned to implement it, but I a closer reading when experience seemed to show otherwise proved me wrong. There is one minor drawback with it, which I feel I could live with (as I don't have any MD5 hashs that I know of to worry about). The change would make it possible to identify mntner objects that have weak MD5 protection, by excluding any that show any auth: attributes. If the actual hash is not disclosed though, I think the risk is minimal for the gain. Best regards, Brian. -- Brian Boyle, Network Services Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/
participants (9)
-
Anders Mundt Due -
Brian Boyle -
Chris -
Denis Walker -
Hank Nussbacher -
Havard Eidnes -
Randy Bush -
Sascha Lenz -
Shane Kerr