- db-wg - mailman.ripe.net

RIPE whoisd re-implementation: RIP-0.3.1beta1 software snapshot
by RIPE Database Administration 27 Jun '00

27 Jun '00

Dear All, This mail is to notify you of the further advancements in the development of the new implementation of the RIPE Database software. Today, we have freezed the source code into a new snapshot. This is mostly a bugfix snapshot. A considerable change, however, has been made in the installation procedure, i.e. the Makefile structure. It is now easier to compile and run the software. You can download this last snapshot at the following URL: ftp://ftp.ripe.net/ripe/dbase/reimp/RIP-0.3.1beta1.tar.gz You can also test the functionality of this snapshot of the RIP whois server in 2 ways: - By querying host reimp.ripe.net at port 43; you will find there a Near-Real-Time Mirror of the RIPE Database. - By using RIP Test Database. You can send test updates to this database at the address <rip-test(a)ripe.net>, and you can query this database at reimp.ripe.net port 4343. We would be very pleased if you could test the new implementation in both ways, and let us know your opinions. This release also includes a "test" bug, which can be spotted by sending a query satisfying certain conditions to the server and checking the results, which will clearly appear to be wrong. We challenge you to find this bug. The first one to catch it will be granted a wonderful prize! :-) Please send your comments and bug reports to the <db-beta(a)ripe.net> mailing list. To subscribe to this list, send a message to <majordomo(a)ripe.net> with the line: subscribe db-beta in the body of your letter. This is a moderated mailing list, so some delays in subscription are possible. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Filippo Portera ____________________________ RIPE Database Administration.

1 0

RE: Deletion of German domains
by Shaun O'keefe 27 Jun '00

27 Jun '00

I think you should move the domains over to DENIC but still keep them on the RIPE server untill everything is up and running fine. Shaun O'keefe, Assistant Network Administrator CITEL Technologies Ltd., http://www.citel.com/<?xml:namespace prefix = o /> shaun.okeefe(a)citel.com +44 (115) 940 5444 -----Original Message----- From: mike.norris(a)heanet.ie [ mailto:mike.norris@heanet.ie <mailto:mike.norris@heanet.ie> ] Sent: Tuesday, June 27, 2000 3:21 PM To: 'RIPE Database Administration'; db-wg(a)ripe.net; lir-wg(a)ripe.net Subject: RE: Deletion of German domains > According to the agreement between RIPE NCC and DENIC we plan Has this agreement been published? > to delete German (.de) domain objects from RIPE whois database > on June 28th. From then on, information about German domains will > be available from DENIC's whois server, whois.nic.de. While speed and efficiency are to be commended, this is rather short notice, isn't it? From the mail on 8th June, I understood that DENIC would need between one and two months after moving the domain objects before the associated person objects could be moved. Regards. Mike

1 0

Antwort: Deletion of German domains
by Jörg Bauer/Denic 27 Jun '00

27 Jun '00

On 27.06.00 11:33 RIPE Database Administration <ripe-dbm(a)ripe.net> wrote: > > > Dear Colleagues, > > According to the agreement between RIPE NCC and DENIC we plan > to delete German (.de) domain objects from RIPE whois database > on June 28th. From then on, information about German domains will > be available from DENIC's whois server, whois.nic.de. nearly correct ;-) The server name is whois.denic.de -- ----------------------------------+------------------------------------------- Joerg Bauer | eMail : Joerg.Bauer(a)denic.de DENIC eG | Fon : +49 69 272 35 180 Wiesenhuettenplatz 26 | Fax : +49 69 27235 235 D-60329 Frankfurt | ----------------------------------+-------------------------------------------

1 0

Deletion of German domains
by RIPE Database Administration 27 Jun '00

27 Jun '00

Dear Colleagues, According to the agreement between RIPE NCC and DENIC we plan to delete German (.de) domain objects from RIPE whois database on June 28th. From then on, information about German domains will be available from DENIC's whois server, whois.nic.de. Please note that you may experience some delays in processing your updates on June 28-29. We are sorry about any inconvenience this may cause. If you have any more questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. We are sorry about any inconvenience this may cause. Regards, Engin Gunduz ____________________________ RIPE Database Administration.

1 0

Flaw in PGP 5.0 key auto-generation
by RIPE Database Administration 16 Jun '00

16 Jun '00

