- db-wg - mailman.ripe.net

FW: FW: FW: [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
by Potapov Vladislav 05 Oct '06

05 Oct '06

Hi! I don't understand WHAT IT'S PROVES? Or you decided to say something only to be shown? -----Original Message----- From: db-wg-admin(a)ripe.net [mailto:db-wg-admin@ripe.net] On Behalf Of Max Tulyev Sent: Thursday, October 05, 2006 2:16 PM To: db-wg(a)ripe.net Subject: Re: FW: FW: [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database Hi! Come on, begin your education career from your FSB (ex-KGB if somebody don't know) colleagues: inetnum: 213.24.76.0 - 213.24.77.255 netname: RT-CLNT-FSB-RF descr: Federal Security Service of Russian Federation descr: 3/6 Lubyansky Proezd Moscow 103045 country: RU admin-c: DIP2-RIPE admin-c: ANH8-RIPE tech-c: ANH8-RIPE tech-c: DIP2-RIPE status: ASSIGNED PA mnt-by: AS8342-MNT source: RIPE # Filtered person: Dmitry Pravikov address: FSB RF address: 3/6 Lubyansky Proezd Moscow 103045 remarks: phone: +7 095 2248374 phone: +7 495 2248374 remarks: fax-no: +7 095 2244441 fax-no: +7 495 2244441 e-mail: pravikov(a)fsb.ru nic-hdl: DIP2-RIPE source: RIPE # Filtered remarks: modified for Russian phone area changes person: Alexander Holushco address: FSB RF address: 3/6 Lubyansky Proezd Moscow 103045 remarks: phone: +7 095 2244441 phone: +7 495 2244441 remarks: fax-no: +7 095 2244441 fax-no: +7 495 2244441 e-mail: root(a)fsb.ru nic-hdl: ANH8-RIPE source: RIPE # Filtered remarks: modified for Russian phone area changes % Information related to '213.24.0.0/16AS8342' route: 213.24.0.0/16 descr: RTCOMM-RU origin: AS8342 mnt-by: AS8342-MNT source: RIPE # Filtered As we can see - there is *NO* mntner at all at *-c: objects! ;-) Potapov Vladislav wrote: > Hi, > > >> From: Gert Doering [mailto:gert@space.net] >> Changing from CRYPT-PW to MD5-PW doesn't incur any >> operational changes, and doesn't require key management and >> crypto of any sort, but *will* improve security. >> > No "operational changes"? Let's look at the plan to get an image that > it's not so "problemless". I don't speak about RIPE resources which > should support this change. About security: there was several > opponents of your view already. I'm adding myself to them. > > >> From: Gert Doering [mailto:gert@space.net] >> Security issues in the IRR DB impact all of us (like "fake objects, >> use that to leverage a routing attack"). >> > Let's not say fairy tales about that. I have asked about REAL LIFE > problems with the scheme. Nobody has answered. As for security > issues... I think the better way to do this things is to educate > people, convince them to have better way of security. Up to now it is > only "small group words" and 3500 usages... > > I'm against the proposal. > > Vladislav Potapov > Ru.iiat > > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

2 1

FW: FW: FW: FW: [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
by Potapov Vladislav 05 Oct '06

05 Oct '06

Hi, ---- From: db-wg-admin(a)ripe.net [mailto:db-wg-admin@ripe.net] On Behalf Of Max Tulyev If to be seriously, I'm showing until weak schemes will be exist, people (even so serious) *WILL* use it. Education will *NOT* helps to solve the problem (so, try ;) ). ---- Then it's better to start banning people who do not agree with you? It's much more simplier than discuss, educate... ---- From: db-wg-admin(a)ripe.net [mailto:db-wg-admin@ripe.net] On Behalf Of Max Tulyev I agree better is set off ANY password authorization. We can do it at least step-by-step, but leave it alone is the worst thing we can do. ---- I don't think that the matter even worst speaking about, because still nobody has answered that there has been any problem with existing schemes even for no-maintainer objects (it's one more way to ignore your attempts to strengten maintainer object). So "the worst thing we can do" is only words. The information in the DB is not accurate, representative or hard tied to operational issues, so the world will be there if it disappears completely (maybe slightly annoying for some players, not more). Potapov Vladislav Ru.iiat

2 1

FW: [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
by Potapov Vladislav 05 Oct '06

05 Oct '06

Hi, -Hank >I think a number of people have pointed out why they wish to deprecate crypt-pw. No, I'm not convinced. And a number of people - only Gert Doering? The point of view they propagate - it should increase security (in reality - not). But, we all know: false sense of security is worse than knowledge of a problem. -Hank >To answer your latest points - data in the DB should be accurate and it does show who is allowed or not allowed to use a range of IPs, and if the data does 'disappear' as you say, it will have operational impact on a number of ISPs that build their access lists from the data in the RIPE-DB. "Should be" != "is" And to now this inaccuracy has NO operational impact on nobody. -Hank >It would appear that you might be enjoying the ability to abuse certain RIPE objects with weak security and by deprecating crypt-pw we will be impacting your playground. Hank, I think it is very cheap accusation at first hand; you are not eligible to accuse me of something - the second; it (abusing) hasn't happened before to speak about it - the third. Speaking your way I can think that RIPE doesn't know where to put money and want us to allow spend them on the projects not well-thinked and useles. Please be more constructive! Let's not allow to go to personal accusation. Vladislav Potapov Ru.iiat

5 4

Re: FW: FW: FW: FW: [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
by Hank Nussbacher 05 Oct '06

05 Oct '06

At 03:49 PM 05-10-06 +0400, Potapov Vladislav wrote: >I don't think that the matter even worst speaking about, because still >nobody has answered that there has been any problem with existing >schemes even for no-maintainer objects (it's one more way to ignore your >attempts to strengten maintainer object). So "the worst thing we can do" >is only words. The information in the DB is not accurate, representative >or hard tied to operational issues, so the world will be there if it >disappears completely (maybe slightly annoying for some players, not >more). I think a number of people have pointed out why they wish to deprecate crypt-pw. To answer your latest points - data in the DB should be accurate and it does show who is allowed or not allowed to use a range of IPs, and if the data does 'disappear' as you say, it will have operational impact on a number of ISPs that build their access lists from the data in the RIPE-DB. It would appear that you might be enjoying the ability to abuse certain RIPE objects with weak security and by deprecating crypt-pw we will be impacting your playground. -Hank >Potapov Vladislav >Ru.iiat

1 0

FW: FW: FW: [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
by Potapov Vladislav 05 Oct '06

05 Oct '06

Hi, On Thu, Oct 05, 2006 at 02:21:53PM +0400, Potapov Vladislav wrote: > The mail will still contain a "password: <something>" block, just the > way this password is hashed in the maintainer object is > different." > > Then it is NOT improve security much. It does. It takes away the attack angle of breaking CRYPT-PW hash. You are not read to the end again. "In security ALL parts are essential." You lock only one part of the "security" > Using your allegory: Let's put > huge lock on our cardboard door? In security ALL parts are essential. > BEFORE I can use "the day-to-day" operation I should change CRYPT-PW > to MD5-PW. And PERSONALLY I don't need the enhanced in some way but > weak in the other "security". As our members tell us that "crypto is hard!!!!" we can not enforce PGP (which would be a big step) - so security is increased in small steps. And you decided to go against "our members"? Maybe it is useful to tell them back? To educate? To convince BEFORE proposing? Maybe then all members (without changes) will put the most secure algorithms to their data? In other way your proposal will be ... authoritarian. And not from real life... Vladislav Potapov Ru.iiat

1 0

RE: [db-wg] Re: [enum-wg] Proposal for new org-type
by Antoin Verschuren 05 Oct '06

05 Oct '06

Per Heldal wrote: > On Wed, 2006-10-04 at 09:47 +0200, Antoin Verschuren wrote: > [snip] >> I can see a reason for the term "REGISTRY" if RIPE intends to expand >> heir services to more than IP network services, and doesn't feel to >> create a long list of different marketing terms for different >> organisations. I work for a ccTLD registry that is not an LIR, and >> even though that is a clear Internet registry function like IANA, >> RIR or LIR, RIPE currently does not supply a service for that >> function that requires an entry in the DB. >> >> Conclusion: >> I can live with ENUM-REGISTRY, REGISTRY, OTHER or no org-type at all. >> I cannot live with the org-type NON-REGISTRY. >> >> My prefference would be the ENUM-REGISTRY org-type. > > > This proposal is taking things out of context. The word REGISTRY in > RIPE-terms means an IP-address registry. Nothing more, nothing less. > That your organisation is categorised as NON-REGISTRY by RIPE doesn't > mean that RIPE does not acknowledge your role as a registry in some > other context, just that you're not an ip-addr registry. Should the > database contain exceptions for all kinds of registries which happen > to deal with something else than ip-addresses? That's why we changed the proposal to change the NON-REGISTRY into OTHER. Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

2 1

FW: FW: [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
by Potapov Vladislav 05 Oct '06

05 Oct '06

Hi, "> No "operational changes"? In the day-to-day operation ("sending in mails to change objects to the RIPE DB") going from CRYPT-PW to MD5-PW *will* *not* *change* *anything*. The mail will still contain a "password: <something>" block, just the way this password is hashed in the maintainer object is different." Then it is NOT improve security much. Using your allegory: Let's put huge lock on our cardboard door? In security ALL parts are essential. BEFORE I can use "the day-to-day" operation I should change CRYPT-PW to MD5-PW. And PERSONALLY I don't need the enhanced in some way but weak in the other "security". "> Let's look at the plan to get an image that it's not so "problemless". So where exactly *do* you see "problems"?" It's simple: the big amount of people and resources involved. "In your mail you speak about "crypto" - which is NOT involved here (except hashing the password) - this proposal is not forcing anybody to go to PGP, just to a different password storing scheme." It's not the only point I spoke about. Please reread once more. Please get a reality check on what is proposed, and what is proposed as replacement. It was my idea initially. I do not see much sense in the proposal, because you can use "better security" without ANY CHANGES AT ALL. *Good* security is fixing problems *before* they happen. Like "lock your front door when you leave your house, even if you have never been burglared yet". If you speak about your home for $1000000 - it's true. And if we speak about cabin for $10? How much sense is a lock for $1000 then? Vladislav Potapov Ru.iiat

2 1

FW: FW: [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
by Potapov Vladislav 05 Oct '06

05 Oct '06

Hi, > From: Gert Doering [mailto:gert@space.net] > Changing from CRYPT-PW to MD5-PW doesn't incur any > operational changes, and doesn't require key management and > crypto of any sort, but *will* improve security. No "operational changes"? Let's look at the plan to get an image that it's not so "problemless". I don't speak about RIPE resources which should support this change. About security: there was several opponents of your view already. I'm adding myself to them. > From: Gert Doering [mailto:gert@space.net] > Security issues in the IRR DB impact all of us (like "fake objects, > use that to leverage a routing attack"). Let's not say fairy tales about that. I have asked about REAL LIFE problems with the scheme. Nobody has answered. As for security issues... I think the better way to do this things is to educate people, convince them to have better way of security. Up to now it is only "small group words" and 3500 usages... I'm against the proposal. Vladislav Potapov Ru.iiat

2 1

RE: [db-wg] Re: [enum-wg] Proposal for new org-type
by Antoin Verschuren 05 Oct '06

05 Oct '06

leo vegoda wrote: > Do people find org-type values like IANA, RIR, LIR and so on useful? > If not, maybe we just need two values: REGISTRY for IANA, RIRs, LIRs, > TLDs and Tier 1 ENUM operators and NON-REGISTRY for everyone else. > However, if people really find the hierarchical distinctions in the > current org-type values useful, maybe we need some additional > granularity for the different kinds of domain registries? > > If the extra granularity is useful, perhaps we need to allow > organisations to have multiple org-type values? That's probably > preferable to having multiple objects for a single organisation. It depends on what is is supposed to be used for in the DB. If is is needed to distinguish types of organisations when making queries, the types makes sense. But if it's only there to give a label and it is never used, it doesn't. I wouldn't mind changing the "NON-REGISTRY" into "OTHER", like I now have to apply for a RIPE meeting. But on the other hand, if RIPE wants to use it as a differentiation of their customers, and this would be expressed in the RIPE DB, I think ENUM-REGISTRY would be appropriate, and I would also find it logical I can register at a RIPE meeting as "ENUM-REGISTRY". It's then just a customer type. I can see a reason for the term "REGISTRY" if RIPE intends to expand heir services to more than IP network services, and doesn't feel to create a long list of different marketing terms for different organisations. I work for a ccTLD registry that is not an LIR, and even though that is a clear Internet registry function like IANA, RIR or LIR, RIPE currently does not supply a service for that function that requires an entry in the DB. Conclusion: I can live with ENUM-REGISTRY, REGISTRY, OTHER or no org-type at all. I cannot live with the org-type NON-REGISTRY. My prefference would be the ENUM-REGISTRY org-type. Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

4 3

Re: FW: [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
by Gert Doering 05 Oct '06

05 Oct '06

Hi, (I'm adding db-wg(a)ripe.net back into the CC: list) On Thu, Oct 05, 2006 at 01:50:09PM +0400, Potapov Vladislav wrote: > > From: Gert Doering [mailto:gert@space.net] > > Changing from CRYPT-PW to MD5-PW doesn't incur any > > operational changes, and doesn't require key management and > > crypto of any sort, but *will* improve security. > No "operational changes"? In the day-to-day operation ("sending in mails to change objects to the RIPE DB") going from CRYPT-PW to MD5-PW *will* *not* *change* *anything*. The mail will still contain a "password: <something>" block, just the way this password is hashed in the maintainer object is different. > Let's look at the plan to get an image that it's not so "problemless". So where exactly *do* you see "problems"? In your mail you speak about "crypto" - which is NOT involved here (except hashing the password) - this proposal is not forcing anybody to go to PGP, just to a different password storing scheme. > I don't speak about RIPE resources which > should support this change. > About security: there was several opponents of your view already. I'm > adding myself to them. Please get a reality check on what is proposed, and what is proposed as replacement. > > From: Gert Doering [mailto:gert@space.net] > > Security issues in the IRR DB impact all of us (like "fake objects, > > use that to leverage a routing attack"). > Let's not say fairy tales about that. I have asked about REAL LIFE > problems with the scheme. Nobody has answered. *Good* security is fixing problems *before* they happen. Like "lock your front door when you leave your house, even if you have never been burglared yet". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 98999 SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

1 0