Dear Colleagues, We are forwarding a warning about a flaw in PGP 5.0 key auto-generation. Please note that the problem appears _only_ when one auto-generates the key (using /dev/random device). If you have any questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Engin Gunduz ____________________________ RIPE Database Administration. >CERT Advisory CA-2000-09 Flaw in PGP 5.0 Key Generation > > Original release date: May 30, 2000 > Last Revised: -- > Source: CERT/CC > > A complete revision history is at the end of this file. > >Systems Affected > > * UNIX systems having a /dev/random device running any version of > PGP 5.0, including U.S. Commercial, U.S. Freeware, and > International versions > * Keys created non-interactively on such a system > * Documents encrypted with such a key > * Signatures generated with such a key > >Overview > > Under certain circumstances, PGP v5.0 generates keys that are not > sufficiently random, which may allow an attacker to predict keys and, > hence, recover information encrypted with that key. > >I. Description > > In order to generate cryptographically secure keys, PGP (and other > products) need to use random numbers as part of the input to the key > generation process. Generating truly random numbers is a difficult > problem. PGP has traditionally solved that problem by prompting the > user to type some random characters or to move the mouse in a random > manner, measuring the time between keystrokes and using this as a > source of random data. Additionally, PGP uses a file (usually called > randseed.bin) as a source of randomness. However, PGP also provides > the ability to generate keys non-interactively (useful, for example, > if you need to generate a large number of keys simultaneously or > provide a script to generate a key). When generating keys > non-interactively, PGP needs a source of random numbers; on some > systems PGP v5.0 uses the /dev/random device to provide the required > random numbers. > > PGP v5.0, including U.S. Commercial, U.S. Freeware, and International > versions, contains a flaw in reading the information provided by > /dev/random. This is not a flaw in /dev/random but instead is the > result of a flaw in how PGP processes the information returned from > /dev/random. Thus, when a key is generated non-interactively using a > command such as > > pgpk -g <DSS or RSA> <key-length> <user-id> <timeout> <pass-phrase> > > it does not contain sufficient randomness to prevent an attacker from > guessing the key. If such a command were issued on a system with no > available randseed.bin file, then the resulting key may be > predictable. > > This problem was discovered and analyzed by Germano Caronni > <gec(a)acm.org>, and verified by Thomas Roessler <roessler(a)guug.de> and > Marcel Waldvogel <mwa(a)arl.wustl.edu>. A copy of their analysis can be > found at > > http://www.securityfocus.com/templates/ > archive.pike?list=1&msg=20000523141323.A28431(a)olymp.org > >II. Impact > > Keys produced non-interactively with PGP v5.0 on a system with > a /dev/random device may be predictable, especially those > produced in an environment without a pre-existing randseed.bin > file. > > Documents encrypted with a vulnerable key may recoverable by an > attacker. Additionally, an attacker may be able to forge a > digital signature corresponding to a vulnerable key. > > Signatures produced using a vulnerable key, including > signatures in certificates, may be untrustworthy. > >III. Solution > > If your PGP key was generated non-interactively using any > version of PGP v5.0 on a system with a /dev/random device, you > may wish to revoke it. > > Documents encrypted with a predictable key may need to be > re-encrypted with a non-vulnerable key, if your particular > circumstances warrant it; that is, if the information still > needs to be encrypted. > > You may need to resign documents signed with a vulnerable key > if your circumstances warrant it. > >Appendix A Vendor Information > >Network Associates > > Network Associates Security Advisory > Date: May 30, 2000 > Author: PGP Engineering > Background: > > A security issue has been discovered in the following PGP > products: > > PGP 5.0 for Linux, US Commercial and Freeware editions > > PGP 5.0 for Linux, Source code book (basis for PGP 5.0i for Linux) > > The following PGP products are NOT affected by this issue: > > + PGP 1.x products > + PGP 2.x products > + PGP 4.x products > + All other PGP 5.x products > + PGP 6.x products > + PGP 7.x products > > Synopsis: > > During a recent review of our published PGP 5.0 for Linux > source code, researchers discovered that under specific, rare > circumstances PGP 5.0 for Linux will generate weak, predictable > public/private keypairs. These keys can only be created under > the following circumstances: > > + Keys are generated using PGP's command line option for > unattended batch key generation, with no user interaction for > entropy (random data) collection > + No keys were generated interactively on this system > previously (e.g., a PGP random seed file is not present on > this system prior to unattended batch key generation) > + PGP is able to access the UNIX /dev/random service to gather > entropy during unattended batch key generation > > PGP 5.0 for Linux does not process the data read from > /dev/random appropriately, and therefore does not gather enough > entropy required to generate strong public/private keypairs. > This issue affects both RSA and Diffie-Hellman public/private > keypairs, regardless of keysize. Network Associates has > verified that this issue does not exist in any other version of > PGP. > > Solution: > > Users who generated keys in the manner described above are > strongly urged to do the following: > > + Revoke and no longer use keys suspected to have this problem > + Generate new public/private keypairs with entropy collected > from users' typing and/or mouse movements > + Re-encrypt any data with the newly generated keypairs that is > currently encrypted with keys suspected to have this problem > + Re-sign any data with the newly generated keypairs, if > required > > Users are also urged to upgrade to the latest releases of PGP, > as PGP 5.0 products have not been officially supported by > Network Associates since early 1999, or distributed by Network > Associates since June 1998. > > Additional Information: > > US commercial and freeware versions of PGP 5.0 for Linux were > released in September 1997 by PGP, Inc., a company founded by > Phil Zimmermann. Source code for the PGP 5.0 product family was > published in September 1997. PGP, Inc. was acquired by Network > Associates in December 1997. > > Acknowledgements: > > PGP appreciates the efforts of Germano Caronni, Thomas Roessler > and Marcel Waldvogel in identifying this issue and bringing it > to our attention. > > A pgp signed version of this statement is also available at > > http://www.cert.org/advisories/CA-2000-09/pgp.asc > __________________________________________________________ > > The CERT Coordination Center thanks Germano Caronni, Thomas > Roessler, and Marcel Waldvogel for initially discovering and > reporting this vulnerability, and for their help in developing > this advisory. Additionally we thank Brett Thomas for his > insights. > __________________________________________________________ > > Shawn Hernan was the primary author of this document. > _______________________________________________________________ > > This document is available from: > http://www.cert.org/advisories/CA-2000-09.html > _______________________________________________________________ > >CERT/CC Contact Information > > Email: cert(a)cert.org > Phone: +1 412-268-7090 (24-hour hotline) > Fax: +1 412-268-6989 > Postal address: > CERT Coordination Center > Software Engineering Institute > Carnegie Mellon University > Pittsburgh PA 15213-3890 > U.S.A. > > CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / > EDT(GMT-4) Monday through Friday; they are on call for > emergencies during other hours, on U.S. holidays, and on > weekends. > >Using encryption > > We strongly urge you to encrypt sensitive information sent by > email. Our public PGP key is available from > > http://www.cert.org/CERT_PGP.key > > If you prefer to use DES, please call the CERT hotline for more > information. > >Getting security information > > CERT publications and other security information are available > from our web site > > http://www.cert.org/ > > To be added to our mailing list for advisories and bulletins, > send email to cert-advisory-request(a)cert.org and include > SUBSCRIBE your-email-address in the subject of your message. > > * "CERT" and "CERT Coordination Center" are registered in the > U.S. Patent and Trademark Office. > _______________________________________________________________ > > NO WARRANTY > Any material furnished by Carnegie Mellon University and the > Software Engineering Institute is furnished on an "as is" > basis. Carnegie Mellon University makes no warranties of any > kind, either expressed or implied as to any matter including, > but not limited to, warranty of fitness for a particular > purpose or merchantability, exclusivity or results obtained > from use of the material. Carnegie Mellon University does not > make any warranty of any kind with respect to freedom from > patent, trademark, or copyright infringement. > __________________________________________________________ > > Conditions for use, disclaimers, and sponsorship information > > Copyright 2000 Carnegie Mellon University. > > Revision History > >May 30, 2000: initial release

1 0

First steps in moving *.de domain objects
by Andrei Robachevsky 08 Jun '00

08 Jun '00

Dear Colleagues, As part of the process of moving *.de domains from the RIPE Database today, 8 July, we started updating unmaintained person objects referenced from German domain objects. Currently there are about 100,000 such objects in the RIPE database and all of them will be protected by DENIC-P maintainer. The Database performance should not be affected. This step is essential because the setup of DENIC database is planned to be done in two phases: first moving domain objects and then moving/copying person ones. The time needed between the two phases is 1-2 months as estimated by DENIC. In such circumstances after the first phase is completed person objects referenced only from *.de domains may be occasionally deleted if not protected by maintainer. Best regards, Andrei Robachevsky Database Group Manager RIPE NCC

1 0

Top 100 Maintainers List 20000605
by RIPE Database Administration 05 Jun '00

05 Jun '00

1 0

Top 100 Maintainers List 20000524
by RIPE Database Administration 24 May '00

24 May '00

1 0

Delay in processing updates
by RIPE Database Administration 24 May '00

24 May '00

Dear Colleagues, We have currenly a larger update queue than usual. We expect that updates in the queue will be processed in 4-5 hours. If you have not yet received an acknowledgement to your updates, there is no need to send them again. All updates received by auto-dbm(a)ripe.net have been queued. We are sorry about the inconvenience. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Engin Gunduz ____________________________ RIPE Database Administration.

1 0

RIPE Database working normally again.
by RIPE Database Administration 18 May '00

18 May '00

Dear Colleagues, Thank you for your patience. The RIPE Database is working normally again. Updates are being processed and queries are being answered by the primary server. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Daniele Arena ------------- RIPE NCC

1 0