Geolocation data prototype in the RIPE Database
Dear colleagues, At the RIPE 62 Meeting in Amsterdam the RIPE NCC Database Group was asked to investigate handling geolocation data in the RIPE Database. We now have a proof of concept prototype for discussion by the community. Based on input from a number of community sources and the subsequent presentation at RIPE 62, this prototype has two new optional attributes for storing geolocation data and language details. We have written an article about the design approach on RIPE Labs https://labs.ripe.net/Members/denis/geolocation-prototype-for-ripe-database This prototype references a sand-boxed TEST Database and does not have any pre-loaded geolocation or language data. But you can create your own data to see how easy it is to manage this new, optional information. We also have a prototype Geolocation Finder tool to search for this data. Another article on RIPE Labs shows how to create the new optional attributes and use the Geolocation Finder tool to search for this data. No changes in this sand-boxed TEST Database will affect the production RIPE or TEST Database services. The article is available at: https://labs.ripe.net/Members/denis/example-usage-of-ripe-database-geolocati... We invite comments or feedback on this design and suggestions for how to move forward if it is seen as a useful addition to the RIPE Database by the community. Regards Denis Walker Business Analyst RIPE NCC Database Group
Hi. I was one of the persons really against this at the RIPE 62 and I still am. How can I as a LIR avoid being forced by my customers to modify this data? How can the end user easily modify this themselves without the LIR being involved at all? What if the country says UK in the inetnum but the geoloc data is somewhere in France? What if Geoloc data providers used by content providers starts using the geoloc data in the inetnum. Can it not be manipulated then to allow content to be seen outside laws and regulation? I certainly don't want to be pressured from content providers to remove manipulated geoloc data. I just don't think RIPE dB is the place to solve the issues for content providers etc. Rgds Patrick Arkley Verizon Europe -----Original Message----- From: db-wg-bounces@ripe.net [mailto:db-wg-bounces@ripe.net] On Behalf Of Denis Walker Sent: den 5 oktober 2011 15:29 To: Database WG Subject: [db-wg] Geolocation data prototype in the RIPE Database Dear colleagues, At the RIPE 62 Meeting in Amsterdam the RIPE NCC Database Group was asked to investigate handling geolocation data in the RIPE Database. We now have a proof of concept prototype for discussion by the community. Based on input from a number of community sources and the subsequent presentation at RIPE 62, this prototype has two new optional attributes for storing geolocation data and language details. We have written an article about the design approach on RIPE Labs https://labs.ripe.net/Members/denis/geolocation-prototype-for-ripe-datab ase This prototype references a sand-boxed TEST Database and does not have any pre-loaded geolocation or language data. But you can create your own data to see how easy it is to manage this new, optional information. We also have a prototype Geolocation Finder tool to search for this data. Another article on RIPE Labs shows how to create the new optional attributes and use the Geolocation Finder tool to search for this data. No changes in this sand-boxed TEST Database will affect the production RIPE or TEST Database services. The article is available at: https://labs.ripe.net/Members/denis/example-usage-of-ripe-database-geolo cation-prototype We invite comments or feedback on this design and suggestions for how to move forward if it is seen as a useful addition to the RIPE Database by the community. Regards Denis Walker Business Analyst RIPE NCC Database Group Verizon Sweden AB - registrerat i Sverige med organisationsnummer 556489-1009- huvudkontorets adress: Armegatan 38, Box 4127, 171 04 Solna, Sverige
On 10/05/11 19:33, Arkley, Patrick wrote:
How can I as a LIR avoid being forced by my customers to modify this data? [...] I certainly don't want to be pressured from content providers to remove manipulated geoloc data.
There are other aspects as well. There are for sure lots of people out there who do NOT want their IP address geolocated. And then there are different privacy regulation in every country which have to be observed. Also depending on the internal routing of the IP address possessor, the real location can vary heavily and the whole network is not necessarily used completely at the same location. In the end you'd have to attach a current location to every single address ... If anybody should submit the current location it is the end user alone. Cheers Hendrik -- Hendrik Voelker Server & Services Management EMEA Server Operations Verizon Deutschland GmbH Sebrathweg 20 D-44149 Dortmund GERMANY http://www.verizonbusiness.com/de/ tel +49-231-972-1565 fax +49-231-972-2587 PubKey 1024D/92479A5D EC1B 76F2 D69D 11C6 2611 5CD1 5269 9351 9247 9A5D Verizon Deutschland GmbH - Sebrathweg 20, 44149 Dortmund, Germany - Amtsgericht Dortmund, HRB 14952 - Geschäftsführer: Detlef Eppig - Vorsitzender des Aufsichtsrats: Dominique Gaillard
06.10.2011 13:20, Hendrik T. Voelker пишет:
There are other aspects as well. There are for sure lots of people out there who do NOT want their IP address geolocated. And then there are different privacy regulation in every country which have to be observed.
Also depending on the internal routing of the IP address possessor, the real location can vary heavily and the whole network is not necessarily used completely at the same location. In the end you'd have to attach a current location to every single address ...
If anybody should submit the current location it is the end user alone. It's all true only in case of publishing precise location - up to meters (in form of coordinates, of cause). But no one insist on such accuracy - you can give a rough coordinates with only accuracy up to street or even city.
-- With best regards, Dennis Yusupoff, network engineer of Smart-Telecom ISP Russia, Saint-Petersburg
On 10/07/11 07:01, Dennis Yusupoff wrote:
06.10.2011 13:20, Hendrik T. Voelker пишет:
There are other aspects as well. There are for sure lots of people out there who do NOT want their IP address geolocated. And then there are different privacy regulation in every country which have to be observed.
Also depending on the internal routing of the IP address possessor, the real location can vary heavily and the whole network is not necessarily used completely at the same location. In the end you'd have to attach a current location to every single address ...
If anybody should submit the current location it is the end user alone. It's all true only in case of publishing precise location - up to meters (in form of coordinates, of cause). But no one insist on such accuracy - you can give a rough coordinates with only accuracy up to street or even city.
We have a lot of Allocations that are split up and used in different countries and in that country in different cities. So beside that administrative nightmare this will cause it also will require a LOT of additional entries in the RIPE db. So the best accuracy of location we can give them is EMEA. And that is already implied with the addresses being allocated from the RIPE ... And I didn't even mention mobile (smart)phones yet ... The RIPE db is the wrong place for this kind of information. Cheers Hendrik -- Hendrik Voelker Server & Services Management EMEA Server Operations Verizon Deutschland GmbH Sebrathweg 20 D-44149 Dortmund GERMANY http://www.verizonbusiness.com/de/ tel +49-231-972-1565 fax +49-231-972-2587 PubKey 1024D/92479A5D EC1B 76F2 D69D 11C6 2611 5CD1 5269 9351 9247 9A5D Verizon Deutschland GmbH - Sebrathweg 20, 44149 Dortmund, Germany - Amtsgericht Dortmund, HRB 14952 - Gesch�ftsf�hrer: Detlef Eppig - Vorsitzender des Aufsichtsrats: Dominique Gaillard
07.10.2011 12:27, Hendrik T. Voelker пишет:
We have a lot of Allocations that are split up and used in different countries and in that country in different cities. So beside that administrative nightmare this will cause it also will require a LOT of additional entries in the RIPE db. So the best accuracy of location we can give them is EMEA. And that is already implied with the addresses being allocated from the RIPE ...
And I didn't even mention mobile (smart)phones yet ...
The RIPE db is the wrong place for this kind of information.
Hm...may be you're right. -- With best regards, Dennis Yusupoff, network engineer of Smart-Telecom ISP Russia, Saint-Petersburg
The RIPE db is the wrong place for this kind of information.
bingo yes, i may use a block in nebraska (or moldavia), but that does not mean all customers there wish their privacy exposed randy
07.10.2011 16:30, Randy Bush пишет:
yes, i may use a block in nebraska (or moldavia), but that does not mean all customers there wish their privacy exposed randy Actually it's VERY funny - "privacy of ip-addresses". Really LOL.
-- With best regards, Dennis Yusupoff, network engineer of Smart-Telecom ISP Russia, Saint-Petersburg
yes, i may use a block in nebraska (or moldavia), but that does not mean all customers there wish their privacy exposed randy Actually it's VERY funny - "privacy of ip-addresses". Really LOL.
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id B4A13341A2 for <maillists-archiver-wg+db@ripe.net>; Fri, 7 Oct 2011 15:57:58 +0200 (CEST) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RCAvp-00011w-Ai; Fri, 07 Oct 2011 15:57:50 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RCAvo-0001Nr-Ur; Fri, 07 Oct 2011 15:57:44 +0200 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <stolpe@resilans.se>) id 1RCAvm-0001Nb-LD for db-wg@lists.ripe.net; Fri, 07 Oct 2011 15:57:42 +0200 Received: from ns1.resilans.se ([2a01:280:1::53] helo=server.resilans.se) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <stolpe@resilans.se>) id 1RCAvh-0002t7-Gb for db-wg@ripe.net; Fri, 07 Oct 2011 15:57:42 +0200 Received: from server.resilans.se (server.resilans.se [194.14.3.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.resilans.se (Postfix) with ESMTPS id 88D101883ED; Fri, 7 Oct 2011 15:47:44 +0200 (CEST) Date: Fri, 7 Oct 2011 15:47:44 +0200 (CEST) From: Daniel Stolpe <stolpe@resilans.se> To: "Hendrik T. Voelker" <hendrik.volker@de.verizonbusiness.com> In-Reply-To: <4E8EB7FA.1080001@de.verizonbusiness.com> Message-ID: <alpine.LNX.2.00.1110071547150.6744@server.resilans.se> References: <4E8C5BA0.8080502@ripe.net> <F3C953C7AA592A4590CA50D1B2ACF5EB08D2B00A@ms-ams-e3mb01.emea.dsmain.com> <4E8D72E2.5000702@de.verizonbusiness.com> <4E8EA3D1.4020007@smartspb.net> <4E8EB7FA.1080001@de.verizonbusiness.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.4 points pts rule name description ---- ---------------------- ------------------------------------ -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: c3aeb2490f138a562ee6e8d56e76c7c5fc2d4a7412218958cb859e944157526f Cc: db-wg@ripe.net Subject: Re: [db-wg] Geolocation data prototype in the RIPE Database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/pipermail/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.4 points
no, in this case privacy of location for privacy of ip addresses see rfc 4941 randy pts rule name description ---- ---------------------- ------------------------------------ -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719fc2d4a7412218958cb859e944157526f On Fri, 7 Oct 2011, Hendrik T. Voelker wrote:
The RIPE db is the wrong place for this kind of information.
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 5A12F341A2 for <maillists-archiver-wg+db@ripe.net>; Fri, 7 Oct 2011 16:00:28 +0200 (CEST) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RCAyI-00034I-18; Fri, 07 Oct 2011 16:00:22 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RCAyH-0001Q2-Cw; Fri, 07 Oct 2011 16:00:17 +0200 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <hendrik.volker@de.verizonbusiness.com>) id 1RCA5L-0000u2-O5 for db-wg@lists.ripe.net; Fri, 07 Oct 2011 15:03:31 +0200 Received: from emr0.eu.uu.net ([195.129.12.211]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <hendrik.volker@de.verizonbusiness.com>) id 1RCA5H-0000Kl-SH for db-wg@ripe.net; Fri, 07 Oct 2011 15:03:31 +0200 Received: from imr1.eu.uu.net ([213.68.123.49]) by emr0.eu.uu.net with esmtps (TLSv1:AES256-SHA:256) (envelope-from <hendrik.volker@de.verizonbusiness.com>) id 1RCA5H-0005ie-Jp for db-wg@ripe.net; Fri, 07 Oct 2011 13:03:27 +0000 Received: from dsrs04.dtm.ops.eu.uu.net ([194.139.32.107]) by imr1.eu.uu.net with esmtp id 1RCA5H-0007T5-4l for db-wg@ripe.net; Fri, 07 Oct 2011 13:03:27 +0000 X-Virus-Check: ClamAV 0.97/13760 on imr1.eu.uu.net; Fri, 07 Oct 2011 13:03:27 +0000 Message-ID: <4E8EF89E.1070305@de.verizonbusiness.com> Date: Fri, 07 Oct 2011 13:03:26 +0000 From: "Hendrik T. Voelker" <hendrik.volker@de.verizonbusiness.com> Organization: Server and Services Management (SSM) EMEA User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; de-DE; rv:1.9.2.8) Gecko/20100804 Thunderbird/3.1.2 MIME-Version: 1.0 To: db-wg@ripe.net References: <4E8C5BA0.8080502@ripe.net> <F3C953C7AA592A4590CA50D1B2ACF5EB08D2B00A@ms-ams-e3mb01.emea.dsmain.com> <4E8D72E2.5000702@de.verizonbusiness.com> <4E8EA3D1.4020007@smartspb.net> <4E8EB7FA.1080001@de.verizonbusiness.com> <m2sjn5x9uf.wl%randy@psg.com> <4E8EF5B6.9010604@smartspb.net> In-Reply-To: <4E8EF5B6.9010604@smartspb.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points pts rule name description ---- ---------------------- ------------------------------------ -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [195.129.12.211 listed in list.dnswl.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 432f6d1ae3191166dc639007e8d08e0ddb1d56d2488c791fc38a67887bf10a33 X-Mailman-Approved-At: Fri, 07 Oct 2011 16:00:15 +0200 Subject: Re: [db-wg] Geolocation data prototype in the RIPE Database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/pipermail/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points
I totally agree! Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm pts rule name description ---- ---------------------- ------------------------------------ -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [195.129.12.211 listed in list.dnswl.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719db1d56d2488c791fc38a67887bf10a33 On 10/07/11 12:51, Dennis Yusupoff wrote:
07.10.2011 16:30, Randy Bush пишет:
yes, i may use a block in nebraska (or moldavia), but that does not mean all customers there wish their privacy exposed randy Actually it's VERY funny - "privacy of ip-addresses". Really LOL.
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 950FF341A2 for <maillists-archiver-wg+db@ripe.net>; Fri, 7 Oct 2011 17:19:49 +0200 (CEST) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RCCCy-00069z-Ie; Fri, 07 Oct 2011 17:19:39 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RCCCy-00026Q-AD; Fri, 07 Oct 2011 17:19:32 +0200 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <dyr@smartspb.net>) id 1RCCCv-00026K-GU for db-wg@lists.ripe.net; Fri, 07 Oct 2011 17:19:29 +0200 Received: from quix.smartspb.net ([217.119.16.133]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <dyr@smartspb.net>) id 1RCCCr-00069D-PY for db-wg@ripe.net; Fri, 07 Oct 2011 17:19:29 +0200 Received: from dyr.smartspb.net ([217.119.16.26] helo=[127.0.0.1]) by quix.smartspb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.61 (FreeBSD)) (envelope-from <dyr@smartspb.net>) id 1RCCD4-000J9H-VH for db-wg@ripe.net; Fri, 07 Oct 2011 19:19:39 +0400 Message-ID: <4E8F1881.9060607@smartspb.net> Date: Fri, 07 Oct 2011 19:19:29 +0400 From: Dennis Yusupoff <dyr@smartspb.net> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: db-wg@ripe.net References: <4E8C5BA0.8080502@ripe.net> <F3C953C7AA592A4590CA50D1B2ACF5EB08D2B00A@ms-ams-e3mb01.emea.dsmain.com> <4E8D72E2.5000702@de.verizonbusiness.com> <4E8EA3D1.4020007@smartspb.net> <4E8EB7FA.1080001@de.verizonbusiness.com> <m2sjn5x9uf.wl%randy@psg.com> <4E8EF5B6.9010604@smartspb.net> <4E8EF89E.1070305@de.verizonbusiness.com> In-Reply-To: <4E8EF89E.1070305@de.verizonbusiness.com> X-Enigmail-Version: 1.3.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEFFE4CA3CA01C6EFFC6FB7A8" X-Antivirus: avast! (VPS 111007-0, 07.10.2011), Outbound message X-Antivirus-Status: Clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.4 points pts rule name description ---- ---------------------- ------------------------------------ -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: a80a130791b81e5f58b4aa4bfb41ad1d699a404a858d2527ca829a21700f918b Subject: Re: [db-wg] Geolocation data prototype in the RIPE Database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/pipermail/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.4 points
Actually you are mixing things up. The IP address itself is of cause not private. It is a simple technicality to ensure that data can be delivered properly. But it does normally not tell you much about it's user - beside maybe which upstream provider he uses. As soon as you start attaching a geolocation to an IP address this changes. And this change touches areas were privacy concerns are valid. The geolocation - regardless if as coordinates or a postal address - are for the user alone to reveal on his choice. Cheers Hendrik "It is no one's concern that I have nothing to hide" -- Hendrik Voelker Server & Services Management EMEA Server Operations Verizon Deutschland GmbH Sebrathweg 20 D-44149 Dortmund GERMANY http://www.verizonbusiness.com/de/ tel +49-231-972-1565 fax +49-231-972-2587 PubKey 1024D/92479A5D EC1B 76F2 D69D 11C6 2611 5CD1 5269 9351 9247 9A5D Verizon Deutschland GmbH - Sebrathweg 20, 44149 Dortmund, Germany - Amtsgericht Dortmund, HRB 14952 - Gesch�ftsf�hrer: Detlef Eppig - Vorsitzender des Aufsichtsrats: Dominique Gaillard pts rule name description ---- ---------------------- ------------------------------------ -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719699a404a858d2527ca829a21700f918b This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEFFE4CA3CA01C6EFFC6FB7A8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 07.10.2011 17:03, Hendrik T. Voelker =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
Actually you are mixing things up.
The IP address itself is of cause not private. It is a simple technicality to ensure that data can be delivered properly. But it does normally not tell you much about it's user - beside maybe which upstream provider he uses.
As soon as you start attaching a geolocation to an IP address this changes. And this change touches areas were privacy concerns are valid.=
The geolocation - regardless if as coordinates or a postal address - are for the user alone to reveal on his choice.
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id DC338341A2 for <maillists-archiver-wg+db@ripe.net>; Mon, 10 Oct 2011 09:22:31 +0200 (CEST) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RDABd-00050H-An; Mon, 10 Oct 2011 09:22:13 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RDABd-0004l5-3j; Mon, 10 Oct 2011 09:22:09 +0200 Received: from ayeaye.ipv6.ripe.net ([2001:67c:2e8:23::c100:1705] helo=ayeaye.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <alexb@ripe.net>) id 1RDABa-0004l0-Sg for db-wg@lists.ripe.net; Mon, 10 Oct 2011 09:22:06 +0200 Received: from aband.vpn.ripe.net ([193.0.21.42]) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from <alexb@ripe.net>) id 1RDABa-0002R8-DX for db-wg@ripe.net; Mon, 10 Oct 2011 09:22:06 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Alex Band <alexb@ripe.net> In-Reply-To: <4E8EF89E.1070305@de.verizonbusiness.com> Date: Mon, 10 Oct 2011 09:22:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7462C287-0C69-46DB-AC64-9EB4436B6D9E@ripe.net> References: <4E8C5BA0.8080502@ripe.net> <F3C953C7AA592A4590CA50D1B2ACF5EB08D2B00A@ms-ams-e3mb01.emea.dsmain.com> <4E8D72E2.5000702@de.verizonbusiness.com> <4E8EA3D1.4020007@smartspb.net> <4E8EB7FA.1080001@de.verizonbusiness.com> <m2sjn5x9uf.wl%randy@psg.com> <4E8EF5B6.9010604@smartspb.net> <4E8EF89E.1070305@de.verizonbusiness.com> To: db-wg@ripe.net X-Mailer: Apple Mail (2.1084) Subject: Re: [db-wg] Geolocation data prototype in the RIPE Database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/pipermail/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.6 points
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 2B2F3341A2 for <maillists-archiver-wg+db@ripe.net>; Mon, 10 Oct 2011 11:06:07 +0200 (CEST) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RDBo1-0000fX-Om; Mon, 10 Oct 2011 11:05:58 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RDBo1-0007iU-BX; Mon, 10 Oct 2011 11:05:53 +0200 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <hendrik.volker@de.verizonbusiness.com>) id 1RDBKq-0007RU-CC for db-wg@lists.ripe.net; Mon, 10 Oct 2011 10:35:44 +0200 Received: from emr1.eu.uu.net ([195.129.12.212]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <hendrik.volker@de.verizonbusiness.com>) id 1RDBKn-0007yG-TM for db-wg@ripe.net; Mon, 10 Oct 2011 10:35:44 +0200 Received: from imr1.eu.uu.net ([213.68.123.49]) by emr1.eu.uu.net with esmtps (TLSv1:AES256-SHA:256) (envelope-from <hendrik.volker@de.verizonbusiness.com>) id 1RDBKn-0003OA-Gt; Mon, 10 Oct 2011 08:35:41 +0000 Received: from dsrs04.dtm.ops.eu.uu.net ([194.139.32.107]) by imr1.eu.uu.net with esmtp id 1RDBKn-00074N-45; Mon, 10 Oct 2011 08:35:41 +0000 X-Virus-Check: ClamAV 0.97/13776 on imr1.eu.uu.net; Mon, 10 Oct 2011 08:35:41 +0000 Message-ID: <4E92AE5C.8060206@de.verizonbusiness.com> Date: Mon, 10 Oct 2011 08:35:40 +0000 From: "Hendrik T. Voelker" <hendrik.volker@de.verizonbusiness.com> Organization: Server and Services Management (SSM) EMEA User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; de-DE; rv:1.9.2.8) Gecko/20100804 Thunderbird/3.1.2 MIME-Version: 1.0 To: Alex Band <alexb@ripe.net> References: <4E8C5BA0.8080502@ripe.net> <F3C953C7AA592A4590CA50D1B2ACF5EB08D2B00A@ms-ams-e3mb01.emea.dsmain.com> <4E8D72E2.5000702@de.verizonbusiness.com> <4E8EA3D1.4020007@smartspb.net> <4E8EB7FA.1080001@de.verizonbusiness.com> <m2sjn5x9uf.wl%randy@psg.com> <4E8EF5B6.9010604@smartspb.net> <4E8EF89E.1070305@de.verizonbusiness.com> <7462C287-0C69-46DB-AC64-9EB4436B6D9E@ripe.net> In-Reply-To: <7462C287-0C69-46DB-AC64-9EB4436B6D9E@ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: / X-RIPE-Spam-Report: Spam Total Points: -0.0 points pts rule name description ---- ---------------------- ------------------------------------ -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [195.129.12.212 listed in list.dnswl.org] -0.0 BAYES_20 BODY: Bayes spam probability is 5 to 20% [score: 0.0858] X-RIPE-Signature: 432f6d1ae3191166dc639007e8d08e0dc56a4d3b8955b7c9f7085a4fd4f17321 X-Mailman-Approved-At: Mon, 10 Oct 2011 11:05:51 +0200 Cc: db-wg@ripe.net Subject: Re: [db-wg] Geolocation data prototype in the RIPE Database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/pipermail/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points
I doesn't see any difference. How can you be sure NOW that's your provider doesn't expose such kind of information by other method - for example, by DNS-names or something like that? It's kind of "security via obscurity", no more, and as you know, it's not really secure at all. --=20 With best regards, Dennis Yusupoff, network engineer of Smart-Telecom ISP Russia, Saint-Petersburg --------------enigEFFE4CA3CA01C6EFFC6FB7A8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOjxiBAAoJEBUTaqBS2NB4c9MH/jk42GzOkFqZcB/6akKoyqLk R77iTarsG1g09Y7Ku4yzQwe8qKchz7zhO51HaqFd58a9B6ynSDltacp3EIZG2JQa 4YLGg60B05cMN6eXFv0ibYyXDZcGzJOKl16K2bhXpX8zWvl5dc2LX+r2v5B1D+7j MXEziFeAlCEQmPb2W+EuCSuf9l+BKfF8J7TBYnUDN5f8m3lD4SLD4Om9uN1q2Yfw rkhtn8bwhVO+BFqZ9TY53JRpXpWLNfIIaFBmjisblA4tI5+ohkI6BYNP/RbEVOV8 vQNU1JBY3yPTSTOen3SwR2XNHO757A3xUmqEW3+yjpbgGb+ghrCnNSKtUS6DIJE= =88KW -----END PGP SIGNATURE----- --------------enigEFFE4CA3CA01C6EFFC6FB7A8-- pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.8 FRT_BIGGERMEM1 BODY: ReplaceTags: Bigger / Larger, Penis / Member -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b8351171953fd65f2c32b8848c93187f4762eae2b The simple truth is that geolocation data for IP addresses is already = available in some form, but there is no authoritative method of mapping = an IP address to a location or a language. This causes location and = language based web services to be error prone. Some of you have said = that this inaccuracy and obscurity is a good thing, but others just want = a more reliable system and reduce end user frustration and complaints. For example, IP address space which was returned to the RIPE NCC and = redistributed to another LIR is often subject to location or language = related problems for their end users: content providers present them = with the wrong language, or access to location restricted content (such = as BBC iPlayer) is blocked. For some countries such as Belgium and = Switzerland, there is no way at all to know or specify in which language = content should be presented.=20 With this in mind, what better way than to hand the power to = authoritatively specify the usage location and language of an IP address = block to its legitimate holder. We can leave it up to third parties to = create databases based on fancy data mining, but this is proven to be = problematic as illustrated earlier. The reliance on this kind of data is = only increasing, and with IPv6 in the mix data quality is certainly not = improving. I would like to emphasise that the Database department did not launch = the geolocation prototype on a whim and the usage is completely = optional. I am sure that you can come up with various examples where = entering this information in the current prototype doesn't cover a = particular use case; in fact you already have. Of course there are quite = a number of things we should add and change to the functionality before = thinking about rolling this into the production database.=20 As far as privacy goes, third parties will always attempt to geolocate = an IP address as close to the user as possible. It's up to you if you = enter anything in the RIPE Database at all and if you do, the = granularity is completely in your hands. The implementation and maintenance complexity for our larger members = will of course be higher but I doubt that should mean we don't offer it = to anyone, even if it's easy for others to enter and maintain and it = solves their problems. The current implementation is a starting point = for discussion and it would be great if we could talk about how the = prototype could be developed and evolved to make it as easy, useful and = accurate as possible for everyone interested, and alleviates the = concerns that were raised. Regards, Alex Band= pts rule name description ---- ---------------------- ------------------------------------ -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [195.129.12.212 listed in list.dnswl.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719c56a4d3b8955b7c9f7085a4fd4f17321 Good morning Alex. On 10/10/11 07:22, Alex Band wrote:
[...] This causes location and language based web services to be error prone.
Well concerning the languages: Only because my IP address is currently routes in for example France doesn't mean I want to be presented with content in French. For selecting the content language I set the proper preferences in my browser and also rely on the fact that provider of multilingual content additionally provide me with a way to select from the languages they serve. Location based services: If I intent to use a location based service I will instruct my front end device to supply the correct location (-> http://www.w3.org/2008/geolocation/).
Some of you have said that this inaccuracy and obscurity is a good thing
Yes, I was one of them. I don't like to provide information like my current geolocation unwillingly. This violates my privacy. And as privacy is protected by laws you run into trouble as the country specific regulations have to be observed. This will result in an incomplete data base, and thus you have to achieved the reliability you are aiming at. A simple way for you to find out the "German position" on this I suggest contacting the Bundesdatenschutzbeauftragten (http://www.bfdi.bund.de/Vorschaltseite_EN_node.html)
but others just want a more reliable system and reduce end user frustration and complaints.
As said before, the location will not fix the language problem ...
[...] or access to location restricted content (such as BBC iPlayer) is blocked.
This is the only situation where I can understand that a correct location is required. But in this case the country is enough. And, honestly, this is still the wrong way. A better solution would be for the enduser to provide a verifyanble token that he is either a British citizen or is currently on British territory.
For some countries such as Belgium and Switzerland, there is no way at all to know or specify in which language content should be presented.
You are correct, and here you also contradict your own arguments from above ...
With this in mind, what better way than to hand the power to authoritatively specify the usage location and language of an IP address block to its legitimate holder.
As I pointed out before in another email: The one authoritative location cannot be given on the net level but only per IP address. Also it would require a real time update mechanism and lots of technical engineering to get all the POP equipment to provide the correct location for the current location of the user of the address. In mobile environment it would be automatic triangulation of the devices ...
We can leave it up to third parties to create databases based on fancy data mining, but this is proven to be problematic as illustrated earlier.
Your suggested way is as problematic as it practically doesn't do anything else as to create just another data base based on fancy data mining, and lots of more or less reliable data provided by entities possessing a net block from the RIPE.
I would like to emphasise that the Database department did not launch the geolocation prototype on a whim and the usage is completely optional.
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id B73B3341A2 for <maillists-archiver-wg+db@ripe.net>; Mon, 10 Oct 2011 11:17:51 +0200 (CEST) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RDBzC-0008Sy-JM; Mon, 10 Oct 2011 11:17:32 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RDBzC-0007oM-1g; Mon, 10 Oct 2011 11:17:26 +0200 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <thor.kottelin@turvasana.com>) id 1RDBzA-0007oH-BT for db-wg@lists.ripe.net; Mon, 10 Oct 2011 11:17:24 +0200 Received: from auth-smtp.nebula.fi ([217.30.180.105]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <thor.kottelin@turvasana.com>) id 1RDBz8-00017A-MK for db-wg@ripe.net; Mon, 10 Oct 2011 11:17:24 +0200 Received: from turvasan047101 (a85-156-227-198.elisa-laajakaista.fi [85.156.227.198]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id p9A9GWcV015649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <db-wg@ripe.net>; Mon, 10 Oct 2011 12:16:34 +0300 From: "Thor Kottelin" <thor.kottelin@turvasana.com> To: <db-wg@ripe.net> References: <4E8C5BA0.8080502@ripe.net> <F3C953C7AA592A4590CA50D1B2ACF5EB08D2B00A@ms-ams-e3mb01.emea.dsmain.com> <4E8D72E2.5000702@de.verizonbusiness.com> <4E8EA3D1.4020007@smartspb.net> <4E8EB7FA.1080001@de.verizonbusiness.com> <m2sjn5x9uf.wl%randy@psg.com> <4E8EF5B6.9010604@smartspb.net> <4E8EF89E.1070305@de.verizonbusiness.com> <7462C287-0C69-46DB-AC64-9EB4436B6D9E@ripe.net> <4E92AE5C.8060206@de.verizonbusiness.com> In-Reply-To: <4E92AE5C.8060206@de.verizonbusiness.com> Date: Mon, 10 Oct 2011 12:16:34 +0300 Organization: Turvasana Tmi, http://turvasana.com/ Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAADs1SQBfrQFIidqBOlhIPRTCgAAAEAAAAGVvHHDbX5VInDgOJ3sujwEBAAAAAA==@turvasana.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 5 (Lowest) X-MSMail-Priority: Low X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyHK9jyUyrDk40ORyqiz8nJUZ200gAASvLQ Content-Language: fi Importance: Low X-RIPE-Spam-Level: / X-RIPE-Spam-Report: Spam Total Points: 0.1 points pts rule name description ---- ---------------------- ------------------------------------ -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [217.30.180.105 listed in list.dnswl.org] 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4714] X-RIPE-Signature: b7791e8fcc02fba56c624ecf418a5e784d886b4f32e1f38f4942c7daf20e161e Subject: Re: [db-wg] Geolocation data prototype in the RIPE Database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/pipermail/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.6 points
If the use is optional than the data base can never by authoritative, because she is incomplete. And you will never succeed in making it mandatory as this would automatically cause law suits. Cheers Hendrik -- Hendrik Voelker Server & Services Management EMEA Server Operations Verizon Deutschland GmbH Sebrathweg 20 D-44149 Dortmund GERMANY http://www.verizonbusiness.com/de/ tel +49-231-972-1565 fax +49-231-972-2587 PubKey 1024D/92479A5D EC1B 76F2 D69D 11C6 2611 5CD1 5269 9351 9247 9A5D Verizon Deutschland GmbH - Sebrathweg 20, 44149 Dortmund, Germany - Amtsgericht Dortmund, HRB 14952 - Gesch�ftsf�hrer: Detlef Eppig - Vorsitzender des Aufsichtsrats: Dominique Gaillard pts rule name description ---- ---------------------- ------------------------------------ -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [217.30.180.105 listed in list.dnswl.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b835117194d886b4f32e1f38f4942c7daf20e161e
-----Original Message----- From: db-wg-bounces@ripe.net [mailto:db-wg-bounces@ripe.net] On Behalf Of Hendrik T. Voelker Sent: Monday, October 10, 2011 11:36 AM To: Alex Band Cc: db-wg@ripe.net
On 10/10/11 07:22, Alex Band wrote:
[...] This causes location and language based web services to be error prone.
Only because my IP address is currently routes in for example France doesn't mean I want to be presented with content in French.
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id C06F1341A2 for <maillists-archiver-wg+db@ripe.net>; Mon, 10 Oct 2011 13:08:49 +0200 (CEST) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RDDih-0005NO-Cu; Mon, 10 Oct 2011 13:08:39 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RDDig-0000Mr-VE; Mon, 10 Oct 2011 13:08:30 +0200 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <mm@elabnet.de>) id 1RDDie-0000Mm-H0 for db-wg@lists.ripe.net; Mon, 10 Oct 2011 13:08:28 +0200 Received: from vhost1.elabnet.de ([81.16.179.36]) by postgirl.ripe.net with esmtp (Exim 4.72) (envelope-from <mm@elabnet.de>) id 1RDDid-0005Mb-Bs; Mon, 10 Oct 2011 13:08:28 +0200 Received: from vhost1.elabnet.de (localhost [127.0.0.1]) by vhost1.elabnet.de (Postfix) with ESMTP id E92FC6E036; Mon, 10 Oct 2011 12:58:39 +0200 (CEST) Received: from elab4vm1.elabnet.com (elab4vm1.elabnet.com [81.16.178.73]) by vhost1.elabnet.de (Postfix) with ESMTP id C15EC6E007; Mon, 10 Oct 2011 12:58:39 +0200 (CEST) Received: from [172.17.2.67] ([172.17.2.67]) by elab4vm1.elabnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Oct 2011 12:58:39 +0200 From: Michael Markstaller <mm@elabnet.de> To: "Hendrik T. Voelker" <hendrik.volker@de.verizonbusiness.com> In-Reply-To: <4E92AE5C.8060206@de.verizonbusiness.com> References: <4E8C5BA0.8080502@ripe.net> <F3C953C7AA592A4590CA50D1B2ACF5EB08D2B00A@ms-ams-e3mb01.emea.dsmain.com> <4E8D72E2.5000702@de.verizonbusiness.com> <4E8EA3D1.4020007@smartspb.net> <4E8EB7FA.1080001@de.verizonbusiness.com> <m2sjn5x9uf.wl%randy@psg.com> <4E8EF5B6.9010604@smartspb.net> <4E8EF89E.1070305@de.verizonbusiness.com> <7462C287-0C69-46DB-AC64-9EB4436B6D9E@ripe.net> <4E92AE5C.8060206@de.verizonbusiness.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ZAa/r8kPiLQ5g0tl33Jt" Date: Mon, 10 Oct 2011 12:58:38 +0200 Message-ID: <1318244318.19074.1319.camel@v1520-mm> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 X-OriginalArrivalTime: 10 Oct 2011 10:58:39.0523 (UTC) FILETIME=[912AE730:01CC873B] X-AV-Checked: ClamAV using ClamSMTP X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.5 points pts rule name description ---- ---------------------- ------------------------------------ -0.0 SPF_PASS SPF: sender matches SPF record -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid X-RIPE-Signature: b39e10ef984bac7ab916959f04ef70aeb0e69a0f63e5ecb25db756a4395216d1 Cc: db-wg@ripe.net Subject: Re: [db-wg] Geolocation data prototype in the RIPE Database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/pipermail/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.4 points
Good morning Alex. =20 On 10/10/11 07:22, Alex Band wrote:
[...] This causes location and language based web services to be error =
...or in Swiss, when in Switzerland... -- Thor Kottelin http://www.anta.net/ pts rule name description ---- ---------------------- ------------------------------------ -0.0 SPF_PASS SPF: sender matches SPF record -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719b0e69a0f63e5ecb25db756a4395216d1 --=-ZAa/r8kPiLQ5g0tl33Jt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Am Montag, den 10.10.2011, 08:35 +0000 schrieb Hendrik T. Voelker: prone.
=20 Well concerning the languages: Only because my IP address is currently ro= utes=20 in for example France doesn't mean I want to be presented with content in= =20 French. For selecting the content language I set the proper preferences i= n my=20 browser and also rely on the fact that provider of multilingual content= =20 additionally provide me with a way to select from the languages they serv= e. =20 Location based services: If I intent to use a location based service I wi= ll=20 instruct my front end device to supply the correct location (->=20 http://www.w3.org/2008/geolocation/).
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id CA43E341A2 for <maillists-archiver-wg+db@ripe.net>; Thu, 13 Oct 2011 16:43:00 +0200 (CEST) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1REMUf-0003b7-0R; Thu, 13 Oct 2011 16:42:49 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1REMUe-0005UX-P3; Thu, 13 Oct 2011 16:42:44 +0200 Received: from dodo.ipv6.ripe.net ([2001:67c:2e8:23::c100:1704] helo=dodo.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <denis@ripe.net>) id 1REMUd-0005UP-OJ; Thu, 13 Oct 2011 16:42:43 +0200 Received: from denis.vpn.ripe.net ([193.0.21.59] helo=guest138.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from <denis@ripe.net>) id 1REMUd-0002Dv-Jr; Thu, 13 Oct 2011 16:42:43 +0200 Message-ID: <4E96F8E3.9030502@ripe.net> Date: Thu, 13 Oct 2011 16:42:43 +0200 From: Denis Walker <denis@ripe.net> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: Database WG <db-wg@ripe.net>, NCC Services WG <ncc-services-wg@ripe.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [db-wg] Deployment of REST Interfaces to the RIPE Database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/pipermail/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.4 points
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id D69A5341A2 for <maillists-archiver-wg+db@ripe.net>; Mon, 17 Oct 2011 13:53:40 +0200 (CEST) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RFlkq-0007cT-Af; Mon, 17 Oct 2011 13:53:25 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RFlkq-0002BO-2Q; Mon, 17 Oct 2011 13:53:16 +0200 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <Woeber@CC.UniVie.ac.at>) id 1RFlko-0002BG-OE; Mon, 17 Oct 2011 13:53:14 +0200 Received: from grace.univie.ac.at ([2001:62a:4:25::25:115]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <Woeber@CC.UniVie.ac.at>) id 1RFlkn-0007cI-Lb; Mon, 17 Oct 2011 13:53:14 +0200 Received: from joan.univie.ac.at ([131.130.3.110] helo=joan.univie.ac.at) by grace.univie.ac.at with esmtp (Exim 4.76) (envelope-from <Woeber@CC.UniVie.ac.at>) id 1RFlkm-00073M-FR; Mon, 17 Oct 2011 13:53:12 +0200 Received: from [88.116.251.69] by joan.univie.ac.at with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from <Woeber@CC.UniVie.ac.at>) id 1RFlkm-00054F-AG; Mon, 17 Oct 2011 13:53:12 +0200 Message-ID: <4E9C1726.8070904@CC.UniVie.ac.at> Date: Mon, 17 Oct 2011 11:53:10 +0000 From: "Wilfried Woeber, UniVie/ACOnet" <Woeber@CC.UniVie.ac.at> Organization: UniVie - ACOnet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Database WG <db-wg@ripe.net> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Univie-Virus-Scan: scanned by ClamAV on joan.univie.ac.at X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.4 points pts rule name description ---- ---------------------- ------------------------------------ -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: d04a9d8b6219edc74e3d2b1de6d505acb58cea6d8679cbdbf68778de8a9623d8 Cc: RIPE NCC Meeting Role <meeting@ripe.net>, RIPE WG Chairs <wg-chairs@ripe.net> Subject: [db-wg] RIPE63 DB-WG Draft Agenda V1 X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Woeber@CC.UniVie.ac.at List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.4 points
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id CF35C341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 1 Nov 2011 12:08:44 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RLCCj-0002MX-6P; Tue, 01 Nov 2011 12:08:30 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RLCCi-0002L4-Qj; Tue, 01 Nov 2011 12:08:28 +0100 Received: from dodo.ipv6.ripe.net ([2001:67c:2e8:23::c100:1704] helo=dodo.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <denis@ripe.net>) id 1RLCCf-0002Kw-0h; Tue, 01 Nov 2011 12:08:25 +0100 Received: from denis.vpn.ripe.net ([193.0.21.59] helo=dhcp-24-118.ripemtg.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from <denis@ripe.net>) id 1RLCCe-00012z-OK; Tue, 01 Nov 2011 12:08:24 +0100 Message-ID: <4EAFD328.1060102@ripe.net> Date: Tue, 01 Nov 2011 12:08:24 +0100 From: Denis Walker <denis@ripe.net> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Database WG <db-wg@ripe.net>, NCC Services WG <ncc-services-wg@ripe.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [db-wg] New RIPE Database Online Forms X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: ---- X-RIPE-Spam-Report: Spam Total Points: -4.1 points
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 61BE8341A2 for <maillists-archiver-wg+db@ripe.net>; Fri, 4 Nov 2011 09:52:01 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RMFUv-0003Rr-GF; Fri, 04 Nov 2011 09:51:45 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RMFUv-000487-9P; Fri, 04 Nov 2011 09:51:37 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <cris.pascual.gonzalez@gmail.com>) id 1RM2eB-0004eD-08 for db-wg@lists.ripe.net; Thu, 03 Nov 2011 20:08:19 +0100 Received: from marfik.cc.upv.es ([158.42.249.9]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <cris.pascual.gonzalez@gmail.com>) id 1RM2e7-0003rZ-7M for db-wg@ripe.net; Thu, 03 Nov 2011 20:08:18 +0100 Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id pA3J8EiP017604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <db-wg@ripe.net>; Thu, 3 Nov 2011 20:08:14 +0100 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id pA3J8EVZ015885 for <db-wg@ripe.net>; Thu, 3 Nov 2011 20:08:14 +0100 Received: from JLLORET (vpn245-22.vpns.upv.es [158.42.245.22]) by smtp.upv.es (8.13.6/8.13.6) with SMTP id pA3J8CiS017779 for <db-wg@ripe.net>; Thu, 3 Nov 2011 20:08:13 +0100 Date: Thu, 3 Nov 2011 20:08:13 +0100 Message-Id: <201111031908.pA3J8CiS017779@smtp.upv.es> From: Cristina Pascual<cris.pascual.gonzalez@gmail.com> To: db-wg@ripe.net CC: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-RIPE-Spam-Level: ++ X-RIPE-Spam-Report: Spam Total Points: 2.8 points pts rule name description ---- ---------------------- ------------------------------------ 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (cris.pascual.gonzalez[at]gmail.com) -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED 0.8 SPF_NEUTRAL SPF: sender does not match SPF record (neutral) -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0032] 0.0 FROM_MISSP_DKIM From misspaced, DKIM dependable 2.5 TO_NO_BRKTS_FROM_MSSP Multiple formatting errors 0.0 FROM_MISSP_EH_MATCH From misspaced, matches envelope 0.9 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list 0.0 FROM_MISSP_URI From misspaced, has URI 0.5 FROM_MISSP_FREEMAIL From misspaced + freemail provider X-RIPE-Signature: 19be5bb48d44139a1d1061e1e2812615ad6c4eee688a8e153b99a3454e30ea2b X-Mailman-Approved-At: Fri, 04 Nov 2011 09:51:35 +0100 Subject: [db-wg] 2nd CfP: ICCGI 2012 || June 24-29, 2012 - Venice, Italy X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: / X-RIPE-Spam-Report: Spam Total Points: -0.6 points
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id 30E5E341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 8 Nov 2011 10:46:17 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RNiFZ-0007bR-5d; Tue, 08 Nov 2011 10:45:56 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RNiFY-0006gX-Vm; Tue, 08 Nov 2011 10:45:49 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <david.freedman@uk.clara.net>) id 1RNiFV-0006gS-9Q for db-wg@lists.ripe.net; Tue, 08 Nov 2011 10:45:45 +0100 Received: from staff00.mail.eu.clara.net ([2001:a88:0:fff7::68]) by postgirl.ripe.net with esmtp (Exim 4.72) (envelope-from <david.freedman@uk.clara.net>) id 1RNiFS-0005QH-Cp for db-wg@ripe.net; Tue, 08 Nov 2011 10:45:45 +0100 Received: from [195.157.10.59] (port=30454 helo=SRVGREXCAS02.claranet.local) by staff00.mail.eu.clara.net (staff00.mail.eu.clara.net [80.168.65.68]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1RNiFR-00005O-2P for db-wg@ripe.net (return-path <david.freedman@uk.clara.net>); Tue, 08 Nov 2011 09:45:41 +0000 Received: from SRVGREXMB03.claranet.local ([10.75.5.26]) by SRVGREXCAS02.claranet.local ([fe80::cd6a:3120:3174:a299%10]) with mapi id 14.01.0339.001; Tue, 8 Nov 2011 09:45:41 +0000 From: David Freedman <david.freedman@uk.clara.net> To: "db-wg@ripe.net" <db-wg@ripe.net> Thread-Topic: Displaying RegID for all resources Thread-Index: AQHMnfst78kR8ipH/EK4YsX6Xj8FvA== Date: Tue, 8 Nov 2011 09:45:41 +0000 Message-ID: <CADEAABD.65CFB%david.freedman@eu.clara.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.18.6.3] Content-Type: multipart/alternative; boundary="_000_CADEAABD65CFBdavidfreedmaneuclaranet_" MIME-Version: 1.0 X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 5aa369f352efcb7801fa06fbb6cba0ddd0a9c37165047794f1350914628f9bb1 Subject: [db-wg] Displaying RegID for all resources X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points
100% Ack! Geolocation by IP is IMHO a disease for privacy as well as in technical terms (error prone). Imagine i.e. a company with a HQ in EU and a small subsidiary in LA/US surfing over a VPN through the central proxy. There are sites out there right now where you cannot access the US-content then.. We had such cases.. A better approach would be - it's most likely unrealistic and too late though - to say the address in the RIPE-DB is only saying where the ISP lives. There's no need for a website to tell where the end-user comes from. best regards Michael Markstaller --=-ZAa/r8kPiLQ5g0tl33Jt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk6Sz94ACgkQaWRHV2kMuAK4TwCfZEZAmGw/0sB2xZcbdRfol0JH s3AAoPqpmBaw12CjQKTY4fnwYxo5S9o5 =Eq76 -----END PGP SIGNATURE----- --=-ZAa/r8kPiLQ5g0tl33Jt-- pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b835117196e88fe79df10fc9cf014fc753dbca408 [Apologies for duplicate emails] Dear colleagues, The RIPE NCC Database Group is pleased to announce the deployment of the RIPE Database RESTful Web Services API. These are REST interfaces to the RIPE Database. The latest version of the API offers full CRUD support and also new advanced methods to programmatically manipulate RIPE Database objects. These services have been available for a while as discussed on RIPE Labs. They have now been migrated to our production servers and are fully supported. Documentation can be found on RIPE Labs: https://labs.ripe.net/ripe-database/database-api/api-documentation https://labs.ripe.net/ripe-database/database-api/api-introduction https://labs.ripe.net/Members/Paul_P_/create-update-and-delete-via-the-restf... The development of these services will continue through our iterative development process. Whilst the fundamentals won't change, we will be responding to ideas, suggestions and any bug reports as we continue to develop them. For this reason we would consider them as beta releases for a while. Regards, Denis Walker Business Analyst RIPE NCC Database Group pts rule name description ---- ---------------------- ------------------------------------ -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719b58cea6d8679cbdbf68778de8a9623d8 Dear DB-WG folks, Chairpersons, "Meeting"! This is the 1st draft of an agenda for the DB-WG at RIPE63 in Vienna, during the 1st week of November 2011. For time slot allocations please refer to the most up-to-date meeting plan at http://ripe63.ripe.net/programme/meeting-plan The DB-WG Meeting is scheduled for *Thursday*, November 3rd, starting at 14:00 in the afternoon. The length of this timeslot is 90 Minutes. Please feel free to propose additional topics to be discussed! I'd also suggest that you submit your points of view regarding the topics on the proposed agenda on the mailing list, preferably before the WG meeting's start :-) Best regards, hope to see you soon in my hometown, Wilfried. ________________________________________________________________________ A. Administrative Matters . Welcome . select scribe . finalise agenda . approval of minutes from previous WG meeting(s) . review of action list B. Data Base Update (N.N., RIPE NCC) - brief update - the road ahead (core software reimplementation - discussion of impact on users, if any :-) C. Internationalisation of the Registry System - problem statement and goals - mandate to the NCC / implementation approach? D. GeoLocation Registry proposal and prototype - current status of discussion and mock-up - deployment possibilities (responsibility for entries, use,...) - continue or cancel? (--> PDP?) H. Input from other WGs and TFs Z. AOB ________________________________________________________________________ pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b835117191cb37e1f6960e98c70d5be39457d717f [Apologies for duplicate emails] Dear Colleagues, The RIPE NCC Database Group is pleased to announce further improvements to the RIPE Database online forms. The old CGIs for generating an MD5 password hash and requesting a password reset have been replaced by new online forms with a much improved workflow. https://apps.db.ripe.net/crypt/crypt.html https://apps.db.ripe.net/change-auth/ This concludes the RIPE Database Group's project to migrate old online forms and CGIs to the new database platform. We will continue to develop new tools and services on this platform to further enhance the RIPE Database experience. Regards Denis Walker Business Analyst RIPE NCC Database Group pts rule name description ---- ---------------------- ------------------------------------ 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (cris.pascual.gonzalez[at]gmail.com) -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED 0.8 SPF_NEUTRAL SPF: sender does not match SPF record (neutral) -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 FROM_MISSP_DKIM From misspaced, DKIM dependable 0.0 FROM_MISSP_EH_MATCH From misspaced, matches envelope 0.0 FROM_MISSP_URI From misspaced, has URI 0.5 FROM_MISSP_FREEMAIL From misspaced + freemail provider X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719ad6c4eee688a8e153b99a3454e30ea2b INVITATION: ================= Please, consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results to ICCGI 2012. The submission deadline is set to February 5, 2012. In addition, authors of selected papers will be invited to submit extended article versions to one of the IARIA Journals: http://www.iariajournals.org ================= ============== ICCGI 2012 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS ICCGI 2012, The Seventh International Multi-Conference on Computing in the Global Information Technology June 24-29, 2012 - Venice, Italy General page: http://www.iaria.org/conferences2012/ICCGI12.html Call for Papers: http://www.iaria.org/conferences2012/CfPICCGI12.html - regular papers - short papers (work in progress) - posters - ideas Submission page: http://www.iaria.org/conferences2012/SubmitICCGI12.html Submission deadline: February 5, 2012 Sponsored by IARIA, www.iaria.org Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Please note the Poster and Work in Progress options. The topics suggested by the conference can be discussed in term of concepts, state of the art, research, standards, implementations, running experiments, applications, and industrial case studies. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal in the following, but not limited to, topic areas. All tracks are open to both research and industry contributions, in terms of Regular papers, Posters, Work in progress, Technical/marketing/business presentations, Demos, Tutorials, and Panels. Before submission, please check and comply with the Editorial rules: http://www.iaria.org/editorialrules.html ICCGI 2012 Topics (topics and submission details: see CfP on the site) Industrial systems Control theory and systems; Fault-tolerance and reliability; Data engineering; Enterprise computing and evaluation; Electrical and electronics engineering; Economic decisions and information systems; Advanced robotics; Virtual reality systems; Industrial systems and applications; Industrial and financial systems; Industrial control electronics; Industrial IT solutions Evolutionary computation Algorithms, procedures, mechanisms and applications; Computer architecture and systems; Computational sciences; Computation in complex systems; Computer and communication systems; Computer networks; Computer science theory; Computation and computer security; Computer simulation; Digital telecommunications; Distributed and parallel computing; Computation in embedded and real-time systems; Soft computing; User-centric computation Autonomic and autonomous systems Automation and autonomous systems; Theory of Computing; Autonomic computing; Autonomic networking; Network computing; Protecting computing; Theories of agency and autonomy; Multi-agent evolution, adaptation and learning; Adjustable and self-adjustable autonomy; Pervasive systems and computation; Computing with locality principles; GRID networking and services; Pervasive computing; Cluster computing and performance; Artificial intelligence Computational linguistics; Cognitive technologies; Decision making; Evolutionary computation; Expert systems; Computational biology Bio-technologies Models and techniques for biometric technologies; Bioinformatics; Biometric security; Computer graphics and visualization; Computer vision and image processing; Computational biochemistry; Finger, facial, iris, voice, and skin biometrics; Signature recognition; Multimodal biometrics; Verification and identification techniques; Accuracy of biometric technologies; Authentication smart cards and biometric metrics; Performance and assurance testing; Limitations of biometric technologies; Biometric card technologies; Biometric wireless technologies; Biometric software and hardware; Biometric standards Knowledge data systems Data mining and Web mining; Knowledge databases and systems; Data warehouse and applications; Data warehousing and information systems; Database performance evaluation; Semantic and temporal databases; Database systems Databases and information retrieval; Digital library design; Meta-data modeling Mobile and distance education Human computer interaction; Educational technologies; Computer in education; Distance learning; E-learning; Mobile learning Cognitive support for learning; Internet-based education; Impact of ICT on education and society; Group decision making and software; Habitual domain and information technology; Computer-mediated communications; Immersing authoring; Contextual and cultural challenges in user mobility Intelligent techniques, logics, and systems Intelligent agent technologies; Intelligent and fuzzy information processing; Intelligent computing and knowledge management; Intelligent systems and robotics; Fault-tolerance and reliability; Fuzzy logic & systems; Genetic algorithms; Haptic phenomena; Graphic recognition; Neural networks; Symbolic and algebraic computation; Modeling, simulation and analysis of business processes and systems Knowledge processing Knowledge representation models; Knowledge languages; Cognitive science; Knowledge acquisition; Knowledge engineering; Knowledge processing under uncertainty; Machine intelligence; Machine learning; Making decision through Internet; Networking knowledge plan Information technologies Information technology and organizational behavior; Agents, data mining and ontologies; Information retrieval systems; Information and network security; Information ethics and legal evaluations; Optimization and information technology; Organizational information systems; Information fusion; Information management systems; Information overload; Information policy making; Information security; Information systems; Information discovery Internet and web technologies Internet and WWW-based computing; Web and Grid computing; Internet service and training; IT and society; IT in education and health; Management information systems; Visualization and group decision making; Web based language development; Web search and decision making; Web service ontologies; Scientific web intelligence; Online business and decision making; Business rule language; E-Business; E-Commerce; Online and collaborative work; Social eco-systems and social networking; Social decisions on Internet; Computer ethics Digital information processing Mechatronics; Natural language processing; Medical imaging; Image processing; Signal processing; Speech processing; Video processing; Pattern recognition; Pattern recognition models; Graphics & computer vision; Medical systems and computing Cognitive science and knowledge agent-based systems Cognitive support for e-learning and mobile learning; Agents and cognitive models; Agents & complex systems; computational ecosystems; Agent architectures, perception, action & planning in agents; Agent communication: languages, semantics, pragmatics & protocols; Agent-based electronic commerce and trading systems Multi-agent constraint satisfaction; Agent programming languages, development environments and testbeds; Computational complexity in autonomous agents; Multi-agent planning and cooperation; Logics and formal models of for agency verification; Nomadic agents; Negotiation, auctions, persuasion; Privacy and security issues in multi-agent systems Mobility and multimedia systems Mobile communications; Multimedia and visual programming; Multimedia and decision making; Multimedia systems; Mobile multimedia systems; User-centered mobile applications; Designing for the mobile devices; Contextual user mobility; Mobile strategies for global market; Interactive television and mobile commerce Systems performance Performance evaluation; Performance modeling; Performance of parallel computing; Reasoning under uncertainty; Reliability and fault-tolerance; Performance instrumentation; Performance monitoring and corrections; Performance in entity-dependable systems; Real-time performance and near-real time performance evaluation; Performance in software systems; Performance and hybrid systems; Measuring performance in embedded systems Networking and telecommunications Telecommunication and Networking; Telecommunication Systems and Evaluation; Multiple Criteria Decision Making in Information Technology; Network and Decision Making; Networks and Security; Communications protocols (SIP/H323/MPLS/IP); Specialized networks (GRID/P2P/Overlay/Ad hoc/Sensor); Advanced services (VoIP/IPTV/Video-on-Demand; Network and system monitoring and management; Feature interaction detection and resolution; Policy-based monitoring and managements systems; Traffic modeling and monitoring; Traffic engineering and management; Self-monitoring, self-healing and self-management systems; Man-in-the-loop management paradigm Software development and deployment Software requirements engineering; Software design, frameworks, and architectures; Software interactive design; Formal methods for software development, verification and validation; Neural networks and performance; Patterns/Anti-patterns/Artifacts/Frameworks; Agile/Generic/Agent-oriented programming; Empirical software evaluation metrics; Software vulnerabilities; Reverse engineering; Software reuse; Software security, reliability and safety; Software economics; Software testing and debugging; Tracking defects in the OO design; Distributed and parallel software; Programming languages; Declarative programming; Real-time and embedded software; Open source software development methodologies; Software tools and deployment environments; Software Intelligence; Software Performance and Evaluation Knowledge virtualization Modeling techniques, tools, methodologies, languages; Model-driven architectures (MDA); Service-oriented architectures (SOA); Utility computing frameworks and fundamentals; Enabled applications through virtualization; Small-scale virtualization methodologies and techniques; Resource containers, physical resource multiplexing, and segmentation; Large-scale virtualization methodologies and techniques; Management of virtualized systems; Platforms, tools, environments, and case studies; Making virtualization real; On-demand utilities Adaptive enterprise; Managing utility-based systems; Development environments, tools, prototypes Systems and networks on the chip Microtechnology and nanotechnology; Real-time embedded systems; Programming embedded systems; Controlling embedded systems; High speed embedded systems; Designing methodologies for embedded systems; Performance on embedded systems; Updating embedded systems; Wireless/wired design of systems-on-the-chip; Testing embedded systems; Technologies for systems processors; Migration to single-chip systems Context-aware systems Context-aware autonomous entities; Context-aware fundamental concepts, mechanisms, and applications; Modeling context-aware systems; Specification and implementation of awareness behavioral contexts; Development and deployment of large-scale context-aware systems and subsystems; User awareness requirements Design techniques for interfaces and systems; Methodologies, metrics, tools, and experiments for specifying context-aware systems; Tools evaluations, Experiment evaluations Networking technologies Next generation networking; Network, control and service architectures; Network signalling, pricing and billing; Network middleware; Telecommunication networks architectures; On-demand networks, utility computing architectures; Next generation networks [NGN] principles; Storage area networks [SAN]; Access and home networks; High-speed networks; Optical networks; Peer-to-peer and overlay networking; Mobile networking and systems; MPLS-VPN, IPSec-VPN networks; GRID networks; Broadband networks Security in network, systems, and applications IT in national and global security; Formal aspects of security; Systems and network security; Security and cryptography; Applied cryptography; Cryptographic protocols; Key management; Access control; Anonymity and pseudonymity management; Security management; Trust management; Protection management; Certification and accreditation; Virii, worms, attacks, spam; Intrusion prevention and detection; Information hiding; Legal and regulatory issues Knowledge for global defense Business continuity and availability; Risk assessment; Aerospace computing technologies; Systems and networks vulnerabilities; Developing trust in Internet commerce; Performance in networks, systems, and applications; Disaster prevention and recovery; IT for anti-terrorist technology innovations (ATTI); Networks and applications emergency services; Privacy and trust in pervasive communications; Digital rights management; User safety and protection Information Systems [IS] Management Information Systems; Decision Support Systems; Innovation and IS; Enterprise Application Integration; Enterprise Resource Planning; Business Process Change; Design and Development Methodologies and Frameworks; Iterative and Incremental Methodologies; Agile Methodologies; IS Standards and Compliance Issues; Risk Management in IS Design and Development; Research Core Theories; Conceptualizations and Paradigms in IS; Research Ontological Assumptions in IS Research; IS Research Constraints, Limitations and Opportunities; IS vs Computer Science Research; IS vs Business Studies IPv6 Today - Technology and deployment IP Upgrade - An Engineering Exercise or a Necessity?; Worldwide IPv6 Adoption - Trends and Policies; IPv6 Programs, from Research to Knowledge Dissemination; IPv6 Technology - Practical Information; Advanced Topics and Latest Developments in IPv6; IPv6 Deployment Experiences and Case Studies; IPv6 Enabled Applications and Devices Modeling Continuous and Discrete Models; Optimal Models; Complex System Modeling; Individual-Based Models; Modeling Uncertainty; Compact Fuzzy Models; Modeling Languages; Real-time modeling; Performance modeling Optimization Multicriteria Optimization; Multilervel Optimization; Goal Programming; Optimization and Efficiency; Optimization-based decisions; Evolutionary Optimization; Self-Optimization; Extreme Optimization; Combinatorial Optimization; Discrete Optimization; Fuzzy Optimization; Lipschitzian Optimization; Non-Convex Optimization; Convexity; Continuous Optimization; Interior point methods; Semi-definite and Conic Programming Complexity Complexity Analysis; Computational Complexity; Complexity Reduction; Optimizing Model Complexity; Communication Complexity; Managing Complexity; Modeling Complexity in Social Systems; Low-complexity Global Optimization; Software Development for Modeling and Optimization; Industrial applications ------------------------------ Committee:http://www.iaria.org/conferences2012/ComICCGI12.html ==================== pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719d0a9c37165047794f1350914628f9bb1 --_000_CADEAABD65CFBdavidfreedmaneuclaranet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After the feedback from the DB-WG Meeting in Vienna last week, I'd like to = bring this back to the list. I'd like to see the RegID (or equivalent) displayed for all resources in th= e database, this will help us identify the holder of: * PA Allocations (currently found in alloclist, currently attached Org-= ID) * PA Assignments (only found through less specific aggregate inetnum an= d as per above) * PI Assignments (not found at all) * Autonomous systems (not found at all?) The privacy issues concerning publishing are currently being investigated b= y the NCC and a number of people have expressed concern about revealing com= mercial relationships, especially with regards to revealing the sponsoring LIR for a particular en= d-user resource (though, I did make the point that you can ask the NCC a di= rect question about who the sponsoring LIR is and lack of policy means they reveal this). The technical issue concerning publishing , is that using the RegID may not= be the best idea, the NCC say "It is for internal use" (but it is the only= thing I see in my LIR portal?), why not use the OrgID (but this doesn't relate to the RegID , how do I link this to a bone = fide LIR?) , one issue with using the regID over the orgID may be that the = regID would simply be represented in the database as a string , since there is no related object to tie it to (which= may be an undesirable outcome). Dave. --_000_CADEAABD65CFBdavidfreedmaneuclaranet_ Content-Type: text/html; charset="us-ascii" Content-ID: <156F6A30F3EB4E4BAF9509874F0B503C@claranet.local> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id D2932341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 8 Nov 2011 10:48:15 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RNiHt-0007i3-6r; Tue, 08 Nov 2011 10:48:15 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RNiHs-0006ia-Tn; Tue, 08 Nov 2011 10:48:12 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <david.freedman@uk.clara.net>) id 1RNiHq-0006iV-DY for db-wg@lists.ripe.net; Tue, 08 Nov 2011 10:48:10 +0100 Received: from staff01.mail.eu.clara.net ([2001:a88:0:fff7::54]) by postgirl.ripe.net with esmtp (Exim 4.72) (envelope-from <david.freedman@uk.clara.net>) id 1RNiHm-0005Xi-A2 for db-wg@ripe.net; Tue, 08 Nov 2011 10:48:10 +0100 Received: from [195.157.10.59] (port=22623 helo=SRVGREXCAS01.claranet.local) by staff01.mail.eu.clara.net (staff01.mail.eu.clara.net [80.168.65.54]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1RNiHl-0006yJ-5K for db-wg@ripe.net (return-path <david.freedman@uk.clara.net>); Tue, 08 Nov 2011 09:48:05 +0000 Received: from SRVGREXMB03.claranet.local ([10.75.5.26]) by SRVGREXCAS01.claranet.local ([fe80::d0e0:3f28:712f:4dea%10]) with mapi id 14.01.0339.001; Tue, 8 Nov 2011 09:48:05 +0000 From: David Freedman <david.freedman@uk.clara.net> To: "db-wg@ripe.net" <db-wg@ripe.net> Thread-Topic: Reverse aut-num queries in the database Thread-Index: AQHMnfuDhs2Ooc3ElkanhXxOmyGirw== Date: Tue, 8 Nov 2011 09:48:04 +0000 Message-ID: <CADEAB50.65D0A%david.freedman@eu.clara.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.18.6.3] Content-Type: multipart/alternative; boundary="_000_CADEAB5065D0Adavidfreedmaneuclaranet_" MIME-Version: 1.0 X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 5aa369f352efcb7801fa06fbb6cba0dde83eb5a24370c622c35dae8c20d7f16b Subject: [db-wg] Reverse aut-num queries in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points
</head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 16px; font-fami= ly: Calibri, sans-serif; "> <div>After the feedback from the DB-WG Meeting in Vienna last week, I'd lik= e to bring this back to the list.</div> <div><br> </div> <div>I'd like to see the RegID (or equivalent) displayed for all resources = in the database, this will help us identify the </div> <div>holder of:</div> <ul> <li>PA Allocations (currently found in alloclist, currently attached Org-ID= )</li><li>PA Assignments (only found through less specific aggregate inetnu= m and as per above)</li><li>PI Assignments (not found at all)</li><li>Auton= omous systems (not found at all?)</li></ul> <div>The privacy issues concerning publishing are currently being investiga= ted by the NCC and a number of people have expressed concern about revealin= g commercial relationships,</div> <div>especially with regards to revealing the sponsoring LIR for a particul= ar end-user resource (though, I did make the point that you can ask the NCC= a direct question about who the </div> <div>sponsoring LIR is and lack of policy means they reveal this).</div> <div><br> </div> <div>The technical issue concerning publishing , is that using the RegID ma= y not be the best idea, the NCC say "It is for internal use" (but= it is the only thing I see in my LIR portal?), why not use the</div> <div>OrgID (but this doesn't relate to the RegID , how do I link this to a = bone fide LIR?) , one issue with using the regID over the orgID may be that= the regID would simply be represented in the </div> <div>database as a string , since there is no related object to tie it to (= which may be an undesirable outcome).</div> <div><br> </div> <div>Dave.</div> <div><br> </div> </body> </html> --_000_CADEAABD65CFBdavidfreedmaneuclaranet_-- pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719e83eb5a24370c622c35dae8c20d7f16b --_000_CADEAB5065D0Adavidfreedmaneuclaranet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After the feedback from the DB-WG Meeting in Vienna last week, I'd like to = bring this back to the list. I'd been trying to clean up an Aut-Num to return it to the NCC. I wanted to= know if there was a way of undertaking an inverse search against the RPSL policies of my peers' Aut-Num objects to ensure the= y could remove all references to be before handing the resource back. I'm currently doing this with a free-text search, since the database doesn'= t hold references to the tokens in the RPSL policy (or does it?) Any better ideas? Dave. --_000_CADEAB5065D0Adavidfreedmaneuclaranet_ Content-Type: text/html; charset="us-ascii" Content-ID: <FEA9DF7D3B62444795686169936F8856@claranet.local> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id 0D5C4341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 8 Nov 2011 10:50:34 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RNiK8-0007nf-D5; Tue, 08 Nov 2011 10:50:33 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RNiK8-0006jb-2X; Tue, 08 Nov 2011 10:50:32 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <david.freedman@uk.clara.net>) id 1RNiK6-0006jV-6v for db-wg@lists.ripe.net; Tue, 08 Nov 2011 10:50:30 +0100 Received: from staff00.mail.eu.clara.net ([2001:a88:0:fff7::68]) by postgirl.ripe.net with esmtp (Exim 4.72) (envelope-from <david.freedman@uk.clara.net>) id 1RNiK3-0005gT-VG for db-wg@ripe.net; Tue, 08 Nov 2011 10:50:30 +0100 Received: from [195.157.10.59] (port=4460 helo=SRVGREXCAS01.claranet.local) by staff00.mail.eu.clara.net (staff00.mail.eu.clara.net [80.168.65.68]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1RNi8b-0007mc-1C for db-wg@ripe.net (return-path <david.freedman@uk.clara.net>); Tue, 08 Nov 2011 09:38:37 +0000 Received: from SRVGREXMB03.claranet.local ([10.75.5.26]) by SRVGREXCAS01.claranet.local ([fe80::d0e0:3f28:712f:4dea%10]) with mapi id 14.01.0339.001; Tue, 8 Nov 2011 09:38:37 +0000 From: David Freedman <david.freedman@uk.clara.net> To: "db-wg@ripe.net" <db-wg@ripe.net> Thread-Topic: MD5 Hashes in the database Thread-Index: AQHMnfowpyEJtl7QskqXfDgwu6BOLg== Date: Tue, 8 Nov 2011 09:38:36 +0000 Message-ID: <CADEA918.65CDA%david.freedman@eu.clara.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.18.6.3] Content-Type: multipart/alternative; boundary="_000_CADEA91865CDAdavidfreedmaneuclaranet_" MIME-Version: 1.0 X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 5aa369f352efcb7801fa06fbb6cba0ddece0497318f62b6a8ea4596d6fe2bcf5 Subject: [db-wg] MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points
</head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 16px; font-fami= ly: Calibri, sans-serif; "> <div>After the feedback from the DB-WG Meeting in Vienna last week, I'd lik= e to bring this back to the list.</div> <div><br> </div> <div>I'd been trying to clean up an Aut-Num to return it to the NCC. I want= ed to know if there was a way of undertaking an inverse</div> <div>search against the RPSL policies of my peers' Aut-Num objects to ensur= e they could remove all references to be before handing</div> <div>the resource back.</div> <div><br> </div> <div>I'm currently doing this with a free-text search, since the database d= oesn't hold references to the tokens in the RPSL policy (or does it?)</div> <div><br> </div> <div>Any better ideas?</div> <div><br> </div> <div>Dave.</div> <div><br> </div> </body> </html> --_000_CADEAB5065D0Adavidfreedmaneuclaranet_-- pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719ece0497318f62b6a8ea4596d6fe2bcf5 --_000_CADEA91865CDAdavidfreedmaneuclaranet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After the feedback from the DB-WG Meeting in Vienna last week, I'd like to = bring this back to the list. I'd like to see auth: MD5-PW deprecated , even though it seems to be widely= used (for various reasons) according to the report by DB presented to us. Until we can stop it being used completely, I'd like the hashes removed fro= m the database, since they are sitting out there waiting to be bruteforced, at which point somebody takes malicious control = of the resources protected by your mntner. I understand the challenge of hiding the field from display is that it must= be present when changing or deleting objects , but since it only appears to be in mntners, I'm sure an exception could be made= , considering the seriousness of this. Dave. --_000_CADEA91865CDAdavidfreedmaneuclaranet_ Content-Type: text/html; charset="us-ascii" Content-ID: <90E914149596904DA90812576ACCFD51@claranet.local> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 45D9F341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 8 Nov 2011 11:15:42 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RNiiC-00079W-Mw; Tue, 08 Nov 2011 11:15:28 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RNiiC-0006z4-DI; Tue, 08 Nov 2011 11:15:24 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <stolpe@resilans.se>) id 1RNiiA-0006yz-FM for db-wg@lists.ripe.net; Tue, 08 Nov 2011 11:15:22 +0100 Received: from ns1.resilans.se ([2a01:280:1::53] helo=server.resilans.se) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <stolpe@resilans.se>) id 1RNii8-00079C-SZ for db-wg@ripe.net; Tue, 08 Nov 2011 11:15:22 +0100 Received: from server.resilans.se (server.resilans.se [194.14.3.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.resilans.se (Postfix) with ESMTPS id C9DDE34A4C8; Tue, 8 Nov 2011 11:15:19 +0100 (CET) Date: Tue, 8 Nov 2011 11:15:19 +0100 (CET) From: Daniel Stolpe <stolpe@resilans.se> To: David Freedman <david.freedman@uk.clara.net> In-Reply-To: <CADEAABD.65CFB%david.freedman@eu.clara.net> Message-ID: <alpine.LNX.2.00.1111081106380.1838@server.resilans.se> References: <CADEAABD.65CFB%david.freedman@eu.clara.net> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="247595523-845671658-1320747319=:1838" X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: c3aeb2490f138a562ee6e8d56e76c7c5a755986cf73fb355c95ced77c3b7deba Cc: "db-wg@ripe.net" <db-wg@ripe.net> Subject: Re: [db-wg] Displaying RegID for all resources X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points
</head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 16px; font-fami= ly: Calibri, sans-serif; "> <div>After the feedback from the DB-WG Meeting in Vienna last week, I'd lik= e to bring this back to the list.</div> <div><br> </div> <div>I'd like to see auth: MD5-PW deprecated , even though it seems to be w= idely used (for various reasons)</div> <div>according to the report by DB presented to us. </div> <div><br> </div> <div>Until we can stop it being used completely, I'd like the hashes remove= d from the database, since they are sitting out there</div> <div>waiting to be bruteforced, at which point somebody takes malicious con= trol of the resources protected by your mntner.</div> <div><br> </div> <div>I understand the challenge of hiding the field from display is that it= must be present when changing or deleting objects , but</div> <div>since it only appears to be in mntners, I'm sure an exception could be= made, considering the seriousness of this.</div> <div><br> </div> <div>Dave.</div> <div><br> </div> </body> </html> --_000_CADEA91865CDAdavidfreedmaneuclaranet_-- pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719a755986cf73fb355c95ced77c3b7deba This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --247595523-845671658-1320747319=:1838 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable We discussed this issue in Amsterdam if I remember things correctly. I am= =20 very much in favour of 'a way' to get this information. Maybe you could restrict questions to the LIR portal and track who is=20 asking and let the holder know. But as you say the NCC will reveal this=20 anyway if asked. On Tue, 8 Nov 2011, David Freedman wrote:
After the feedback from the DB-WG Meeting in Vienna last week, I'd like= to bring this back to the list. =20 I'd like to see the RegID (or equivalent) displayed for all resources i= n the database, this will help us identify the=A0 holder of: * PA Allocations (currently found in alloclist, currently attached Or= g-ID) * PA Assignments (only found through less specific aggregate inetnum = and as per above) * PI Assignments (not found at all) * Autonomous systems (not found at all?) The privacy issues concerning publishing are currently being investigat= ed by the NCC and a number of people have expressed concern about reveali= ng commercial relationships, especially with regards to revealing the sponsoring LIR for a particula= r end-user resource (though, I did make the point that you can ask the NC= C a direct question about who the=A0 sponsoring LIR is and lack of policy means they reveal this). =20 The technical issue concerning publishing , is that using the RegID may= not be the best idea, the NCC say "It is for internal use" (but it is th= e only thing I see in my LIR portal?), why not use the OrgID (but this doesn't relate to the RegID , how do I link this to a b= one fide LIR?) , one issue with using the regID over the orgID may be tha= t the regID would simply be represented in the=A0 database as a string , since there is no related object to tie it to (w= hich may be an undesirable outcome). =20 Dave. =20 =20
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id E16C3341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 8 Nov 2011 12:56:45 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RNkHz-00027o-Oi; Tue, 08 Nov 2011 12:56:33 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RNkHz-0007sr-FG; Tue, 08 Nov 2011 12:56:27 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <shane@time-travellers.org>) id 1RNkHy-0007sm-Ei for db-wg@lists.ripe.net; Tue, 08 Nov 2011 12:56:26 +0100 Received: from he.time-travellers.nl.eu.org ([62.212.65.17] helo=time-travellers.nl.eu.org) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <shane@time-travellers.org>) id 1RNkHw-0003KC-6b for db-wg@ripe.net; Tue, 08 Nov 2011 12:56:26 +0100 Received: from s529d1bbf.adsl.wanadoo.nl ([82.157.27.191] helo=[172.29.1.198]) by time-travellers.nl.eu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <shane@time-travellers.org>) id 1RNkHu-000183-72; Tue, 08 Nov 2011 11:56:22 +0000 From: Shane Kerr <shane@time-travellers.org> To: David Freedman <david.freedman@uk.clara.net> Date: Tue, 08 Nov 2011 12:56:16 +0100 In-Reply-To: <CADEA918.65CDA%david.freedman@eu.clara.net> References: <CADEA918.65CDA%david.freedman@eu.clara.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 (3.0.3-1.fc15) Content-Transfer-Encoding: 7bit Message-ID: <1320753382.2522.21.camel@shane-desktop> Mime-Version: 1.0 X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points pts rule name description ---- ---------------------- ------------------------------------ -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 7dbc47838f18b9f91fca9fb4839f56ddc974e215b19c029b8c6acef320aa6da4 Cc: "db-wg@ripe.net" <db-wg@ripe.net> Subject: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points
Best Regards, Daniel Stolpe _________________________________________________________________________= ________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@res= ilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resi= lans.se/ Box 13 054 556741-1193 103 02 Stockholm --247595523-845671658-1320747319=:1838-- pts rule name description ---- ---------------------- ------------------------------------ -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719c974e215b19c029b8c6acef320aa6da4 David, On Tue, 2011-11-08 at 09:38 +0000, David Freedman wrote:
I'd like to see auth: MD5-PW deprecated , even though it seems to be widely used (for various reasons) according to the report by DB presented to us.
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 9D356341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 8 Nov 2011 12:58:06 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RNkJM-0003Q8-In; Tue, 08 Nov 2011 12:57:57 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RNkJL-0007tV-2n; Tue, 08 Nov 2011 12:57:51 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <shane@time-travellers.org>) id 1RNkJI-0007tP-Pk for db-wg@lists.ripe.net; Tue, 08 Nov 2011 12:57:48 +0100 Received: from he.time-travellers.nl.eu.org ([62.212.65.17] helo=time-travellers.nl.eu.org) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <shane@time-travellers.org>) id 1RNkJH-0003Pv-JF for db-wg@ripe.net; Tue, 08 Nov 2011 12:57:48 +0100 Received: from s529d1bbf.adsl.wanadoo.nl ([82.157.27.191] helo=[172.29.1.198]) by time-travellers.nl.eu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <shane@time-travellers.org>) id 1RNkBj-00017q-Lv; Tue, 08 Nov 2011 11:49:59 +0000 From: Shane Kerr <shane@time-travellers.org> To: David Freedman <david.freedman@uk.clara.net> Date: Tue, 08 Nov 2011 12:49:51 +0100 In-Reply-To: <CADEA918.65CDA%david.freedman@eu.clara.net> References: <CADEA918.65CDA%david.freedman@eu.clara.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 (3.0.3-1.fc15) Content-Transfer-Encoding: 7bit Message-ID: <1320752999.2522.15.camel@shane-desktop> Mime-Version: 1.0 X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points pts rule name description ---- ---------------------- ------------------------------------ -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 7dbc47838f18b9f91fca9fb4839f56dd7b365b4918dba91439ebf0e0137a1b6d Cc: "db-wg@ripe.net" <db-wg@ripe.net> Subject: [db-wg] Hiding MD5 hashes from users, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points
I propose that we deprecate passwords over unencrypted channels. AFAIK this just means e-mail today, although the web API stuff may also provide an non-TLS option (I don't know). Unlike hiding MD5, this is a major change for users, and would need to be done with the same caution and preparation as similar large changes in the past. We could have a warning phase, where anyone using a password in email would get a scary warning in the reply telling them to use a more secure scheme (PGP, X.509, webupdates, or database web API). The RIPE NCC could identify heavy users and help them convert their tools. And eventually we could flip the switch and turn off plain text passwords. -- Shane pts rule name description ---- ---------------------- ------------------------------------ -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b835117197b365b4918dba91439ebf0e0137a1b6d David, On Tue, 2011-11-08 at 09:38 +0000, David Freedman wrote:
Until we can stop it being used completely, I'd like the hashes removed from the database, since they are sitting out there waiting to be bruteforced, at which point somebody takes malicious control of the resources protected by your mntner.
I understand the challenge of hiding the field from display is that it must be present when changing or deleting objects , but since it only appears to be in mntners, I'm sure an exception could be made, considering the seriousness of this.
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 589EF341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 8 Nov 2011 12:58:57 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RNkKL-0003WA-6X; Tue, 08 Nov 2011 12:58:57 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RNkKK-0007v8-Tl; Tue, 08 Nov 2011 12:58:52 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <david.freedman@uk.clara.net>) id 1RNkKJ-0007v3-6v for db-wg@lists.ripe.net; Tue, 08 Nov 2011 12:58:51 +0100 Received: from staff00.mail.eu.clara.net ([2001:a88:0:fff7::68]) by postgirl.ripe.net with esmtp (Exim 4.72) (envelope-from <david.freedman@uk.clara.net>) id 1RNkKH-0003Vw-UK for db-wg@ripe.net; Tue, 08 Nov 2011 12:58:51 +0100 Received: from [195.157.10.59] (port=33603 helo=SRVGREXCAS02.claranet.local) by staff00.mail.eu.clara.net (staff00.mail.eu.clara.net [80.168.65.68]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1RNkKG-0007Cb-2Z (return-path <david.freedman@uk.clara.net>); Tue, 08 Nov 2011 11:58:48 +0000 Received: from SRVGREXMB03.claranet.local ([10.75.5.26]) by SRVGREXCAS02.claranet.local ([fe80::cd6a:3120:3174:a299%10]) with mapi id 14.01.0339.001; Tue, 8 Nov 2011 11:58:48 +0000 From: David Freedman <david.freedman@uk.clara.net> To: Shane Kerr <shane@time-travellers.org>, David Freedman <david.freedman@uk.clara.net> Thread-Topic: Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database Thread-Index: AQHMnfowpyEJtl7QskqXfDgwu6BOLpWi3uIAgAAAsAA= Date: Tue, 8 Nov 2011 11:58:48 +0000 Message-ID: <CADEC9BD.65E31%david.freedman@eu.clara.net> In-Reply-To: <1320753382.2522.21.camel@shane-desktop> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.18.6.3] Content-Type: text/plain; charset="us-ascii" Content-ID: <EEB94B46A2885A46A642ADD5B60A8937@claranet.local> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5aa369f352efcb7801fa06fbb6cba0dd0ee5d0b29fbc35f75ffee01850530d4d Cc: "db-wg@ripe.net" <db-wg@ripe.net> Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points
So this smaller problem statement is that we have the crypted versions of the passwords visible for all to see/hack. Note that while these passwords are not visible in the downloaded versions of the maintainer files, it is straightforward to convert those maintainer identifiers into WHOIS queries and get the passwords (it only takes a few weeks, even from a single rate-limited IP address). Even if we hide the maintainer files completely, it will still be possible to get a list of "interesting" maintainers from the actual number assignments, since each of those has a maintainer. So, yes, visible passwords are a problem. I support filtering mntner objects so that MD5-PW strings are hidden: auth: MD5-PW # password filtered for security I agree that if it causes problems with updates to mntner objects, that this can be resolved somehow, through the magic of software. -- Shane pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b835117190ee5d0b29fbc35f75ffee01850530d4d I don't mind it continuing to be used over encrypted channels, as long as the hashes are not available to the general public (as per your previous mail) I would support a warning phase Dave. On 08/11/2011 11:56, "Shane Kerr" <shane@time-travellers.org> wrote:
David,
On Tue, 2011-11-08 at 09:38 +0000, David Freedman wrote:
I'd like to see auth: MD5-PW deprecated , even though it seems to be widely used (for various reasons) according to the report by DB presented to us.
I propose that we deprecate passwords over unencrypted channels. AFAIK this just means e-mail today, although the web API stuff may also provide an non-TLS option (I don't know).
Unlike hiding MD5, this is a major change for users, and would need to be done with the same caution and preparation as similar large changes in the past. We could have a warning phase, where anyone using a password in email would get a scary warning in the reply telling them to use a more secure scheme (PGP, X.509, webupdates, or database web API). The RIPE NCC could identify heavy users and help them convert their tools. And eventually we could flip the switch and turn off plain text passwords.
-- Shane
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 4FF15341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 8 Nov 2011 13:23:00 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RNkha-0004wj-S3; Tue, 08 Nov 2011 13:22:57 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RNkha-00088l-IE; Tue, 08 Nov 2011 13:22:54 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <virtualabs@gmail.com>) id 1RNkhX-00088b-79 for db-wg@lists.ripe.net; Tue, 08 Nov 2011 13:22:51 +0100 Received: from mail-qy0-f179.google.com ([209.85.216.179]) by postgirl.ripe.net with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from <virtualabs@gmail.com>) id 1RNkhU-0004wT-IE for db-wg@ripe.net; Tue, 08 Nov 2011 13:22:50 +0100 Received: by qyk32 with SMTP id 32so536041qyk.17 for <db-wg@ripe.net>; Tue, 08 Nov 2011 04:22:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.43.3 with SMTP id u3mr3684735qce.210.1320754473480; Tue, 08 Nov 2011 04:14:33 -0800 (PST) Received: by 10.229.223.134 with HTTP; Tue, 8 Nov 2011 04:14:33 -0800 (PST) In-Reply-To: <CADEC9BD.65E31%david.freedman@eu.clara.net> References: <1320753382.2522.21.camel@shane-desktop> <CADEC9BD.65E31%david.freedman@eu.clara.net> Date: Tue, 8 Nov 2011 13:14:33 +0100 Message-ID: <CAFr1is4Dr_u8xuJQ07UhJfjGyeRbPQtO4SgJoq788_vC9__hwA@mail.gmail.com> From: virtu virtualabs <virtualabs@gmail.com> To: David Freedman <david.freedman@uk.clara.net> Content-Type: multipart/alternative; boundary=0016364268793a33ea04b1381d01 X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.7 points pts rule name description ---- ---------------------- ------------------------------------ -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.216.179 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (virtualabs[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid X-RIPE-Signature: 91f864e994235b53501ac01e981d4482f50b84db2b474b557565ac427a6780cc Cc: Shane Kerr <shane@time-travellers.org>, "db-wg@ripe.net" <db-wg@ripe.net> Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.6 points
pts rule name description ---- ---------------------- ------------------------------------ -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.216.179 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (virtualabs[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719f50b84db2b474b557565ac427a6780cc --0016364268793a33ea04b1381d01 Content-Type: text/plain; charset=ISO-8859-1 Hello David &Shane, I agree the fact that grabbing all the existing maintainers hashes is completely feasible since I did it during previous days (in order to assess their strength, not to disclose them). I made some tests with the help of a friend of mine, and we recovered at least 4% of these passwords only by testing a very popular wordlist (rockyou), and the recovery process is still running. We were amazed to see how many maintainers use weak passwords to protect their datas, sometimes using their alias as a password. Therefore, I totally agree with David and would ask that some constraints should be added while creating MD5(UNIX) hashes through RIPE's website dedicated page (https://apps.db.ripe.net/crypt/). This webpage is also recommended by ARIN and modifying the way passwords are hashed (and checked ?) should be better for both RIPE NCC and ARIN. Telling people not to use twice a generated hash could also help a bit more ;) My goal is not to recover every possible password from public hashes but just demonstrate that it does not follow currently best-practices in term of security. Damien On Tue, Nov 8, 2011 at 12:58 PM, David Freedman <david.freedman@uk.clara.net
wrote:
I don't mind it continuing to be used over encrypted channels, as long as the hashes are not available to the general public (as per your previous mail)
I would support a warning phase
Dave.
On 08/11/2011 11:56, "Shane Kerr" <shane@time-travellers.org> wrote:
David,
On Tue, 2011-11-08 at 09:38 +0000, David Freedman wrote:
I'd like to see auth: MD5-PW deprecated , even though it seems to be widely used (for various reasons) according to the report by DB presented to us.
I propose that we deprecate passwords over unencrypted channels. AFAIK this just means e-mail today, although the web API stuff may also provide an non-TLS option (I don't know).
Unlike hiding MD5, this is a major change for users, and would need to be done with the same caution and preparation as similar large changes in the past. We could have a warning phase, where anyone using a password in email would get a scary warning in the reply telling them to use a more secure scheme (PGP, X.509, webupdates, or database web API). The RIPE NCC could identify heavy users and help them convert their tools. And eventually we could flip the switch and turn off plain text passwords.
-- Shane
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id 44322341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 8 Nov 2011 13:23:08 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RNkhb-0002ym-JY; Tue, 08 Nov 2011 13:23:05 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RNkha-00088t-W7; Tue, 08 Nov 2011 13:22:55 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <stolpe@resilans.se>) id 1RNkhY-00088g-0j for db-wg@lists.ripe.net; Tue, 08 Nov 2011 13:22:52 +0100 Received: from ns1.resilans.se ([2a01:280:1::53] helo=server.resilans.se) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <stolpe@resilans.se>) id 1RNkhW-0004wX-IM for db-wg@ripe.net; Tue, 08 Nov 2011 13:22:51 +0100 Received: from server.resilans.se (server.resilans.se [194.14.3.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.resilans.se (Postfix) with ESMTPS id 238CB34A82D; Tue, 8 Nov 2011 13:22:50 +0100 (CET) Date: Tue, 8 Nov 2011 13:22:50 +0100 (CET) From: Daniel Stolpe <stolpe@resilans.se> To: David Freedman <david.freedman@uk.clara.net> In-Reply-To: <CADEC9BD.65E31%david.freedman@eu.clara.net> Message-ID: <alpine.LNX.2.00.1111081320150.1838@server.resilans.se> References: <CADEC9BD.65E31%david.freedman@eu.clara.net> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: c3aeb2490f138a562ee6e8d56e76c7c519c5a9cb6bd693e2e30334d883e8ff17 Cc: Shane Kerr <shane@time-travellers.org>, "db-wg@ripe.net" <db-wg@ripe.net> Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points
--0016364268793a33ea04b1381d01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello David &Shane,<div><br></div><div>I agree the fact that grabbing a= ll the existing maintainers hashes is completely feasible since I did it du= ring previous days =A0(in order to assess their strength, not to disclose t= hem). I made some tests with the help of a friend of mine, and we recovered= at least 4% of these passwords only by testing a very popular wordlist (ro= ckyou), and the recovery process is still running.=A0</div> <div><br></div><div>We were amazed to see how many maintainers use weak pas= swords to protect their datas, sometimes using their alias as a password. T= herefore, I totally agree with David and would ask that some constraints sh= ould be added while creating MD5(UNIX) hashes through RIPE's website de= dicated page (<a href=3D"https://apps.db.ripe.net/crypt/">https://apps.db.r= ipe.net/crypt/</a>). This webpage is also recommended by ARIN and modifying= the way passwords are hashed (and checked ?) should be better for both RIP= E NCC and ARIN.</div> <div><br></div><div>Telling people not to use twice a generated hash could = also help a bit more ;)</div><div><br></div><div>My goal is not to recover = every possible password from public hashes but just demonstrate that it doe= s not follow currently best-practices in term of security.<br> <br><br>Damien<br><br><div class=3D"gmail_quote">On Tue, Nov 8, 2011 at 12:= 58 PM, David Freedman <span dir=3D"ltr"><<a href=3D"mailto:david.freedma= n@uk.clara.net">david.freedman@uk.clara.net</a>></span> wrote:<br><block= quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= solid;padding-left:1ex;"> I don't mind it continuing to be used over encrypted channels,<br> as long as the hashes are not available to the general public (as per your<= br> previous mail)<br> <br> I would support a warning phase<br> <br> Dave.<br> <div class=3D"HOEnZb"><div class=3D"h5"><br> <br> <br> On 08/11/2011 11:56, "Shane Kerr" <<a href=3D"mailto:shane@tim= e-travellers.org">shane@time-travellers.org</a>> wrote:<br> <br> >David,<br> ><br> >On Tue, 2011-11-08 at 09:38 +0000, David Freedman wrote:<br> >> I'd like to see auth: MD5-PW deprecated , even though it seems= to be<br> >> widely used (for various reasons)<br> >> according to the report by DB presented to us.<br> ><br> >I propose that we deprecate =A0passwords over unencrypted channels. AFA= IK<br> >this just means e-mail today, although the web API stuff may also<br> >provide an non-TLS option (I don't know).<br> ><br> >Unlike hiding MD5, this is a major change for users, and would need to<= br> >be done with the same caution and preparation as similar large changes<= br> >in the past. We could have a warning phase, where anyone using a<br> >password in email would get a scary warning in the reply telling them t= o<br> >use a more secure scheme (PGP, X.509, webupdates, or database web API).= <br> >The RIPE NCC could identify heavy users and help them convert their<br> >tools. And eventually we could flip the switch and turn off plain text<= br> >passwords.<br> ><br> >--<br> >Shane<br> ><br> ><br> <br> <br> </div></div></blockquote></div><br></div> --0016364268793a33ea04b1381d01-- pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b8351171919c5a9cb6bd693e2e30334d883e8ff17 I agree. And maybe someone should set up john the ripper to crack some passwords and contact the holders of the weakest ones. On Tue, 8 Nov 2011, David Freedman wrote:
I don't mind it continuing to be used over encrypted channels, as long as the hashes are not available to the general public (as per your previous mail)
I would support a warning phase
Dave.
On 08/11/2011 11:56, "Shane Kerr" <shane@time-travellers.org> wrote:
David,
On Tue, 2011-11-08 at 09:38 +0000, David Freedman wrote:
I'd like to see auth: MD5-PW deprecated , even though it seems to be widely used (for various reasons) according to the report by DB presented to us.
I propose that we deprecate passwords over unencrypted channels. AFAIK this just means e-mail today, although the web API stuff may also provide an non-TLS option (I don't know).
Unlike hiding MD5, this is a major change for users, and would need to be done with the same caution and preparation as similar large changes in the past. We could have a warning phase, where anyone using a password in email would get a scary warning in the reply telling them to use a more secure scheme (PGP, X.509, webupdates, or database web API). The RIPE NCC could identify heavy users and help them convert their tools. And eventually we could flip the switch and turn off plain text passwords.
-- Shane
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id 7176F341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 8 Nov 2011 13:27:10 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RNkla-00037v-H6; Tue, 08 Nov 2011 13:27:09 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RNkla-0008Bh-9s; Tue, 08 Nov 2011 13:27:02 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <virtualabs@gmail.com>) id 1RNklX-0008Bc-Dk for db-wg@lists.ripe.net; Tue, 08 Nov 2011 13:26:59 +0100 Received: from mail-qy0-f172.google.com ([209.85.216.172]) by postgirl.ripe.net with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from <virtualabs@gmail.com>) id 1RNklV-0005CI-Qk for db-wg@ripe.net; Tue, 08 Nov 2011 13:26:59 +0100 Received: by qyl16 with SMTP id 16so4127125qyl.17 for <db-wg@ripe.net>; Tue, 08 Nov 2011 04:26:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.34.13 with SMTP id j13mr3680200qcd.248.1320755214796; Tue, 08 Nov 2011 04:26:54 -0800 (PST) Received: by 10.229.223.134 with HTTP; Tue, 8 Nov 2011 04:26:54 -0800 (PST) In-Reply-To: <alpine.LNX.2.00.1111081320150.1838@server.resilans.se> References: <CADEC9BD.65E31%david.freedman@eu.clara.net> <alpine.LNX.2.00.1111081320150.1838@server.resilans.se> Date: Tue, 8 Nov 2011 13:26:54 +0100 Message-ID: <CAFr1is7ZD9NRA75dV164AHOj_2wF-QcqpmW7LweRrFeytwt68w@mail.gmail.com> From: virtu virtualabs <virtualabs@gmail.com> To: Daniel Stolpe <stolpe@resilans.se> Content-Type: multipart/alternative; boundary=00163683411e69c8cd04b1384984 X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.0 points pts rule name description ---- ---------------------- ------------------------------------ -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.216.172 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (virtualabs[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message 1.7 SARE_HTML_USL_OBFU RAW: Message body has very strange HTML sequence -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid X-RIPE-Signature: 91f864e994235b53501ac01e981d4482c06f8dc441176f0eb3e677cb2429f957 Cc: Shane Kerr <shane@time-travellers.org>, "db-wg@ripe.net" <db-wg@ripe.net>, David Freedman <david.freedman@uk.clara.net> Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: / X-RIPE-Spam-Report: Spam Total Points: -0.9 points
Daniel _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm pts rule name description ---- ---------------------- ------------------------------------ -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.216.172 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (virtualabs[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message 1.7 SARE_HTML_USL_OBFU RAW: Message body has very strange HTML sequence X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719c06f8dc441176f0eb3e677cb2429f957 --00163683411e69c8cd04b1384984 Content-Type: text/plain; charset=ISO-8859-1 If you are interested, I can provide you with a list of maintainers which have weak passwords :) As I said, there is a cracking job running on my side on the MD5(UNIX) hashes I grabbed earlier(by the way I apologize if this raised some errors or security warnings ...). Once done I also could provide you with exact figures regarding number of cracked hashes. On Tue, Nov 8, 2011 at 1:22 PM, Daniel Stolpe <stolpe@resilans.se> wrote:
I agree.
And maybe someone should set up john the ripper to crack some passwords and contact the holders of the weakest ones.
On Tue, 8 Nov 2011, David Freedman wrote:
I don't mind it continuing to be used over encrypted channels,
as long as the hashes are not available to the general public (as per your previous mail)
I would support a warning phase
Dave.
On 08/11/2011 11:56, "Shane Kerr" <shane@time-travellers.org> wrote:
David,
On Tue, 2011-11-08 at 09:38 +0000, David Freedman wrote:
I'd like to see auth: MD5-PW deprecated , even though it seems to be widely used (for various reasons) according to the report by DB presented to us.
I propose that we deprecate passwords over unencrypted channels. AFAIK this just means e-mail today, although the web API stuff may also provide an non-TLS option (I don't know).
Unlike hiding MD5, this is a major change for users, and would need to be done with the same caution and preparation as similar large changes in the past. We could have a warning phase, where anyone using a password in email would get a scary warning in the reply telling them to use a more secure scheme (PGP, X.509, webupdates, or database web API). The RIPE NCC could identify heavy users and help them convert their tools. And eventually we could flip the switch and turn off plain text passwords.
-- Shane
Daniel
______________________________**______________________________** _____________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm
--00163683411e69c8cd04b1384984 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If you are interested, I can provide you with a list of maintainers which h= ave weak passwords :)<div><br></div><div>As I said, there is a cracking job= running on my side on the MD5(UNIX) hashes I grabbed earlier(by the way I = apologize if this raised some errors or security warnings ...). Once done I= also could provide you with exact figures regarding number of cracked hash= es.</div> <div><br></div><div><br><div class=3D"gmail_quote">On Tue, Nov 8, 2011 at 1= :22 PM, Daniel Stolpe <span dir=3D"ltr"><<a href=3D"mailto:stolpe@resila= ns.se">stolpe@resilans.se</a>></span> wrote:<br><blockquote class=3D"gma= il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef= t:1ex;"> <br> I agree.<br> <br> And maybe someone should set up john the ripper to crack some passwords and= contact the holders of the weakest ones.<div><div class=3D"h5"><br> <br> On Tue, 8 Nov 2011, David Freedman wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I don't mind it continuing to be used over encrypted channels,<br> as long as the hashes are not available to the general public (as per your<= br> previous mail)<br> <br> I would support a warning phase<br> <br> Dave.<br> <br> <br> <br> On 08/11/2011 11:56, "Shane Kerr" <<a href=3D"mailto:shane@tim= e-travellers.org" target=3D"_blank">shane@time-travellers.org</a>> wrote= :<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> David,<br> <br> On Tue, 2011-11-08 at 09:38 +0000, David Freedman wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I'd like to see auth: MD5-PW deprecated , even though it seems to be<br=
widely used (for various reasons)<br> according to the report by DB presented to us.<br> </blockquote> <br> I propose that we deprecate =A0passwords over unencrypted channels. AFAIK<b= r> this just means e-mail today, although the web API stuff may also<br> provide an non-TLS option (I don't know).<br> <br> Unlike hiding MD5, this is a major change for users, and would need to<br> be done with the same caution and preparation as similar large changes<br> in the past. We could have a warning phase, where anyone using a<br> password in email would get a scary warning in the reply telling them to<br=
use a more secure scheme (PGP, X.509, webupdates, or database web API).<br> The RIPE NCC could identify heavy users and help them convert their<br> tools. And eventually we could flip the switch and turn off plain text<br> passwords.<br> <br> --<br> Shane<br> <br> <br> </blockquote> <br> <br> <br> </blockquote> <br> <br></div></div> Daniel<br> <br> ______________________________<u></u>______________________________<u></u>_= ____________________<span class=3D"HOEnZb"><font color=3D"#888888"><br> Daniel Stolpe =A0 =A0 =A0 =A0 =A0 Tel: =A008 - 688 11 81 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 <a href=3D"mailto:stolpe@resilans.se" target=3D"_blank"=
stolpe@resilans.se</a><br> Resilans AB =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A008 - 55 00 21 63 =A0 =A0 =A0 = =A0 =A0 =A0<a href=3D"http://www.resilans.se/" target=3D"_blank">http://www= .resilans.se/</a><br> Box 13 054 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0556741-1193<br> 103 02 Stockholm<br> <br> <br> </font></span></blockquote></div><br></div>
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id AF730341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 8 Nov 2011 13:27:56 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RNkmQ-0005Ib-JK; Tue, 08 Nov 2011 13:27:56 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RNkmQ-0008CD-5d; Tue, 08 Nov 2011 13:27:54 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <david.freedman@uk.clara.net>) id 1RNkmN-0008C8-Ap for db-wg@lists.ripe.net; Tue, 08 Nov 2011 13:27:51 +0100 Received: from staff00.mail.eu.clara.net ([2001:a88:0:fff7::68]) by postgirl.ripe.net with esmtp (Exim 4.72) (envelope-from <david.freedman@uk.clara.net>) id 1RNkmL-0005IR-MN for db-wg@ripe.net; Tue, 08 Nov 2011 13:27:51 +0100 Received: from [195.157.10.59] (port=13301 helo=SRVGREXCAS01.claranet.local) by staff00.mail.eu.clara.net (staff00.mail.eu.clara.net [80.168.65.68]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1RNkmK-0001mo-2m (return-path <david.freedman@uk.clara.net>); Tue, 08 Nov 2011 12:27:48 +0000 Received: from SRVGREXMB03.claranet.local ([10.75.5.26]) by SRVGREXCAS01.claranet.local ([fe80::d0e0:3f28:712f:4dea%10]) with mapi id 14.01.0339.001; Tue, 8 Nov 2011 12:27:48 +0000 From: David Freedman <david.freedman@uk.clara.net> To: Daniel Stolpe <stolpe@resilans.se>, David Freedman <david.freedman@uk.clara.net> Thread-Topic: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database Thread-Index: AQHMnfowpyEJtl7QskqXfDgwu6BOLpWi3uIAgAAAsACAAAa8AIAAAV8A Date: Tue, 8 Nov 2011 12:27:47 +0000 Message-ID: <CADED041.65E7E%david.freedman@eu.clara.net> In-Reply-To: <alpine.LNX.2.00.1111081320150.1838@server.resilans.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.18.6.3] Content-Type: text/plain; charset="us-ascii" Content-ID: <07CCDA9B5D84244FAD0DD69EF3B66B02@claranet.local> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5aa369f352efcb7801fa06fbb6cba0dd01cfc1320bca01f0336acdcb88021216 Cc: Shane Kerr <shane@time-travellers.org>, "db-wg@ripe.net" <db-wg@ripe.net> Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points
--00163683411e69c8cd04b1384984-- pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b8351171901cfc1320bca01f0336acdcb88021216 I think the safest thing to do without angering existing maintainers is simply to: =20 - email campaign by NCC asking people to self-deprecate their use of MD5 (warning phase) - Hide the hashes from the database - Support MD5 use only through encrypted means - Ask people who really want to continue using it to change theirs in case old copies of hashes are lying around - Finally deprecate MD5 for good some years from now Dave. =20 =20 On 08/11/2011 12:22, "Daniel Stolpe" <stolpe@resilans.se> wrote:
I agree.
And maybe someone should set up john the ripper to crack some passwords and contact the holders of the weakest ones.
On Tue, 8 Nov 2011, David Freedman wrote:
I don't mind it continuing to be used over encrypted channels, as long as the hashes are not available to the general public (as per your previous mail)
I would support a warning phase
Dave.
On 08/11/2011 11:56, "Shane Kerr" <shane@time-travellers.org> wrote:
David,
On Tue, 2011-11-08 at 09:38 +0000, David Freedman wrote:
I'd like to see auth: MD5-PW deprecated , even though it seems to be widely used (for various reasons) according to the report by DB presented to us.
I propose that we deprecate passwords over unencrypted channels. AFAIK this just means e-mail today, although the web API stuff may also provide an non-TLS option (I don't know).
Unlike hiding MD5, this is a major change for users, and would need to be done with the same caution and preparation as similar large changes in the past. We could have a warning phase, where anyone using a password in email would get a scary warning in the reply telling them to use a more secure scheme (PGP, X.509, webupdates, or database web API). The RIPE NCC could identify heavy users and help them convert their tools. And eventually we could flip the switch and turn off plain text passwords.
-- Shane
Daniel
__________________________________________________________________________ _______ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id C7384341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 8 Nov 2011 13:35:37 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RNkto-0005eF-2U; Tue, 08 Nov 2011 13:35:33 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RNktn-0008Gm-EZ; Tue, 08 Nov 2011 13:35:31 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <stolpe@resilans.se>) id 1RNktl-0008Gg-13 for db-wg@lists.ripe.net; Tue, 08 Nov 2011 13:35:29 +0100 Received: from ns1.resilans.se ([2a01:280:1::53] helo=server.resilans.se) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <stolpe@resilans.se>) id 1RNkti-0005dF-5c for db-wg@ripe.net; Tue, 08 Nov 2011 13:35:29 +0100 Received: from server.resilans.se (server.resilans.se [194.14.3.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.resilans.se (Postfix) with ESMTPS id B752B34A82D; Tue, 8 Nov 2011 13:35:25 +0100 (CET) Date: Tue, 8 Nov 2011 13:35:25 +0100 (CET) From: Daniel Stolpe <stolpe@resilans.se> To: virtu virtualabs <virtualabs@gmail.com> In-Reply-To: <CAFr1is7ZD9NRA75dV164AHOj_2wF-QcqpmW7LweRrFeytwt68w@mail.gmail.com> Message-ID: <alpine.LNX.2.00.1111081333450.1838@server.resilans.se> References: <CADEC9BD.65E31%david.freedman@eu.clara.net> <alpine.LNX.2.00.1111081320150.1838@server.resilans.se> <CAFr1is7ZD9NRA75dV164AHOj_2wF-QcqpmW7LweRrFeytwt68w@mail.gmail.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="247595523-95727614-1320755725=:1838" X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: c3aeb2490f138a562ee6e8d56e76c7c5bff5a41119c48c2cc56763ae99791ee3 Cc: Shane Kerr <shane@time-travellers.org>, "db-wg@ripe.net" <db-wg@ripe.net>, David Freedman <david.freedman@uk.clara.net> Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points
If you are interested, I can provide you with a list of maintainers whi= ch have weak passwords :) As I said, there is a cracking job running on my side on the MD5(UNIX) = hashes I grabbed earlier(by the way I apologize if this raised some error= s or security warnings ...). Once done I also could provide you with exact f= igures regarding number of cracked hashes. =20 =20 On Tue, Nov 8, 2011 at 1:22 PM, Daniel Stolpe <stolpe@resilans.se> wrot= e:
I agree.
And maybe someone should set up john the ripper to crack some pas= swords and contact the holders of the weakest ones.
On Tue, 8 Nov 2011, David Freedman wrote:
I don't mind it continuing to be used over encrypted channe= ls, as long as the hashes are not available to the general publ= ic (as per your previous mail)
I would support a warning phase
Dave. =20 =20
On 08/11/2011 11:56, "Shane Kerr" <shane@time-travellers.or= g> wrote:
David,
On Tue, 2011-11-08 at 09:38 +0000, David Freedman wro= te: I'd like to see auth: MD5-PW deprecated , even =
pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719bff5a41119c48c2cc56763ae99791ee3 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --247595523-95727614-1320755725=:1838 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable It would be intreresting for benchmarking anyway. :-) On Tue, 8 Nov 2011, virtu virtualabs wrote: though it seems to be
widely used (for various reasons) according to the report by DB presented to us. =20
I propose that we deprecate =A0passwords over unencry=
pted channels. AFAIK
this just means e-mail today, although the web API st=
uff may also
provide an non-TLS option (I don't know).
Unlike hiding MD5, this is a major change for users, =
and would need to
be done with the same caution and preparation as simi=
lar large changes
in the past. We could have a warning phase, where any=
one using a
password in email would get a scary warning in the re=
ply telling them to
use a more secure scheme (PGP, X.509, webupdates, or =
database web API).
The RIPE NCC could identify heavy users and help them=
convert their
tools. And eventually we could flip the switch and tu=
rn off plain text
passwords.
-- Shane
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 71ABA341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 8 Nov 2011 13:45:11 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RNl32-00060g-Jf; Tue, 08 Nov 2011 13:45:09 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RNl32-0008MA-8t; Tue, 08 Nov 2011 13:45:04 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <prvs=02938b30bc=ripe@syss.de>) id 1RNl30-0008M5-4s for db-wg@lists.ripe.net; Tue, 08 Nov 2011 13:45:02 +0100 Received: from comline1.syss.de ([92.79.151.121]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <prvs=02938b30bc=ripe@syss.de>) id 1RNl2y-000600-Lt for db-wg@ripe.net; Tue, 08 Nov 2011 13:45:02 +0100 Received: from [10.100.1.204] (port=35805 helo=comsrv.syss.admin) by comline1.syss.de with esmtp (Exim 4.69) (envelope-from <ripe@syss.de>) id 1RNl0j-00079t-1J for db-wg@ripe.net; Tue, 08 Nov 2011 13:42:41 +0100 Received: from [10.200.1.67] (unknown [10.200.1.67]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by comsrv.syss.admin (Postfix) with ESMTPS id AA7102777A; Tue, 8 Nov 2011 13:40:27 +0100 (CET) Message-ID: <4EB923C0.1080306@syss.de> Date: Tue, 08 Nov 2011 13:42:40 +0100 From: Micha Borrmann <ripe@syss.de> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; de-DE; rv:1.9.2.8) Gecko/20100804 Thunderbird/3.1.2 MIME-Version: 1.0 To: db-wg@ripe.net References: <1320753382.2522.21.camel@shane-desktop> <CADEC9BD.65E31%david.freedman@eu.clara.net> <CAFr1is4Dr_u8xuJQ07UhJfjGyeRbPQtO4SgJoq788_vC9__hwA@mail.gmail.com> In-Reply-To: <CAFr1is4Dr_u8xuJQ07UhJfjGyeRbPQtO4SgJoq788_vC9__hwA@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: b1ac20b57459dc99d31ad9b24a4062a017217cd06a060b80e178381843ab2981 Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points
Daniel _________________________________________________________________________= ________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@res= ilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resi= lans.se/ Box 13 054 556741-1193 103 02 Stockholm --247595523-95727614-1320755725=:1838-- pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b8351171917217cd06a060b80e178381843ab2981 Am 08.11.2011 13:14, schrieb virtu virtualabs:
I agree the fact that grabbing all the existing maintainers hashes is completely feasible since I did it during previous days (in order to assess their strength, not to disclose them). I made some tests with the help of a friend of mine, and we recovered at least 4% of these passwords only by testing a very popular wordlist (rockyou), and the recovery process is still running.
We were amazed to see how many maintainers use weak passwords to protect their datas, sometimes using their alias as a password. Therefore, I totally agree with David and would ask that some constraints should be added while creating MD5(UNIX) hashes through RIPE's website dedicated page (https://apps.db.ripe.net/crypt/). This webpage is also recommended by ARIN and modifying the way passwords are hashed (and checked ?) should be better for both RIPE NCC and ARIN.
Telling people not to use twice a generated hash could also help a bit more ;)
My goal is not to recover every possible password from public hashes but just demonstrate that it does not follow currently best-practices in term of security.
This is an old story for myself. It was reported by the german magazin "DER SPIEGEL" two years ago (http://www.spiegel.de/spiegel/print/d-65243798.html).
On Tue, Nov 8, 2011 at 12:58 PM, David Freedman <david.freedman@uk.clara.net <mailto:david.freedman@uk.clara.net>> wrote:
I don't mind it continuing to be used over encrypted channels, as long as the hashes are not available to the general public (as per your previous mail)
I would support a warning phase
Dave.
On 08/11/2011 11:56, "Shane Kerr" <shane@time-travellers.org <mailto:shane@time-travellers.org>> wrote:
>David, > >On Tue, 2011-11-08 at 09:38 +0000, David Freedman wrote: >> I'd like to see auth: MD5-PW deprecated , even though it seems to be >> widely used (for various reasons) >> according to the report by DB presented to us. > >I propose that we deprecate passwords over unencrypted channels. AFAIK >this just means e-mail today, although the web API stuff may also >provide an non-TLS option (I don't know). > >Unlike hiding MD5, this is a major change for users, and would need to >be done with the same caution and preparation as similar large changes >in the past. We could have a warning phase, where anyone using a >password in email would get a scary warning in the reply telling them to >use a more secure scheme (PGP, X.509, webupdates, or database web API). >The RIPE NCC could identify heavy users and help them convert their >tools. And eventually we could flip the switch and turn off plain text >passwords.
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id 6B5BD341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 8 Nov 2011 15:02:31 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RNmFX-0005G7-19; Tue, 08 Nov 2011 15:02:19 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RNmFW-0000bI-Mk; Tue, 08 Nov 2011 15:02:02 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <virtualabs@gmail.com>) id 1RNmFS-0000b9-Ij for db-wg@lists.ripe.net; Tue, 08 Nov 2011 15:01:59 +0100 Received: from mail-qw0-f44.google.com ([209.85.216.44]) by postgirl.ripe.net with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from <virtualabs@gmail.com>) id 1RNmFG-00017V-Hm for db-wg@ripe.net; Tue, 08 Nov 2011 15:01:58 +0100 Received: by qadc10 with SMTP id c10so500948qad.17 for <db-wg@ripe.net>; Tue, 08 Nov 2011 06:01:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.34.13 with SMTP id j13mr3734512qcd.248.1320760905226; Tue, 08 Nov 2011 06:01:45 -0800 (PST) Received: by 10.229.223.134 with HTTP; Tue, 8 Nov 2011 06:01:45 -0800 (PST) In-Reply-To: <4EB923C0.1080306@syss.de> References: <1320753382.2522.21.camel@shane-desktop> <CADEC9BD.65E31%david.freedman@eu.clara.net> <CAFr1is4Dr_u8xuJQ07UhJfjGyeRbPQtO4SgJoq788_vC9__hwA@mail.gmail.com> <4EB923C0.1080306@syss.de> Date: Tue, 8 Nov 2011 15:01:45 +0100 Message-ID: <CAFr1is4WqK+0W8uosxrqmt+Bg6=jm=cHmg81Br6dW3u0+dmqxA@mail.gmail.com> From: virtu virtualabs <virtualabs@gmail.com> To: Micha Borrmann <ripe@syss.de> Content-Type: multipart/alternative; boundary=00163683411e96d9bf04b1399cb1 X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.7 points pts rule name description ---- ---------------------- ------------------------------------ -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.216.44 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (virtualabs[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid X-RIPE-Signature: 91f864e994235b53501ac01e981d4482a1b5af9f5abed9e2d76a1a6bc77740a4 Cc: db-wg@ripe.net Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.6 points pts rule name description
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.216.44 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (virtualabs[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719a1b5af9f5abed9e2d76a1a6bc77740a4 --00163683411e96d9bf04b1399cb1 Content-Type: text/plain; charset=ISO-8859-1 That would mean RIPE NCC did not do anything while people has been aware of this fact since 2 years ? On Tue, Nov 8, 2011 at 1:42 PM, Micha Borrmann <ripe@syss.de> wrote:
Am 08.11.2011 13:14, schrieb virtu virtualabs:
I agree the fact that grabbing all the existing maintainers hashes is completely feasible since I did it during previous days (in order to assess their strength, not to disclose them). I made some tests with the help of a friend of mine, and we recovered at least 4% of these passwords only by testing a very popular wordlist (rockyou), and the recovery process is still running.
We were amazed to see how many maintainers use weak passwords to protect their datas, sometimes using their alias as a password. Therefore, I totally agree with David and would ask that some constraints should be added while creating MD5(UNIX) hashes through RIPE's website dedicated page (https://apps.db.ripe.net/crypt/). This webpage is also recommended by ARIN and modifying the way passwords are hashed (and checked ?) should be better for both RIPE NCC and ARIN.
Telling people not to use twice a generated hash could also help a bit more ;)
My goal is not to recover every possible password from public hashes but just demonstrate that it does not follow currently best-practices in term of security.
This is an old story for myself. It was reported by the german magazin "DER SPIEGEL" two years ago (http://www.spiegel.de/spiegel/print/d-65243798.html).
On Tue, Nov 8, 2011 at 12:58 PM, David Freedman <david.freedman@uk.clara.net <mailto:david.freedman@uk.clara.net>> wrote:
I don't mind it continuing to be used over encrypted channels, as long as the hashes are not available to the general public (as per your previous mail)
I would support a warning phase
Dave.
On 08/11/2011 11:56, "Shane Kerr" <shane@time-travellers.org <mailto:shane@time-travellers.org>> wrote:
>David, > >On Tue, 2011-11-08 at 09:38 +0000, David Freedman wrote: >> I'd like to see auth: MD5-PW deprecated , even though it seems to be >> widely used (for various reasons) >> according to the report by DB presented to us. > >I propose that we deprecate passwords over unencrypted channels. AFAIK >this just means e-mail today, although the web API stuff may also >provide an non-TLS option (I don't know). > >Unlike hiding MD5, this is a major change for users, and would need to >be done with the same caution and preparation as similar large changes >in the past. We could have a warning phase, where anyone using a >password in email would get a scary warning in the reply telling them to >use a more secure scheme (PGP, X.509, webupdates, or database web API). >The RIPE NCC could identify heavy users and help them convert their >tools. And eventually we could flip the switch and turn off plain text >passwords.
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id CF759341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 8 Nov 2011 15:21:06 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RNmXt-0005qG-06; Tue, 08 Nov 2011 15:21:04 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RNmXs-0000mQ-Gk; Tue, 08 Nov 2011 15:21:00 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <nick@inex.ie>) id 1RNmXp-0000mL-3w for db-wg@lists.ripe.net; Tue, 08 Nov 2011 15:20:57 +0100 Received: from mail.acquirer.com ([2a03:8900:0:100::5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <nick@inex.ie>) id 1RNmXm-0002Js-K1 for db-wg@ripe.net; Tue, 08 Nov 2011 15:20:57 +0100 X-Envelope-To: db-wg@ripe.net Received: from cupcake.internal.acquirer.com ([IPv6:2001:1bb8:2004:100:edc2:1a92:b351:8a0]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id pA8ENG7Y086661 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 8 Nov 2011 14:23:17 GMT (envelope-from nick@inex.ie) Message-ID: <4EB93AC5.30600@inex.ie> Date: Tue, 08 Nov 2011 14:20:53 +0000 From: Nick Hilliard <nick@inex.ie> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Shane Kerr <shane@time-travellers.org> References: <CADEA918.65CDA%david.freedman@eu.clara.net> <1320753382.2522.21.camel@shane-desktop> In-Reply-To: <1320753382.2522.21.camel@shane-desktop> X-Enigmail-Version: 1.3.2 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: c60c7c7ca4b8c2fc728c9f2bf07a32f59ec1ccb384f2d6966aae4b3e52af5d53 Cc: "db-wg@ripe.net" <db-wg@ripe.net> Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points
--00163683411e96d9bf04b1399cb1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That would mean RIPE NCC did not do anything while people has been aware of= this fact since 2 years ?<br><br><div class=3D"gmail_quote">On Tue, Nov 8,= 2011 at 1:42 PM, Micha Borrmann <span dir=3D"ltr"><<a href=3D"mailto:ri= pe@syss.de">ripe@syss.de</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">Am 08.11.2011 13:14, schrieb virtu virtuala= bs:<br> <div class=3D"im"><br> > I agree the fact that grabbing all the existing maintainers hashes is<= br> > completely feasible since I did it during previous days =A0(in order t= o<br> > assess their strength, not to disclose them). I made some tests with t= he<br> > help of a friend of mine, and we recovered at least 4% of these<br> > passwords only by testing a very popular wordlist (rockyou), and the<b= r> > recovery process is still running.<br> ><br> > We were amazed to see how many maintainers use weak passwords to prote= ct<br> > their datas, sometimes using their alias as a password. Therefore, I<b= r> > totally agree with David and would ask that some constraints should be= <br> > added while creating MD5(UNIX) hashes through RIPE's website dedic= ated<br> > page (<a href=3D"https://apps.db.ripe.net/crypt/" target=3D"_blank">ht= tps://apps.db.ripe.net/crypt/</a>). This webpage is also recommended<br> > by ARIN and modifying the way passwords are hashed (and checked ?)<br> > should be better for both RIPE NCC and ARIN.<br> ><br> > Telling people not to use twice a generated hash could also help a bit= <br> > more ;)<br> ><br> > My goal is not to recover every possible password from public hashes b= ut<br> > just demonstrate that it does not follow currently best-practices in<b= r> > term of security.<br> <br> </div>This is an old story for myself. It was reported by the german magazi= n<br> "DER SPIEGEL" two years ago<br> (<a href=3D"http://www.spiegel.de/spiegel/print/d-65243798.html" target=3D"= _blank">http://www.spiegel.de/spiegel/print/d-65243798.html</a>).<br> <div class=3D"im HOEnZb"><br> > On Tue, Nov 8, 2011 at 12:58 PM, David Freedman<br> </div><div class=3D"im HOEnZb">> <<a href=3D"mailto:david.freedman@uk= .clara.net">david.freedman@uk.clara.net</a> <mailto:<a href=3D"mailto:da= vid.freedman@uk.clara.net">david.freedman@uk.clara.net</a>>> wrote:<b= r> ><br> > =A0 =A0 I don't mind it continuing to be used over encrypted chann= els,<br> > =A0 =A0 as long as the hashes are not available to the general public = (as<br> > =A0 =A0 per your<br> > =A0 =A0 previous mail)<br> ><br> > =A0 =A0 I would support a warning phase<br> ><br> > =A0 =A0 Dave.<br> ><br> ><br> ><br> > =A0 =A0 On 08/11/2011 11:56, "Shane Kerr" <<a href=3D"mai= lto:shane@time-travellers.org">shane@time-travellers.org</a><br> </div><div class=3D"HOEnZb"><div class=3D"h5">> =A0 =A0 <mailto:<a hr= ef=3D"mailto:shane@time-travellers.org">shane@time-travellers.org</a>>&g= t; wrote:<br> ><br> > =A0 =A0 >David,<br> > =A0 =A0 ><br> > =A0 =A0 >On Tue, 2011-11-08 at 09:38 +0000, David Freedman wrote:<b= r> > =A0 =A0 >> I'd like to see auth: MD5-PW deprecated , even th= ough it seems to be<br> > =A0 =A0 >> widely used (for various reasons)<br> > =A0 =A0 >> according to the report by DB presented to us.<br> > =A0 =A0 ><br> > =A0 =A0 >I propose that we deprecate =A0passwords over unencrypted = channels. AFAIK<br> > =A0 =A0 >this just means e-mail today, although the web API stuff m= ay also<br> > =A0 =A0 >provide an non-TLS option (I don't know).<br> > =A0 =A0 ><br> > =A0 =A0 >Unlike hiding MD5, this is a major change for users, and w= ould need to<br> > =A0 =A0 >be done with the same caution and preparation as similar l= arge changes<br> > =A0 =A0 >in the past. We could have a warning phase, where anyone u= sing a<br> > =A0 =A0 >password in email would get a scary warning in the reply t= elling<br> > =A0 =A0 them to<br> > =A0 =A0 >use a more secure scheme (PGP, X.509, webupdates, or datab= ase web API).<br> > =A0 =A0 >The RIPE NCC could identify heavy users and help them conv= ert their<br> > =A0 =A0 >tools. And eventually we could flip the switch and turn of= f plain text<br> > =A0 =A0 >passwords.<br> <br> <br> </div></div></blockquote></div><br> --00163683411e96d9bf04b1399cb1-- pts rule name description ---- ---------------------- ------------------------------------ -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b835117199ec1ccb384f2d6966aae4b3e52af5d53 On 08/11/2011 11:56, Shane Kerr wrote:
I propose that we deprecate passwords over unencrypted channels. AFAIK this just means e-mail today,
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id C9210341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 8 Nov 2011 15:22:47 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RNmZV-0005wH-Dr; Tue, 08 Nov 2011 15:22:47 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RNmZV-0000nL-4N; Tue, 08 Nov 2011 15:22:41 +0100 Received: from dodo.ipv6.ripe.net ([2001:67c:2e8:23::c100:1704] helo=dodo.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <kranjbar@ripe.net>) id 1RNmZT-0000nG-4A for db-wg@lists.ripe.net; Tue, 08 Nov 2011 15:22:39 +0100 Received: from kranjbar.vpn.ripe.net ([193.0.21.67]) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <kranjbar@ripe.net>) id 1RNmZS-0000OR-Bj for db-wg@ripe.net; Tue, 08 Nov 2011 15:22:38 +0100 From: Kaveh Ranjbar <kranjbar@ripe.net> Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_F5E1418B-FA22-408E-A1D3-256DD9E587E0" Date: Tue, 8 Nov 2011 15:22:37 +0100 In-Reply-To: <CAFr1is4WqK+0W8uosxrqmt+Bg6=jm=cHmg81Br6dW3u0+dmqxA@mail.gmail.com> To: db-wg@ripe.net References: <1320753382.2522.21.camel@shane-desktop> <CADEC9BD.65E31%david.freedman@eu.clara.net> <CAFr1is4Dr_u8xuJQ07UhJfjGyeRbPQtO4SgJoq788_vC9__hwA@mail.gmail.com> <4EB923C0.1080306@syss.de> <CAFr1is4WqK+0W8uosxrqmt+Bg6=jm=cHmg81Br6dW3u0+dmqxA@mail.gmail.com> Message-Id: <D4219035-49E0-4879-A48A-B917687780D7@ripe.net> X-Mailer: Apple Mail (2.1251.1) Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: ---- X-RIPE-Spam-Report: Spam Total Points: -4.1 points
There is always starttls - which RIPE already supports. But you cannot be guaranteed that it is turned on at the client site, or that both sides actually perform validation of each others' certs. Any sensible mail admin will enable it. But I agree - this is something which sorely needs to be done. And the crypto hash should not be visible on whois. And MD5 needs to be prohibited for all future updates. Also, for some light entertainment: https://github.com/juuso/BozoCrack Nick -- Network Ability Ltd. | Chief Technical Officer | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 3864f41e5f687a91347c2a5b835117193f2378eb7600e34dc2146e598824c29d --Apple-Mail=_F5E1418B-FA22-408E-A1D3-256DD9E587E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Dear colleague, Since any change in the current process means significantly changing the = behaviour of the RIPE Database* and will break existing use cases of the = system, it is not something the RIPE NCC can make a decision on.=20 The change should come from and get approved by the community and the = RIPE NCC can then implement it. Obviously we as RIPE NCC can suggest = technical solutions -and that's why we have brought up the issue on = different occasions- but still, agreeing on and implementing them will = require community's consensus. In the mean time we are publishing an article on RIPE Labs outlining the = current situation and highlighting the problem statement as well as = guidelines for mitigating the risk until a full solution is found.=20 We are also adding a password strength indicator to the online MD5 hash = generator as an additional measure. Kind Regards, Kaveh Ranjbar, RIPE Database Group Manager *- As an example, current Update process requires the full object = -including the hashes for maintainer objects- to be used in the update = message. =20 On Nov 8, 2011, at 3:01 PM, virtu virtualabs wrote:
That would mean RIPE NCC did not do anything while people has been = aware of this fact since 2 years ?
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 46C46341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 8 Nov 2011 15:32:11 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RNmiM-0002uH-4J; Tue, 08 Nov 2011 15:31:56 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RNmiL-0000t0-RP; Tue, 08 Nov 2011 15:31:49 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <david.freedman@uk.clara.net>) id 1RNmiI-0000su-2n for db-wg@lists.ripe.net; Tue, 08 Nov 2011 15:31:46 +0100 Received: from staff01.mail.eu.clara.net ([2001:a88:0:fff7::54]) by postgirl.ripe.net with esmtp (Exim 4.72) (envelope-from <david.freedman@uk.clara.net>) id 1RNmiA-0002t1-Sz; Tue, 08 Nov 2011 15:31:46 +0100 Received: from [195.157.10.59] (port=8923 helo=SRVGREXCAS04.claranet.local) by staff01.mail.eu.clara.net (staff01.mail.eu.clara.net [80.168.65.54]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1RNmi9-0000if-3r (return-path <david.freedman@uk.clara.net>); Tue, 08 Nov 2011 14:31:37 +0000 Received: from SRVGREXMB03.claranet.local ([10.75.5.26]) by SRVGREXCAS04.claranet.local ([fe80::95c2:9976:e52:fe51%11]) with mapi id 14.01.0339.001; Tue, 8 Nov 2011 14:31:37 +0000 From: David Freedman <david.freedman@uk.clara.net> To: Kaveh Ranjbar <kranjbar@ripe.net>, "db-wg@ripe.net" <db-wg@ripe.net> Thread-Topic: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database Thread-Index: AQHMniMeQNYCcWULhEiLVHzxPUVaNQ== Date: Tue, 8 Nov 2011 14:31:36 +0000 Message-ID: <CADEEDB7.66015%david.freedman@eu.clara.net> In-Reply-To: <D4219035-49E0-4879-A48A-B917687780D7@ripe.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.18.6.3] Content-Type: multipart/alternative; boundary="_000_CADEEDB766015davidfreedmaneuclaranet_" MIME-Version: 1.0 X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 5aa369f352efcb7801fa06fbb6cba0dd0ac07f7bd24b9fc89a47b0573ec6180f Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id 6C38A341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 8 Nov 2011 15:38:26 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RNmoa-0006LO-Ra; Tue, 08 Nov 2011 15:38:20 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RNmoZ-0000wn-Sh; Tue, 08 Nov 2011 15:38:16 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <nick@inex.ie>) id 1RNmoW-0000wh-RH for db-wg@lists.ripe.net; Tue, 08 Nov 2011 15:38:12 +0100 Received: from mail.acquirer.com ([2a03:8900:0:100::5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <nick@inex.ie>) id 1RNmoV-0003EO-BU for db-wg@ripe.net; Tue, 08 Nov 2011 15:38:12 +0100 X-Envelope-To: david.freedman@uk.clara.net Received: from cupcake.internal.acquirer.com (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id pA8EG5JY086558 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 8 Nov 2011 14:16:06 GMT (envelope-from nick@inex.ie) Message-ID: <4EB93916.1000206@inex.ie> Date: Tue, 08 Nov 2011 14:13:42 +0000 From: Nick Hilliard <nick@inex.ie> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: David Freedman <david.freedman@uk.clara.net> References: <CADEAABD.65CFB%david.freedman@eu.clara.net> In-Reply-To: <CADEAABD.65CFB%david.freedman@eu.clara.net> X-Enigmail-Version: 1.3.2 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: c60c7c7ca4b8c2fc728c9f2bf07a32f54529edabf7c435e7ad7b8a88b0180603 Cc: "db-wg@ripe.net" <db-wg@ripe.net> Subject: Re: [db-wg] Displaying RegID for all resources X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points
--Apple-Mail=_F5E1418B-FA22-408E-A1D3-256DD9E587E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "><div>Dear colleague,</div><div><br></div><div>Since any change in the = current process means significantly changing the behaviour of the RIPE = Database* and will break existing use cases of the system, it is not = something the RIPE NCC can make a decision on. </div><div>The = change should come from and get approved by the community and the RIPE = NCC can then implement it. Obviously we as RIPE NCC can suggest = technical solutions -and that's why we have brought up the issue on = different occasions- but still, agreeing on and implementing them will = require community's consensus.</div><div><br></div><div>In the mean time = we are publishing an article on RIPE Labs outlining the current = situation and highlighting the problem statement as well as guidelines = for mitigating the risk until a full solution is = found. </div><div>We are also adding a password strength indicator = to the online MD5 hash generator as an additional = measure.</div><div><br></div><div>Kind Regards,</div><div>Kaveh = Ranjbar,</div><div>RIPE Database Group = Manager</div><div><br></div><div>*- As an example, current Update = process requires the full object -including the hashes for maintainer = objects- to be used in the update = message.</div><div><br></div><div> <br><div><div>On = Nov 8, 2011, at 3:01 PM, virtu virtualabs wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span = class=3D"Apple-style-span" style=3D"border-collapse: separate; = font-family: Helvetica; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: = none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; font-size: medium; ">That would = mean RIPE NCC did not do anything while people has been aware of this = fact since 2 years ?</span></blockquote></div><br></div></body></html>= --Apple-Mail=_F5E1418B-FA22-408E-A1D3-256DD9E587E0-- pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 3864f41e5f687a91347c2a5b835117190ac07f7bd24b9fc89a47b0573ec6180f --_000_CADEEDB766015davidfreedmaneuclaranet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Looks like I need to get a policy proposal together then=85. From: Kaveh Ranjbar <kranjbar@ripe.net<mailto:kranjbar@ripe.net>> Date: Tue, 8 Nov 2011 15:22:37 +0100 To: <db-wg@ripe.net<mailto:db-wg@ripe.net>> Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 H= ashes in the database Dear colleague, Since any change in the current process means significantly changing the be= haviour of the RIPE Database* and will break existing use cases of the syst= em, it is not something the RIPE NCC can make a decision on. The change should come from and get approved by the community and the RIPE = NCC can then implement it. Obviously we as RIPE NCC can suggest technical s= olutions -and that's why we have brought up the issue on different occasion= s- but still, agreeing on and implementing them will require community's co= nsensus. In the mean time we are publishing an article on RIPE Labs outlining the cu= rrent situation and highlighting the problem statement as well as guideline= s for mitigating the risk until a full solution is found. We are also adding a password strength indicator to the online MD5 hash gen= erator as an additional measure. Kind Regards, Kaveh Ranjbar, RIPE Database Group Manager *- As an example, current Update process requires the full object -includin= g the hashes for maintainer objects- to be used in the update message. On Nov 8, 2011, at 3:01 PM, virtu virtualabs wrote: That would mean RIPE NCC did not do anything while people has been aware of= this fact since 2 years ? --_000_CADEEDB766015davidfreedmaneuclaranet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3FC4EAECB9FB5448AFCABFD2FE0989EA@claranet.local> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 16px; font-fami= ly: Calibri, sans-serif; "> <div>Looks like I need to get a policy proposal together then=85.</div> <div><br> </div> <div><br> </div> <div><br> </div> <span id=3D"OLK_SRC_BODY_SECTION"> <div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b= lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:= 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;= BORDER-RIGHT: medium none; PADDING-TOP: 3pt"> <span style=3D"font-weight:bold">From: </span>Kaveh Ranjbar <<a href=3D"= mailto:kranjbar@ripe.net">kranjbar@ripe.net</a>><br> <span style=3D"font-weight:bold">Date: </span>Tue, 8 Nov 2011 15:22:37 += ;0100<br> <span style=3D"font-weight:bold">To: </span><<a href=3D"mailto:db-wg@rip= e.net">db-wg@ripe.net</a>><br> <span style=3D"font-weight:bold">Subject: </span>Re: [db-wg] Disallowing MD= 5 passwords in e-mail updates, was MD5 Hashes in the database<br> </div> <div><br> </div> <div> <div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line= -break: after-white-space; "> <div>Dear colleague,</div> <div><br> </div> <div>Since any change in the current process means significantly changing t= he behaviour of the RIPE Database* and will break existing use cases of the= system, it is not something the RIPE NCC can make a decision on. </di= v> <div>The change should come from and get approved by the community and the = RIPE NCC can then implement it. Obviously we as RIPE NCC can suggest t= echnical solutions -and that's why we have brought up the issue on differen= t occasions- but still, agreeing on and implementing them will require community's consensus.</div> <div><br> </div> <div>In the mean time we are publishing an article on RIPE Labs outlining t= he current situation and highlighting the problem statement as well as guid= elines for mitigating the risk until a full solution is found. </div> <div>We are also adding a password strength indicator to the online MD5 has= h generator as an additional measure.</div> <div><br> </div> <div>Kind Regards,</div> <div>Kaveh Ranjbar,</div> <div>RIPE Database Group Manager</div> <div><br> </div> <div>*- As an example, current Update process requires the full object -inc= luding the hashes for maintainer objects- to be used in the update message.= </div> <div><br> </div> <div> <br> <div> <div>On Nov 8, 2011, at 3:01 PM, virtu virtualabs wrote:</div> <br class=3D"Apple-interchange-newline"> <blockquote type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-= collapse: separate; font-family: Helvetica; font-style: normal; font-varian= t: normal; font-weight: normal; letter-spacing: normal; line-height: normal= ; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: n= one; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-hori= zontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-dec= orations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stro= ke-width: 0px; font-size: medium; ">That would mean RIPE NCC did not do anything while people has been aware of thi= s fact since 2 years ?</span></blockquote> </div> <br> </div> </div> </div> </span> </body> </html> --_000_CADEEDB766015davidfreedmaneuclaranet_-- pts rule name description ---- ---------------------- ------------------------------------ -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b835117194529edabf7c435e7ad7b8a88b0180603 On 08/11/2011 09:45, David Freedman wrote:
The technical issue concerning publishing , is that using the RegID may not be the best idea, the NCC say "It is for internal use"
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 495F8341A2 for <maillists-archiver-wg+db@ripe.net>; Wed, 9 Nov 2011 10:55:42 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RO4sS-0002Hp-Jy; Wed, 09 Nov 2011 10:55:30 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RO4sS-0001ES-BW; Wed, 09 Nov 2011 10:55:28 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <virtualabs@gmail.com>) id 1RO4sQ-0001EN-2P for db-wg@lists.ripe.net; Wed, 09 Nov 2011 10:55:26 +0100 Received: from mail-qy0-f172.google.com ([209.85.216.172]) by postgirl.ripe.net with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from <virtualabs@gmail.com>) id 1RO4sN-0002HN-Si for db-wg@ripe.net; Wed, 09 Nov 2011 10:55:26 +0100 Received: by qyl16 with SMTP id 16so5231137qyl.17 for <db-wg@ripe.net>; Wed, 09 Nov 2011 01:55:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.34.13 with SMTP id j13mr92988qcd.248.1320832522656; Wed, 09 Nov 2011 01:55:22 -0800 (PST) Received: by 10.229.223.134 with HTTP; Wed, 9 Nov 2011 01:55:22 -0800 (PST) In-Reply-To: <1320831517.13847.32.camel@ntitley-laptop> References: <1320753382.2522.21.camel@shane-desktop> <CADEC9BD.65E31%david.freedman@eu.clara.net> <CAFr1is4Dr_u8xuJQ07UhJfjGyeRbPQtO4SgJoq788_vC9__hwA@mail.gmail.com> <4EB923C0.1080306@syss.de> <CAFr1is4WqK+0W8uosxrqmt+Bg6=jm=cHmg81Br6dW3u0+dmqxA@mail.gmail.com> <1320831517.13847.32.camel@ntitley-laptop> Date: Wed, 9 Nov 2011 10:55:22 +0100 Message-ID: <CAFr1is7KvC6+EqjESa+j5XEtjbbuUhAwLWFBq8z9XrNgwF3Eug@mail.gmail.com> From: virtu virtualabs <virtualabs@gmail.com> To: Nigel Titley <nigel@titley.com> Content-Type: multipart/alternative; boundary=00163683411e521e0d04b14a494b X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.3 points pts rule name description ---- ---------------------- ------------------------------------ -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.216.172 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (virtualabs[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message -0.5 BAYES_05 BODY: Bayes spam probability is 1 to 5% [score: 0.0306] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid X-RIPE-Signature: 91f864e994235b53501ac01e981d4482043293f087b35d797372c69d6d1274d4 Cc: db-wg@ripe.net Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.6 points
for PA resources, this information is already available at: ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt Nick pts rule name description ---- ---------------------- ------------------------------------ -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.216.172 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (virtualabs[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719043293f087b35d797372c69d6d1274d4 --00163683411e521e0d04b14a494b Content-Type: text/plain; charset=ISO-8859-1 So it is up to the community to move from MD5 authentication to stronger authentication methods ? No preventive steps would be taken to avoid MD5 hashes disclosure on the RIPE website ? On Wed, Nov 9, 2011 at 10:38 AM, Nigel Titley <nigel@titley.com> wrote:
On Tue, 2011-11-08 at 15:01 +0100, virtu virtualabs wrote:
That would mean RIPE NCC did not do anything while people has been aware of this fact since 2 years ?
This problem is well known, both by the RIPE DB working group (which is what makes the policy, not the RIPE NCC) and also the RIPE NCC itself. It's been discussed for many years (not just 2) and the use of better authentication methods has been recommended (and have also been available for many years).
However, the community seems to wish to continue to use plain text passwords in emails, together with MD5 hashing.
Nigel
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id DAF52341A2 for <maillists-archiver-wg+db@ripe.net>; Wed, 9 Nov 2011 11:00:32 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RO4x5-00037m-12; Wed, 09 Nov 2011 11:00:19 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RO4x3-0001Ii-G7; Wed, 09 Nov 2011 11:00:13 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <nigel@titley.com>) id 1RO4wt-0001Ia-4y for db-wg@lists.ripe.net; Wed, 09 Nov 2011 11:00:04 +0100 Received: from www.titley.com ([217.146.112.2] helo=thor.titley.com) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <nigel@titley.com>) id 1RO4wq-0002WW-4b for db-wg@ripe.net; Wed, 09 Nov 2011 11:00:03 +0100 Received: from ip-217.146.112.1.merula.net ([217.146.112.1] helo=[192.168.1.101]) by thor.titley.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <nigel@titley.com>) id 1RO4cG-0006BE-91; Wed, 09 Nov 2011 09:38:44 +0000 From: Nigel Titley <nigel@titley.com> To: virtu virtualabs <virtualabs@gmail.com> In-Reply-To: <CAFr1is4WqK+0W8uosxrqmt+Bg6=jm=cHmg81Br6dW3u0+dmqxA@mail.gmail.com> References: <1320753382.2522.21.camel@shane-desktop> <CADEC9BD.65E31%david.freedman@eu.clara.net> <CAFr1is4Dr_u8xuJQ07UhJfjGyeRbPQtO4SgJoq788_vC9__hwA@mail.gmail.com> <4EB923C0.1080306@syss.de> <CAFr1is4WqK+0W8uosxrqmt+Bg6=jm=cHmg81Br6dW3u0+dmqxA@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 09 Nov 2011 09:38:37 +0000 Message-ID: <1320831517.13847.32.camel@ntitley-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: c8ada2009d436c6915e1d123312ab3f229f21a875364f3aecc5cd04d31d52f65 Cc: db-wg@ripe.net Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points
--00163683411e521e0d04b14a494b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So it is up to the community to move from MD5 authentication to stronger au= thentication methods ? No preventive steps would be taken to avoid MD5 hash= es disclosure on the RIPE website ?<br><br><div class=3D"gmail_quote">On We= d, Nov 9, 2011 at 10:38 AM, Nigel Titley <span dir=3D"ltr"><<a href=3D"m= ailto:nigel@titley.com">nigel@titley.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div class=3D"im">On Tue, 2011-11-08 at 15:= 01 +0100, virtu virtualabs wrote:<br> > That would mean RIPE NCC did not do anything while people has been<br> > aware of this fact since 2 years ?<br> <br> </div>This problem is well known, both by the RIPE DB working group (which = is<br> what makes the policy, not the RIPE NCC) and also the RIPE NCC itself.<br> It's been discussed for many years (not just 2) and the use of better<b= r> authentication methods has been recommended (and have also been<br> available for many years).<br> <br> However, the community seems to wish to continue to use plain text<br> passwords in emails, together with MD5 hashing.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> Nigel<br> <br> </font></span></blockquote></div><br> --00163683411e521e0d04b14a494b-- pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b8351171929f21a875364f3aecc5cd04d31d52f65 On Tue, 2011-11-08 at 15:01 +0100, virtu virtualabs wrote:
That would mean RIPE NCC did not do anything while people has been aware of this fact since 2 years ?
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 12390341A2 for <maillists-archiver-wg+db@ripe.net>; Wed, 9 Nov 2011 11:16:14 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RO5CN-0004RI-Qh; Wed, 09 Nov 2011 11:16:09 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RO5CN-0001W3-Ih; Wed, 09 Nov 2011 11:16:03 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <shane@time-travellers.org>) id 1RO5CL-0001Vs-3m for db-wg@lists.ripe.net; Wed, 09 Nov 2011 11:16:01 +0100 Received: from he.time-travellers.nl.eu.org ([62.212.65.17] helo=time-travellers.nl.eu.org) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <shane@time-travellers.org>) id 1RO5CE-0004Qr-TF for db-wg@ripe.net; Wed, 09 Nov 2011 11:16:01 +0100 Received: from s529d1bbf.adsl.wanadoo.nl ([82.157.27.191] helo=[172.29.1.198]) by time-travellers.nl.eu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <shane@time-travellers.org>) id 1RO5C9-000242-0x; Wed, 09 Nov 2011 10:15:49 +0000 From: Shane Kerr <shane@time-travellers.org> To: virtu virtualabs <virtualabs@gmail.com> Date: Wed, 09 Nov 2011 11:15:43 +0100 In-Reply-To: <CAFr1is7KvC6+EqjESa+j5XEtjbbuUhAwLWFBq8z9XrNgwF3Eug@mail.gmail.com> References: <1320753382.2522.21.camel@shane-desktop> <CADEC9BD.65E31%david.freedman@eu.clara.net> <CAFr1is4Dr_u8xuJQ07UhJfjGyeRbPQtO4SgJoq788_vC9__hwA@mail.gmail.com> <4EB923C0.1080306@syss.de> <CAFr1is4WqK+0W8uosxrqmt+Bg6=jm=cHmg81Br6dW3u0+dmqxA@mail.gmail.com> <1320831517.13847.32.camel@ntitley-laptop> <CAFr1is7KvC6+EqjESa+j5XEtjbbuUhAwLWFBq8z9XrNgwF3Eug@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 (3.0.3-1.fc15) Content-Transfer-Encoding: 7bit Message-ID: <1320833749.1993.24.camel@shane-desktop> Mime-Version: 1.0 X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points pts rule name description ---- ---------------------- ------------------------------------ -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 7dbc47838f18b9f91fca9fb4839f56dd10b6123cac2f16094db809e07667ac09 Cc: db-wg@ripe.net Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points
This problem is well known, both by the RIPE DB working group (which is what makes the policy, not the RIPE NCC) and also the RIPE NCC itself. It's been discussed for many years (not just 2) and the use of better authentication methods has been recommended (and have also been available for many years). However, the community seems to wish to continue to use plain text passwords in emails, together with MD5 hashing. Nigel pts rule name description ---- ---------------------- ------------------------------------ -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b8351171910b6123cac2f16094db809e07667ac09 Dear unnamed person, This is not the RIPE NCC's database... they maintain it, and they use it, but it is the RIPE Database - for the entire RIPE community. Still, preventative steps have been taken - if you download the data on maintainers then the passwords are not present. Also, the database limits the volume of queries that users can make, to prevent harvesting that way. These were done with coordination of the RIPE community. The RIPE Database has always been completely public. The idea is that you do not have to trust the RIPE NCC to keep secrets. This protects the RIPE NCC, and it also protects us, the users. It also prevents users accidentally exposing secret information by confusing which parts are public and which are private - it is all public. In my mind there are valid reasons to be concerned with hiding *any* of the RIPE Database, although at the end I think it is the right thing to do. Also, this is mostly a registration database we're talking about here. If records are altered nobody will have their credit card charged, and nobody will lose their allocations; probably the worst case is that someone will be unable to get routed properly for a time. The RIPE Database keeps an entire history of all transactions, so that if authentication was compromised then the invalid changes could be rolled back easily once discovered. (At least this used to be how it works; perhaps that has changed?) There are reasons why the Database is the way it is. It is not the RIPE NCC avoiding responsibility. -- Shane On Wed, 2011-11-09 at 10:55 +0100, virtu virtualabs wrote:
So it is up to the community to move from MD5 authentication to stronger authentication methods ? No preventive steps would be taken to avoid MD5 hashes disclosure on the RIPE website ?
On Wed, Nov 9, 2011 at 10:38 AM, Nigel Titley <nigel@titley.com> wrote: On Tue, 2011-11-08 at 15:01 +0100, virtu virtualabs wrote: > That would mean RIPE NCC did not do anything while people has been > aware of this fact since 2 years ?
This problem is well known, both by the RIPE DB working group (which is what makes the policy, not the RIPE NCC) and also the RIPE NCC itself. It's been discussed for many years (not just 2) and the use of better authentication methods has been recommended (and have also been available for many years).
However, the community seems to wish to continue to use plain text passwords in emails, together with MD5 hashing.
Nigel
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id 9AEB2341A2 for <maillists-archiver-wg+db@ripe.net>; Wed, 9 Nov 2011 11:47:21 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RO5gX-0005wB-OV; Wed, 09 Nov 2011 11:47:17 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RO5gX-0003tD-AQ; Wed, 09 Nov 2011 11:47:13 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <virtualabs@gmail.com>) id 1RO5gV-0003t8-DC for db-wg@lists.ripe.net; Wed, 09 Nov 2011 11:47:11 +0100 Received: from mail-qw0-f44.google.com ([209.85.216.44]) by postgirl.ripe.net with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from <virtualabs@gmail.com>) id 1RO5gT-00063O-Pm for db-wg@ripe.net; Wed, 09 Nov 2011 11:47:11 +0100 Received: by qan41 with SMTP id 41so113978qan.17 for <db-wg@ripe.net>; Wed, 09 Nov 2011 02:47:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.206.132 with SMTP id fu4mr1081959qab.20.1320835628666; Wed, 09 Nov 2011 02:47:08 -0800 (PST) Received: by 10.229.223.134 with HTTP; Wed, 9 Nov 2011 02:47:08 -0800 (PST) In-Reply-To: <1320833749.1993.24.camel@shane-desktop> References: <1320753382.2522.21.camel@shane-desktop> <CADEC9BD.65E31%david.freedman@eu.clara.net> <CAFr1is4Dr_u8xuJQ07UhJfjGyeRbPQtO4SgJoq788_vC9__hwA@mail.gmail.com> <4EB923C0.1080306@syss.de> <CAFr1is4WqK+0W8uosxrqmt+Bg6=jm=cHmg81Br6dW3u0+dmqxA@mail.gmail.com> <1320831517.13847.32.camel@ntitley-laptop> <CAFr1is7KvC6+EqjESa+j5XEtjbbuUhAwLWFBq8z9XrNgwF3Eug@mail.gmail.com> <1320833749.1993.24.camel@shane-desktop> Date: Wed, 9 Nov 2011 11:47:08 +0100 Message-ID: <CAFr1is7WP+oo+EHfb3h_uyDGKeN70=9K4GrmtY6orKHjXMNWEg@mail.gmail.com> From: Damien Cauquil <virtualabs@gmail.com> To: Shane Kerr <shane@time-travellers.org> Content-Type: multipart/alternative; boundary=20cf300e4bf3740f1304b14b020f X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.7 points pts rule name description ---- ---------------------- ------------------------------------ -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.216.44 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (virtualabs[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid X-RIPE-Signature: 91f864e994235b53501ac01e981d4482e58856308d33ef8d6a89ab8beb984b7d Cc: db-wg@ripe.net Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.6 points
pts rule name description ---- ---------------------- ------------------------------------ -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.216.44 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (virtualabs[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719e58856308d33ef8d6a89ab8beb984b7d --20cf300e4bf3740f1304b14b020f Content-Type: text/plain; charset=ISO-8859-1 I see. Thank you for this explanation. Damien On Wed, Nov 9, 2011 at 11:15 AM, Shane Kerr <shane@time-travellers.org>wrote:
Dear unnamed person,
This is not the RIPE NCC's database... they maintain it, and they use it, but it is the RIPE Database - for the entire RIPE community.
Still, preventative steps have been taken - if you download the data on maintainers then the passwords are not present. Also, the database limits the volume of queries that users can make, to prevent harvesting that way. These were done with coordination of the RIPE community.
The RIPE Database has always been completely public. The idea is that you do not have to trust the RIPE NCC to keep secrets. This protects the RIPE NCC, and it also protects us, the users. It also prevents users accidentally exposing secret information by confusing which parts are public and which are private - it is all public. In my mind there are valid reasons to be concerned with hiding *any* of the RIPE Database, although at the end I think it is the right thing to do.
Also, this is mostly a registration database we're talking about here. If records are altered nobody will have their credit card charged, and nobody will lose their allocations; probably the worst case is that someone will be unable to get routed properly for a time. The RIPE Database keeps an entire history of all transactions, so that if authentication was compromised then the invalid changes could be rolled back easily once discovered. (At least this used to be how it works; perhaps that has changed?)
There are reasons why the Database is the way it is. It is not the RIPE NCC avoiding responsibility.
-- Shane
On Wed, 2011-11-09 at 10:55 +0100, virtu virtualabs wrote:
So it is up to the community to move from MD5 authentication to stronger authentication methods ? No preventive steps would be taken to avoid MD5 hashes disclosure on the RIPE website ?
On Wed, Nov 9, 2011 at 10:38 AM, Nigel Titley <nigel@titley.com> wrote: On Tue, 2011-11-08 at 15:01 +0100, virtu virtualabs wrote: > That would mean RIPE NCC did not do anything while people has been > aware of this fact since 2 years ?
This problem is well known, both by the RIPE DB working group (which is what makes the policy, not the RIPE NCC) and also the RIPE NCC itself. It's been discussed for many years (not just 2) and the use of better authentication methods has been recommended (and have also been available for many years).
However, the community seems to wish to continue to use plain text passwords in emails, together with MD5 hashing.
Nigel
--20cf300e4bf3740f1304b14b020f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I see. Thank you for this explanation.=A0<div><br></div><div>Damien<br><br>= <div class=3D"gmail_quote">On Wed, Nov 9, 2011 at 11:15 AM, Shane Kerr <spa= n dir=3D"ltr"><<a href=3D"mailto:shane@time-travellers.org">shane@time-t= ravellers.org</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">Dear unnamed person,<br> <br> This is not the RIPE NCC's database... they maintain it, and they use<b= r> it, but it is the RIPE Database - for the entire RIPE community.<br> <br> Still, preventative steps have been taken - if you download the data on<br> maintainers then the passwords are not present. Also, the database<br> limits the volume of queries that users can make, to prevent harvesting<br> that way. These were done with coordination of the RIPE community.<br> <br> The RIPE Database has always been completely public. The idea is that<br> you do not have to trust the RIPE NCC to keep secrets. This protects the<br=
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 52267341A2 for <maillists-archiver-wg+db@ripe.net>; Wed, 9 Nov 2011 15:37:01 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RO9Gd-0006b3-9p; Wed, 09 Nov 2011 15:36:45 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RO9Gc-0005oK-O1; Wed, 09 Nov 2011 15:36:43 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <nigel@titley.com>) id 1RO9Ga-0005oF-2c for db-wg@lists.ripe.net; Wed, 09 Nov 2011 15:36:40 +0100 Received: from www.titley.com ([217.146.112.2] helo=thor.titley.com) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <nigel@titley.com>) id 1RO9FF-0006Xz-Hp for db-wg@ripe.net; Wed, 09 Nov 2011 15:36:40 +0100 Received: from ip-217.146.112.1.merula.net ([217.146.112.1] helo=[192.168.1.101]) by thor.titley.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <nigel@titley.com>) id 1RO9FE-00076u-H6; Wed, 09 Nov 2011 14:35:16 +0000 From: Nigel Titley <nigel@titley.com> To: virtu virtualabs <virtualabs@gmail.com> In-Reply-To: <CAFr1is7KvC6+EqjESa+j5XEtjbbuUhAwLWFBq8z9XrNgwF3Eug@mail.gmail.com> References: <1320753382.2522.21.camel@shane-desktop> <CADEC9BD.65E31%david.freedman@eu.clara.net> <CAFr1is4Dr_u8xuJQ07UhJfjGyeRbPQtO4SgJoq788_vC9__hwA@mail.gmail.com> <4EB923C0.1080306@syss.de> <CAFr1is4WqK+0W8uosxrqmt+Bg6=jm=cHmg81Br6dW3u0+dmqxA@mail.gmail.com> <1320831517.13847.32.camel@ntitley-laptop> <CAFr1is7KvC6+EqjESa+j5XEtjbbuUhAwLWFBq8z9XrNgwF3Eug@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 09 Nov 2011 14:35:11 +0000 Message-ID: <1320849311.13847.78.camel@ntitley-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: c8ada2009d436c6915e1d123312ab3f276aa580b20e0ce368139a9c0013d16aa Cc: db-wg@ripe.net Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points
RIPE NCC, and it also protects us, the users. It also prevents users<br> accidentally exposing secret information by confusing which parts are<br> public and which are private - it is all public. In my mind there are<br> valid reasons to be concerned with hiding *any* of the RIPE Database,<br> although at the end I think it is the right thing to do.<br> <br> Also, this is mostly a registration database we're talking about here.<= br> If records are altered nobody will have their credit card charged, and<br> nobody will lose their allocations; probably the worst case is that<br> someone will be unable to get routed properly for a time. The RIPE<br> Database keeps an entire history of all transactions, so that if<br> authentication was compromised then the invalid changes could be rolled<br> back easily once discovered. (At least this used to be how it works;<br> perhaps that has changed?)<br> <br> There are reasons why the Database is the way it is. It is not the RIPE<br> NCC avoiding responsibility.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> --<br> Shane<br> </font></span><div class=3D"HOEnZb"><div class=3D"h5"><br> On Wed, 2011-11-09 at 10:55 +0100, virtu virtualabs wrote:<br> > So it is up to the community to move from MD5 authentication to<br> > stronger authentication methods ? No preventive steps would be taken<b= r> > to avoid MD5 hashes disclosure on the RIPE website ?<br> ><br> > On Wed, Nov 9, 2011 at 10:38 AM, Nigel Titley <<a href=3D"mailto:ni= gel@titley.com">nigel@titley.com</a>><br> > wrote:<br> > =A0 =A0 =A0 =A0 On Tue, 2011-11-08 at 15:01 +0100, virtu virtualabs wr= ote:<br> > =A0 =A0 =A0 =A0 > That would mean RIPE NCC did not do anything whil= e people<br> > =A0 =A0 =A0 =A0 has been<br> > =A0 =A0 =A0 =A0 > aware of this fact since 2 years ?<br> ><br> ><br> > =A0 =A0 =A0 =A0 This problem is well known, both by the RIPE DB workin= g group<br> > =A0 =A0 =A0 =A0 (which is<br> > =A0 =A0 =A0 =A0 what makes the policy, not the RIPE NCC) and also the = RIPE NCC<br> > =A0 =A0 =A0 =A0 itself.<br> > =A0 =A0 =A0 =A0 It's been discussed for many years (not just 2) an= d the use of<br> > =A0 =A0 =A0 =A0 better<br> > =A0 =A0 =A0 =A0 authentication methods has been recommended (and have = also<br> > =A0 =A0 =A0 =A0 been<br> > =A0 =A0 =A0 =A0 available for many years).<br> ><br> > =A0 =A0 =A0 =A0 However, the community seems to wish to continue to us= e plain<br> > =A0 =A0 =A0 =A0 text<br> > =A0 =A0 =A0 =A0 passwords in emails, together with MD5 hashing.<br> ><br> > =A0 =A0 =A0 =A0 Nigel<br> ><br> ><br> <br> <br> </div></div></blockquote></div><br></div> --20cf300e4bf3740f1304b14b020f-- pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b8351171976aa580b20e0ce368139a9c0013d16aa On Wed, 2011-11-09 at 10:55 +0100, virtu virtualabs wrote:
So it is up to the community to move from MD5 authentication to stronger authentication methods ? No preventive steps would be taken to avoid MD5 hashes disclosure on the RIPE website ?
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 14AD7341A2 for <maillists-archiver-wg+db@ripe.net>; Wed, 9 Nov 2011 15:39:01 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RO9Ih-0006jJ-8b; Wed, 09 Nov 2011 15:39:00 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RO9Ig-0005pb-Mw; Wed, 09 Nov 2011 15:38:50 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <david.freedman@uk.clara.net>) id 1RO9Ie-0005pW-Qp for db-wg@lists.ripe.net; Wed, 09 Nov 2011 15:38:48 +0100 Received: from staff00.mail.eu.clara.net ([2001:a88:0:fff7::68]) by postgirl.ripe.net with esmtp (Exim 4.72) (envelope-from <david.freedman@uk.clara.net>) id 1RO9IZ-0006j4-T4 for db-wg@ripe.net; Wed, 09 Nov 2011 15:38:48 +0100 Received: from [195.157.10.59] (port=4018 helo=SRVGREXCAS04.claranet.local) by staff00.mail.eu.clara.net (staff00.mail.eu.clara.net [80.168.65.68]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1RO9IY-0008CP-0d (return-path <david.freedman@uk.clara.net>); Wed, 09 Nov 2011 14:38:42 +0000 Received: from SRVGREXMB03.claranet.local ([10.75.5.26]) by SRVGREXCAS04.claranet.local ([fe80::95c2:9976:e52:fe51%11]) with mapi id 14.01.0339.001; Wed, 9 Nov 2011 14:38:42 +0000 From: David Freedman <david.freedman@uk.clara.net> To: Nigel Titley <nigel@titley.com>, virtu virtualabs <virtualabs@gmail.com> Thread-Topic: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database Thread-Index: AQHMnsWypyEJtl7QskqXfDgwu6BOLpWknAaAgAAA+IA= Date: Wed, 9 Nov 2011 14:38:41 +0000 Message-ID: <CAE040D5.6687E%david.freedman@eu.clara.net> In-Reply-To: <1320849311.13847.78.camel@ntitley-laptop> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.18.6.3] Content-Type: text/plain; charset="us-ascii" Content-ID: <6913FE7B2BF0244E9EED0167A10544FA@claranet.local> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5aa369f352efcb7801fa06fbb6cba0dd2815857f201c87e8115e5f358d053167 Cc: "db-wg@ripe.net" <db-wg@ripe.net> Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points
The community has so far decided that it is quite happy with the MD5 disclosure on the web site. If you want to create a policy proposal to change this then please go ahead. I suggest you raise it on this list first of all, then if you see a degree of support enlist the help of the RIPE NCC in creating the proposal (Emilio is the policy officer and will be delighted to help). All the best Nigel pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b835117192815857f201c87e8115e5f358d053167 I have already submitted a pair of policy proposals to the db-wg chairs, am awaiting their response. Dave. On 09/11/2011 14:35, "Nigel Titley" <nigel@titley.com> wrote:
On Wed, 2011-11-09 at 10:55 +0100, virtu virtualabs wrote:
So it is up to the community to move from MD5 authentication to stronger authentication methods ? No preventive steps would be taken to avoid MD5 hashes disclosure on the RIPE website ?
The community has so far decided that it is quite happy with the MD5 disclosure on the web site. If you want to create a policy proposal to change this then please go ahead. I suggest you raise it on this list first of all, then if you see a degree of support enlist the help of the RIPE NCC in creating the proposal (Emilio is the policy officer and will be delighted to help).
All the best
Nigel
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id EA591341A2 for <maillists-archiver-wg+db@ripe.net>; Wed, 9 Nov 2011 15:50:52 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RO9UE-0007K0-9a; Wed, 09 Nov 2011 15:50:50 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RO9UD-0005wQ-DA; Wed, 09 Nov 2011 15:50:45 +0100 Received: from dodo.ipv6.ripe.net ([2001:67c:2e8:23::c100:1704] helo=dodo.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <mir@ripe.net>) id 1RO9U9-0005wL-Gf for db-wg@lists.ripe.net; Wed, 09 Nov 2011 15:50:41 +0100 Received: from mkuhne.vpn.ripe.net ([193.0.21.105] helo=guest110.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from <mir@ripe.net>) id 1RO9U9-0005rs-7R for db-wg@ripe.net; Wed, 09 Nov 2011 15:50:41 +0100 Message-ID: <4EBA9341.8000306@ripe.net> Date: Wed, 09 Nov 2011 15:50:41 +0100 From: Mirjam Kuehne <mir@ripe.net> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: RIPE Database WG <db-wg@ripe.net> References: <4EBA9154.8060202@ripe.net> In-Reply-To: <4EBA9154.8060202@ripe.net> X-Forwarded-Message-Id: <4EBA9154.8060202@ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [db-wg] New article on RIPE Labs: Password Management in RIPE Database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: ---- X-RIPE-Spam-Report: Spam Total Points: -4.1 points
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 9F513341A2 for <maillists-archiver-wg+db@ripe.net>; Wed, 9 Nov 2011 17:08:09 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1ROAgq-0002CC-1c; Wed, 09 Nov 2011 17:07:57 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1ROAgp-0006bB-OB; Wed, 09 Nov 2011 17:07:51 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <virtualabs@gmail.com>) id 1ROAgn-0006b5-5E for db-wg@lists.ripe.net; Wed, 09 Nov 2011 17:07:49 +0100 Received: from mail-qy0-f172.google.com ([209.85.216.172]) by postgirl.ripe.net with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from <virtualabs@gmail.com>) id 1ROAgV-0002BL-8m for db-wg@ripe.net; Wed, 09 Nov 2011 17:07:49 +0100 Received: by qyl16 with SMTP id 16so5612204qyl.17 for <db-wg@ripe.net>; Wed, 09 Nov 2011 08:07:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.206.132 with SMTP id fu4mr2646705qab.20.1320854850144; Wed, 09 Nov 2011 08:07:30 -0800 (PST) Received: by 10.229.223.134 with HTTP; Wed, 9 Nov 2011 08:07:30 -0800 (PST) In-Reply-To: <CAE040D5.6687E%david.freedman@eu.clara.net> References: <1320849311.13847.78.camel@ntitley-laptop> <CAE040D5.6687E%david.freedman@eu.clara.net> Date: Wed, 9 Nov 2011 17:07:30 +0100 Message-ID: <CAFr1is762Ws82mpNr0QwkW1F9E+d3=4Edhq=ciQ-fvsoec1+AA@mail.gmail.com> From: Damien Cauquil <virtualabs@gmail.com> To: David Freedman <david.freedman@uk.clara.net> Content-Type: multipart/alternative; boundary=20cf300e4bf324883c04b14f7cba X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.7 points pts rule name description ---- ---------------------- ------------------------------------ -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.216.172 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (virtualabs[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid X-RIPE-Signature: 91f864e994235b53501ac01e981d4482a79c15b170957f88b3a7e7c565036e00 Cc: "db-wg@ripe.net" <db-wg@ripe.net>, Nigel Titley <nigel@titley.com> Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.6 points
pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b8351171935a138f3dfa48698ab8b364916769c30 Dear colleagues, Please see a new article on RIPE Labs describing some issues with the use of password hashes and what you can do to secure your objects until this has been addressed: https://labs.ripe.net/Members/kranjbar/password-management-in-ripe-database Kind regards, Mirjam Kuehne RIPE NCC pts rule name description ---- ---------------------- ------------------------------------ -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.216.172 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (virtualabs[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719a79c15b170957f88b3a7e7c565036e00 --20cf300e4bf324883c04b14f7cba Content-Type: text/plain; charset=ISO-8859-1
The community has so far decided that it is quite happy with the MD5 disclosure on the web site. If you want to create a policy proposal to change this then please go ahead.
Well, I would be honored but I think creating a policy that would fit the intended goals is out of my comptency domains. I am afraid, I am just a professional penetration tester, not a senior manager. However, it seems David have drafted one or two , maybe should I help by just reviewing the final policy proposal ? Regards, Damien On Wed, Nov 9, 2011 at 3:38 PM, David Freedman <david.freedman@uk.clara.net>wrote:
I have already submitted a pair of policy proposals to the db-wg chairs, am awaiting their response.
Dave.
On 09/11/2011 14:35, "Nigel Titley" <nigel@titley.com> wrote:
On Wed, 2011-11-09 at 10:55 +0100, virtu virtualabs wrote:
So it is up to the community to move from MD5 authentication to stronger authentication methods ? No preventive steps would be taken to avoid MD5 hashes disclosure on the RIPE website ?
The community has so far decided that it is quite happy with the MD5 disclosure on the web site. If you want to create a policy proposal to change this then please go ahead. I suggest you raise it on this list first of all, then if you see a degree of support enlist the help of the RIPE NCC in creating the proposal (Emilio is the policy officer and will be delighted to help).
All the best
Nigel
--20cf300e4bf324883c04b14f7cba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >The community has so far decided that it is quite happy with the MD5<br=
>disclosure on the web site. If you want to create a policy proposal to= <br>>change this then please go ahead.=A0<div><br></div><div>Well, I wou= ld be honored but I think creating a policy that would fit the intended goa= ls is out of my comptency domains. I am afraid, I am just a professional pe= netration tester, not a senior manager.=A0</div> <div>However, it seems David have drafted one or two , maybe should I help = by just reviewing the final policy proposal ?</div><div><br></div><div>Rega= rds,</div><div><br></div><div>Damien=A0</div><div><br><div class=3D"gmail_q= uote"> On Wed, Nov 9, 2011 at 3:38 PM, David Freedman <span dir=3D"ltr"><<a hre= f=3D"mailto:david.freedman@uk.clara.net">david.freedman@uk.clara.net</a>>= ;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex;"> I have already submitted a pair of policy proposals to the db-wg chairs,<br=
am awaiting their response.<br> <br> Dave.<br> <div class=3D"HOEnZb"><div class=3D"h5"><br> <br> On 09/11/2011 14:35, "Nigel Titley" <<a href=3D"mailto:nigel@t= itley.com">nigel@titley.com</a>> wrote:<br> <br> >On Wed, 2011-11-09 at 10:55 +0100, virtu virtualabs wrote:<br> >> So it is up to the community to move from MD5 authentication to<br=
>> stronger authentication methods ? No preventive steps would be tak= en<br> >> to avoid MD5 hashes disclosure on the RIPE website ?<br> ><br> >The community has so far decided that it is quite happy with the MD5<br=
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 51EBD341A2 for <maillists-archiver-wg+db@ripe.net>; Wed, 9 Nov 2011 19:04:33 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1ROCVT-0006Hs-Pm; Wed, 09 Nov 2011 19:04:18 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1ROCVT-0007Y0-Gz; Wed, 09 Nov 2011 19:04:15 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <david.freedman@uk.clara.net>) id 1ROCVQ-0007Xv-Sl for db-wg@lists.ripe.net; Wed, 09 Nov 2011 19:04:13 +0100 Received: from staff00.mail.eu.clara.net ([2001:a88:0:fff7::68]) by postgirl.ripe.net with esmtp (Exim 4.72) (envelope-from <david.freedman@uk.clara.net>) id 1ROCVP-0006Hh-15 for db-wg@ripe.net; Wed, 09 Nov 2011 19:04:12 +0100 Received: from [195.157.10.59] (port=10355 helo=SRVGREXCAS02.claranet.local) by staff00.mail.eu.clara.net (staff00.mail.eu.clara.net [80.168.65.68]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1ROCVL-0003df-1B (return-path <david.freedman@uk.clara.net>); Wed, 09 Nov 2011 18:04:07 +0000 Received: from SRVGREXMB03.claranet.local ([10.75.5.26]) by SRVGREXCAS02.claranet.local ([fe80::cd6a:3120:3174:a299%10]) with mapi id 14.01.0339.001; Wed, 9 Nov 2011 18:04:07 +0000 From: David Freedman <david.freedman@uk.clara.net> To: Shane Kerr <shane@time-travellers.org>, "db-wg@ripe.net" <db-wg@ripe.net> Thread-Topic: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database Thread-Index: AQHMnsWypyEJtl7QskqXfDgwu6BOLpWkU4iAgACC2wA= Date: Wed, 9 Nov 2011 18:04:06 +0000 Message-ID: <CAE070ED.66C1F%david.freedman@eu.clara.net> In-Reply-To: <1320833749.1993.24.camel@shane-desktop> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.18.6.3] Content-Type: text/plain; charset="Windows-1252" Content-ID: <D5441B55251CF04C8F2239CCE97DAE07@claranet.local> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5aa369f352efcb7801fa06fbb6cba0dd8ac7e5abaff57fac6079cdeb02a3ac08 Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points
>disclosure on the web site. If you want to create a policy proposal to<= br> >change this then please go ahead. I suggest you raise it on this list<b= r> >first of all, then if you see a degree of support enlist the help of th= e<br> >RIPE NCC in creating the proposal (Emilio is the policy officer and wil= l<br> >be delighted to help).<br> ><br> >All the best<br> ><br> >Nigel<br> ><br> ><br> ><br> <br> </div></div></blockquote></div><br></div> --20cf300e4bf324883c04b14f7cba-- pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b835117198ac7e5abaff57fac6079cdeb02a3ac08 On 09/11/2011 10:15, "Shane Kerr" <shane@time-travellers.org> wrote:
probably the worst case is that someone will be unable to get routed properly for a time.
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id 1643A341A2 for <maillists-archiver-wg+db@ripe.net>; Thu, 10 Nov 2011 09:04:18 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1ROPcD-0003zL-3N; Thu, 10 Nov 2011 09:04:11 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1ROPcC-0007CV-OL; Thu, 10 Nov 2011 09:04:04 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <prvs=029505d401=ripe@syss.de>) id 1ROPcA-0007CQ-DV for db-wg@lists.ripe.net; Thu, 10 Nov 2011 09:04:02 +0100 Received: from comline1.syss.de ([92.79.151.121]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <prvs=029505d401=ripe@syss.de>) id 1ROPc8-0004iL-Pc for db-wg@ripe.net; Thu, 10 Nov 2011 09:04:02 +0100 Received: from [10.100.1.204] (port=42481 helo=comsrv.syss.admin) by comline1.syss.de with esmtp (Exim 4.69) (envelope-from <ripe@syss.de>) id 1ROPZA-0000Nw-1E for db-wg@ripe.net; Thu, 10 Nov 2011 09:00:56 +0100 Received: from [10.200.1.67] (unknown [10.200.1.67]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by comsrv.syss.admin (Postfix) with ESMTPS id 3E14127776 for <db-wg@ripe.net>; Thu, 10 Nov 2011 08:58:39 +0100 (CET) Message-ID: <4EBB84B7.7010109@syss.de> Date: Thu, 10 Nov 2011 09:00:55 +0100 From: Micha Borrmann <ripe@syss.de> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; de-DE; rv:1.9.2.8) Gecko/20100804 Thunderbird/3.1.2 MIME-Version: 1.0 To: db-wg@ripe.net References: <CAE070ED.66C1F%david.freedman@eu.clara.net> In-Reply-To: <CAE070ED.66C1F%david.freedman@eu.clara.net> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 95d7ff51caeec00c1748d6352f63f5bbf3de19231cef89d55f4932dc5784116a Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points
"Ouch", said the operator=8A pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719f3de19231cef89d55f4932dc5784116a Am 09.11.2011 19:04, schrieb David Freedman:
On 09/11/2011 10:15, "Shane Kerr" <shane@time-travellers.org> wrote: =20
probably the worst case is that someone will be unable to get routed properly for a time. =20 "Ouch", said the operator=A6
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id EF33D341A2 for <maillists-archiver-wg+db@ripe.net>; Thu, 10 Nov 2011 09:53:36 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1ROQNt-0006Vc-AW; Thu, 10 Nov 2011 09:53:23 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1ROQNs-0007by-PZ; Thu, 10 Nov 2011 09:53:20 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <david.kessens@nsn.com>) id 1ROM2l-0005CF-Qk for db-wg@lists.ripe.net; Thu, 10 Nov 2011 05:15:15 +0100 Received: from demumfd002.nsn-inter.net ([93.183.12.31]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <david.kessens@nsn.com>) id 1ROM2i-0006Bs-5P for db-wg@ripe.net; Thu, 10 Nov 2011 05:15:15 +0100 Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pAA3ljqN019347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Nov 2011 04:47:46 +0100 Received: from localhost.localdomain ([10.138.51.24]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pAA3lhwx030860; Thu, 10 Nov 2011 04:47:45 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.5/8.14.5) with ESMTP id pAA3lgQu014158; Wed, 9 Nov 2011 19:47:42 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.5/8.14.5/Submit) id pAA3lfP1014157; Wed, 9 Nov 2011 19:47:41 -0800 Date: Wed, 9 Nov 2011 19:47:41 -0800 From: David Kessens <david.kessens@nsn.com> To: Nigel Titley <nigel@titley.com> Message-ID: <20111110034741.GI9275@nsn.com> References: <1320753382.2522.21.camel@shane-desktop> <CADEC9BD.65E31%david.freedman@eu.clara.net> <CAFr1is4Dr_u8xuJQ07UhJfjGyeRbPQtO4SgJoq788_vC9__hwA@mail.gmail.com> <4EB923C0.1080306@syss.de> <CAFr1is4WqK+0W8uosxrqmt+Bg6=jm=cHmg81Br6dW3u0+dmqxA@mail.gmail.com> <1320831517.13847.32.camel@ntitley-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1320831517.13847.32.camel@ntitley-laptop> User-Agent: Mutt/1.5.21 (2010-09-15) X-RIPE-Spam-Level: ---- X-RIPE-Spam-Report: Spam Total Points: -4.2 points pts rule name description ---- ---------------------- ------------------------------------ -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [93.183.12.31 listed in list.dnswl.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 1ac3c4602a1530a90e7a2e3da08397d757f5951a7bb4f7522867ef9a3b542813 X-Mailman-Approved-At: Thu, 10 Nov 2011 09:53:18 +0100 Cc: db-wg@ripe.net Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: ---- X-RIPE-Spam-Report: Spam Total Points: -4.2 points
with a manipulated reverse DNS zone some email may be tagged as spam, too= . pts rule name description ---- ---------------------- ------------------------------------ -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [93.183.12.31 listed in list.dnswl.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b8351171957f5951a7bb4f7522867ef9a3b542813 On Wed, Nov 09, 2011 at 09:38:37AM +0000, Nigel Titley wrote:
On Tue, 2011-11-08 at 15:01 +0100, virtu virtualabs wrote:
That would mean RIPE NCC did not do anything while people has been aware of this fact since 2 years ?
This problem is well known, both by the RIPE DB working group (which is what makes the policy, not the RIPE NCC) and also the RIPE NCC itself. It's been discussed for many years (not just 2) and the use of better authentication methods has been recommended (and have also been available for many years).
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 79114341A2 for <maillists-archiver-wg+db@ripe.net>; Thu, 10 Nov 2011 11:32:13 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RORvH-0002G8-AB; Thu, 10 Nov 2011 11:32:00 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RORvG-0002Az-TX; Thu, 10 Nov 2011 11:31:54 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <prvs=029505d401=ripe@syss.de>) id 1RORvE-0002Au-Qb for db-wg@lists.ripe.net; Thu, 10 Nov 2011 11:31:52 +0100 Received: from comline1.syss.de ([92.79.151.121]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <prvs=029505d401=ripe@syss.de>) id 1RORvD-0002FL-D4 for db-wg@ripe.net; Thu, 10 Nov 2011 11:31:52 +0100 Received: from [10.100.1.204] (port=50598 helo=comsrv.syss.admin) by comline1.syss.de with esmtp (Exim 4.69) (envelope-from <ripe@syss.de>) id 1RORv3-0005EP-0c for db-wg@ripe.net; Thu, 10 Nov 2011 11:31:41 +0100 Received: from [10.200.1.67] (unknown [10.200.1.67]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by comsrv.syss.admin (Postfix) with ESMTPS id DC33227776 for <db-wg@ripe.net>; Thu, 10 Nov 2011 11:29:23 +0100 (CET) Message-ID: <4EBBA80C.3020201@syss.de> Date: Thu, 10 Nov 2011 11:31:40 +0100 From: Micha Borrmann <ripe@syss.de> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; de-DE; rv:1.9.2.8) Gecko/20100804 Thunderbird/3.1.2 MIME-Version: 1.0 To: db-wg@ripe.net References: <1320753382.2522.21.camel@shane-desktop> <CADEC9BD.65E31%david.freedman@eu.clara.net> <CAFr1is4Dr_u8xuJQ07UhJfjGyeRbPQtO4SgJoq788_vC9__hwA@mail.gmail.com> <4EB923C0.1080306@syss.de> <CAFr1is4WqK+0W8uosxrqmt+Bg6=jm=cHmg81Br6dW3u0+dmqxA@mail.gmail.com> <1320831517.13847.32.camel@ntitley-laptop> <20111110034741.GI9275@nsn.com> In-Reply-To: <20111110034741.GI9275@nsn.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 95d7ff51caeec00c1748d6352f63f5bb5c5dab9d2a96087cd60899dd0c234133 Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points
To put this into some more precisely defined historical perspective, see this presentation (page 11) from 1995: ftp://ftp.ripe.net/ripe/presentations/ripe-m22-david-DB-REPORT.ps.gz We are now 16 years later. Maybe the time has come to address this issue ... David Kessens --- pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b835117195c5dab9d2a96087cd60899dd0c234133 Am 10.11.2011 04:47, schrieb David Kessens:
On Wed, Nov 09, 2011 at 09:38:37AM +0000, Nigel Titley wrote:
On Tue, 2011-11-08 at 15:01 +0100, virtu virtualabs wrote:
That would mean RIPE NCC did not do anything while people has been aware of this fact since 2 years ?
This problem is well known, both by the RIPE DB working group (which is what makes the policy, not the RIPE NCC) and also the RIPE NCC itself. It's been discussed for many years (not just 2) and the use of better authentication methods has been recommended (and have also been available for many years).
To put this into some more precisely defined historical perspective, see this presentation (page 11) from 1995:
ftp://ftp.ripe.net/ripe/presentations/ripe-m22-david-DB-REPORT.ps.gz
We are now 16 years later. Maybe the time has come to address this issue ...
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 569D4341A2 for <maillists-archiver-wg+db@ripe.net>; Fri, 11 Nov 2011 15:25:01 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1ROs2D-0004iw-OP; Fri, 11 Nov 2011 15:24:51 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1ROs2D-0008MS-Dd; Fri, 11 Nov 2011 15:24:49 +0100 Received: from dodo.ipv6.ripe.net ([2001:67c:2e8:23::c100:1704] helo=dodo.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <denis@ripe.net>) id 1ROs2B-0008MK-Ip; Fri, 11 Nov 2011 15:24:47 +0100 Received: from denis.vpn.ripe.net ([193.0.21.59] helo=guest138.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from <denis@ripe.net>) id 1ROs2B-0007Na-DQ; Fri, 11 Nov 2011 15:24:47 +0100 Message-ID: <4EBD302F.80304@ripe.net> Date: Fri, 11 Nov 2011 15:24:47 +0100 From: Denis Walker <denis@ripe.net> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Database WG <db-wg@ripe.net>, NCC Services WG <ncc-services-wg@ripe.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [db-wg] Securing MD5 Hashes in the RIPE Database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: ---- X-RIPE-Spam-Report: Spam Total Points: -4.1 points
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id 48E0B341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 15 Nov 2011 05:36:09 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RQAkQ-00057c-E1; Tue, 15 Nov 2011 05:35:56 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RQAkP-0002oN-TH; Tue, 15 Nov 2011 05:35:49 +0100 Received: from dodo.ipv6.ripe.net ([2001:67c:2e8:23::c100:1704] helo=dodo.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <kranjbar@ripe.net>) id 1RQAkN-0002o9-3a; Tue, 15 Nov 2011 05:35:47 +0100 Received: from kranjbar.vpn.ripe.net ([193.0.21.67]) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <kranjbar@ripe.net>) id 1RQAkM-0006yC-5B; Tue, 15 Nov 2011 05:35:47 +0100 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=koi8-r From: Kaveh Ranjbar <kranjbar@ripe.net> In-Reply-To: <4EBD3F94.7030509@msu.ru> Date: Tue, 15 Nov 2011 05:35:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <CCAA2EC5-FB56-42E6-9202-C7CEC827233D@ripe.net> References: <4EBD302F.80304@ripe.net> <4EBD3F94.7030509@msu.ru> To: Alexander Zubkov <green@msu.ru> X-Mailer: Apple Mail (2.1251.1) Cc: ncc-services-wg@ripe.net, db-wg@ripe.net Subject: Re: [db-wg] [ncc-services-wg] Securing MD5 Hashes in the RIPE Database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: ---- X-RIPE-Spam-Report: Spam Total Points: -4.1 points
=20 Why filter all auth attributes? What if someone will want to use =
it is not well known, but the MNT objects can also be secured using X.509 (S/MIME). pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b8351171905b460cec5349f6cb6eda240ae2cf899 [Apologies for duplicate emails] Dear colleagues, The RIPE NCC has formed a technical solution for the issue of publicly displaying MD5 password hashes in the RIPE Database. The solution includes: * Filtering out of all "auth:" attributes from all query results of MNTNER objects * Displaying MNTNER objects with "auth:" attributes only in Webupdates after password authentication We published an article on RIPE Labs describing the details, including a mockup of the password authentication required by Webupdates: https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database Additionally, we added a basic strength indicator to the password generator: https://apps.db.ripe.net/crypt/crypt.html We look forward to your comments and feedback, either on the Database Working Group mailing list or below the article itself. Kind regards, Denis Walker Business Analyst RIPE NCC Database Group pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719da945711eddbf1570313e5ce668e8eb0 [Sorry for the long reply] Hello Alexander, Thank you for your feedback. If you agree, I would suggest we continue = rest of this discussion in the db-wg mailing list (CCed). On Nov 11, 2011, at 4:30 PM, Alexander Zubkov wrote: public key to send encrypted mail? :)
=20
You are right, we could filter out only the lines with MD5 hashes. The = reasons we have proposed to filter all "auth:" attributes are: a) It is simpler and more straight forward. Think about the new users = who will start using RIPE Database after these changes are made, system = filtering all "auth:" attributes looks like rational behavior but = filtering only some type of "auth:" attributes needs some explanation of = the history. In two years, a lot of us will forget why that was = implemented and then it will be just another behaviour of the system = that we all have to live with :) b) The PGP Key referenced in the "auth:" attribute is not intended to be = used as a pointer to a public-key for email encryption and actually it = shouldn't be used for that purpose. Users might not have access to the = private-key for decrypting emails (for example in automated setups) and = -even if thy have the access- the value is not there to advertise the = public-key. Also note that a MNTNER object is a container. It often contains = credentials for several different people. The holder of the MNTNER = object itself may be different from each of the people with credentials = contained within it. If you encrypt an email based on a PGP credential = contained within a MNTNER object, who would you send that email to? It = is quite likely none of the email addresses in the MNTNER object relate = directly to the person holding that PGP credential. The whole = authentication model of the RIPE Database is complex with many levels of = indirection. For these reasons, if anyone wants a key to be used for encryption users = can be directly referred to the public-key in the database or there can = be references to the public-key in the remarks lines of different = objects, including role objects. But that's just our opinion and point of view, hiding only the MD5 = "auth:" attributes will serve the purpose just as well.
Also what about implementing stronger schemes for plain passwords like = SHA-256,512?
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 414AD341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 15 Nov 2011 10:15:54 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RQF76-0000mV-EC; Tue, 15 Nov 2011 10:15:36 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RQF75-0005FY-SJ; Tue, 15 Nov 2011 10:15:32 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <green@msu.ru>) id 1RQF72-0005FT-3P for db-wg@lists.ripe.net; Tue, 15 Nov 2011 10:15:28 +0100 Received: from pigeon.msu.net ([2a00:f480:0:102::1c]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <green@msu.ru>) id 1RQF6z-0000mA-P1 for db-wg@ripe.net; Tue, 15 Nov 2011 10:15:28 +0100 Received: (qmail 26604 invoked from network); 15 Nov 2011 09:08:43 -0000 Received: from unknown (HELO ?IPv6:2a00:f480:0:2::1:32?) (2a00:f480:0:2::1:32) by pigeon.msu.net with ESMTPS (DHE-RSA-CAMELLIA256-SHA encrypted); 15 Nov 2011 09:08:43 -0000 Message-ID: <4EC22C1B.10009@msu.ru> Date: Tue, 15 Nov 2011 13:08:43 +0400 From: Alexander Zubkov <green@msu.ru> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Kaveh Ranjbar <kranjbar@ripe.net> References: <4EBD302F.80304@ripe.net> <4EBD3F94.7030509@msu.ru> <CCAA2EC5-FB56-42E6-9202-C7CEC827233D@ripe.net> In-Reply-To: <CCAA2EC5-FB56-42E6-9202-C7CEC827233D@ripe.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-ClamFilter-Status: No X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: e72d347eaef9ca06106f34f87283d21dcff293d4540bf59a63d9c0dc41f21ed7 Cc: db-wg@ripe.net Subject: Re: [db-wg] [ncc-services-wg] Securing MD5 Hashes in the RIPE Database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points
I can see two different scenarios here: 1- We use different hash function and keep the keys published, In this = case: a) This still leaves the door open for dictionary attacks. A = strong hash does not help with a weak password. b) Processing power is constantly improving. We started with = CRYPT-PW until it was considered to be week and was replaced with MD5. = Now SHA 256/512 is a strong hashing function, but this might not be the = case in 5 years. c) Experience has shown it takes years for users to change data. = When we switched from CRYPT-PW to MD5 we allowed about a year for users = to upgrade. At the end of that period we still had to lock many MNTNER = objects that still only had CRYPT-PW. d) We didn't find any business case for keeping the hashes = public. 2- Another scenario could be the case that we use different hash = function and still go ahead and hide the hashes, hence in practice we = use different hashing system for internal storage of password hashes a) It is definitely good idea and the way to go, after hiding = the hashes we should think about making the internal storage more = secure. b) In long term we may suggest moving the authentication to a = system specifically designed for this purpose, for example RIPE Access. = That system might even use HSMs to keep hashes safe but it will be that = system's responsibility. Again, this is just clarifying our line of thinking for making that = technical proposal, we might have missed something or our assumptions = might be wrong, that's why we need community's feedback on the issue. And to emphasize Peter Koch's comments at RIPE 63's Database Session, = there is a need to take a look at the bigger picture as well. This = proposal only addresses publication of MD5 hashes. The issue of clear = text password transport over email is still open and there might be = other issues as well and that's why a security analysis of the whole = process is useful and needed. Thank you again for contributing to the subject. Kind Regards, Kaveh. --- Kaveh Ranjbar, Database Group Manager, RIPE NCC= pts rule name description ---- ---------------------- ------------------------------------ -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719cff293d4540bf59a63d9c0dc41f21ed7
You are right, we could filter out only the lines with MD5 hashes. The reasons we have proposed to filter all "auth:" attributes are:
You are right. Here pros and cons is on the side of hiding all auth attributes.
Also what about implementing stronger schemes for plain passwords like SHA-256,512?
I can see two different scenarios here:
1- We use different hash function and keep the keys published, In this case:
a) This still leaves the door open for dictionary attacks. A strong hash does not help with a weak password.
b) Processing power is constantly improving. We started with CRYPT-PW until it was considered to be week and was replaced with MD5. Now SHA 256/512 is a strong hashing function, but this might not be the case in 5 years.
c) Experience has shown it takes years for users to change data. When we switched from CRYPT-PW to MD5 we allowed about a year for users to upgrade. At the end of that period we still had to lock many MNTNER objects that still only had CRYPT-PW.
But this fact should not be stopper for implementing this for other users, which think a little more about security. :) By the way, if there is desire to force switching of hash scheme. This could be done during password updates. During update RIPE DB server is receiving plain password and can replace corresponding MD5 field "automagically".
d) We didn't find any business case for keeping the hashes public.
2- Another scenario could be the case that we use different hash function and still go ahead and hide the hashes, hence in practice we use different hashing system for internal storage of password hashes
a) It is definitely good idea and the way to go, after hiding the hashes we should think about making the internal storage more secure.
b) In long term we may suggest moving the authentication to a system specifically designed for this purpose, for example RIPE Access. That system might even use HSMs to keep hashes safe but it will be that system's responsibility.
There is also couple of things, I think should be discussed. 1) When object is being updated, the copy of it is sent by e-mail. This copy contains unfiltered object. For this case stronger hashing scheme should be preferred to for various reasons (mail interception, when object is sent to internal mail list where only some should know password). 2) Proposed updating procedure (when one should enter password to see unfiltered object) prevents updating object that is covered by other types of auth attributes too. For example if we have mntner object, which is maintained by mntner that have MD5-PW and PGP-KEY auth. And we have only PGP-KEY and want to modify the object, then we will be unable to do so, because we will not get unfiltered object without knowing password. Even more, if maintainer object with MD5-PW is protected by separate maintainer object, which have only KEY auth, this pocedure will be broken too.
Again, this is just clarifying our line of thinking for making that technical proposal, we might have missed something or our assumptions might be wrong, that's why we need community's feedback on the issue.
And to emphasize Peter Koch's comments at RIPE 63's Database Session, there is a need to take a look at the bigger picture as well. This proposal only addresses publication of MD5 hashes. The issue of clear text password transport over email is still open and there might be other issues as well and that's why a security analysis of the whole process is useful and needed.
Thank you again for contributing to the subject.
Kind Regards, Kaveh.
--- Kaveh Ranjbar, Database Group Manager, RIPE NCC
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id 7EF6F341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 15 Nov 2011 10:31:45 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RQFMW-00029K-MJ; Tue, 15 Nov 2011 10:31:32 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RQFMW-0005Nz-BI; Tue, 15 Nov 2011 10:31:28 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <green@msu.ru>) id 1RQFMS-0005Nu-Na for db-wg@lists.ripe.net; Tue, 15 Nov 2011 10:31:24 +0100 Received: from pigeon.msu.net ([2a00:f480:0:102::1c]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <green@msu.ru>) id 1RQFMR-0001Ty-7Y for db-wg@ripe.net; Tue, 15 Nov 2011 10:31:24 +0100 Received: (qmail 6654 invoked from network); 15 Nov 2011 09:31:22 -0000 Received: from unknown (HELO ?IPv6:2a00:f480:0:2::1:32?) (2a00:f480:0:2::1:32) by pigeon.msu.net with ESMTPS (DHE-RSA-CAMELLIA256-SHA encrypted); 15 Nov 2011 09:31:22 -0000 Message-ID: <4EC23169.1020800@msu.ru> Date: Tue, 15 Nov 2011 13:31:21 +0400 From: Alexander Zubkov <green@msu.ru> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: db-wg@ripe.net Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-ClamFilter-Status: No X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: e72d347eaef9ca06106f34f87283d21d5d0d65284aa6a211840bb20260229537 Subject: Re: [db-wg] Disallowing MD5 passwords in e-mail updates, was MD5 Hashes in the database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points pts rule name description
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b835117195d0d65284aa6a211840bb20260229537
There is always starttls - which RIPE already supports. But you cannot be guaranteed that it is turned on at the client site, or that both sides actually perform validation of each others' certs. Any sensible mail admin will enable it.
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id 1E603341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 15 Nov 2011 11:22:10 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RQG9Q-0003Cq-9w; Tue, 15 Nov 2011 11:22:02 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RQG9P-0005rI-Hy; Tue, 15 Nov 2011 11:21:59 +0100 Received: from dodo.ipv6.ripe.net ([2001:67c:2e8:23::c100:1704] helo=dodo.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <denis@ripe.net>) id 1RQG9N-0005rD-4x for db-wg@lists.ripe.net; Tue, 15 Nov 2011 11:21:57 +0100 Received: from denis.vpn.ripe.net ([193.0.21.59] helo=guest138.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from <denis@ripe.net>) id 1RQG9M-0002em-Oq; Tue, 15 Nov 2011 11:21:56 +0100 Message-ID: <4EC23D44.4050107@ripe.net> Date: Tue, 15 Nov 2011 11:21:56 +0100 From: Denis Walker <denis@ripe.net> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Alexander Zubkov <green@msu.ru> References: <4EBD302F.80304@ripe.net> <4EBD3F94.7030509@msu.ru> <CCAA2EC5-FB56-42E6-9202-C7CEC827233D@ripe.net> <4EC22C1B.10009@msu.ru> In-Reply-To: <4EC22C1B.10009@msu.ru> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Kaveh Ranjbar <kranjbar@ripe.net>, db-wg@ripe.net Subject: Re: [db-wg] [ncc-services-wg] Securing MD5 Hashes in the RIPE Database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: ---- X-RIPE-Spam-Report: Spam Total Points: -4.1 points
Problem with sending mail securely to RIPE DB's server can be solved with encrypted e-mail. But as I know, there is no this possibility yet. I think this is more reliable way, then making sure mail will go in SSL channels all way long. In addition, crypted mail and TLS connections are not preventing each other. And can be used together. :) pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719cc8f706fba86343824f26f0dd50cfcc2 On 15/11/11:47 10:08 AM, Alexander Zubkov wrote:
You are right, we could filter out only the lines with MD5 hashes. The reasons we have proposed to filter all "auth:" attributes are:
You are right. Here pros and cons is on the side of hiding all auth attributes.
Also what about implementing stronger schemes for plain passwords like SHA-256,512?
I can see two different scenarios here:
1- We use different hash function and keep the keys published, In this case:
a) This still leaves the door open for dictionary attacks. A strong hash does not help with a weak password.
b) Processing power is constantly improving. We started with CRYPT-PW until it was considered to be week and was replaced with MD5. Now SHA 256/512 is a strong hashing function, but this might not be the case in 5 years.
c) Experience has shown it takes years for users to change data. When we switched from CRYPT-PW to MD5 we allowed about a year for users to upgrade. At the end of that period we still had to lock many MNTNER objects that still only had CRYPT-PW.
But this fact should not be stopper for implementing this for other users, which think a little more about security. :) By the way, if there is desire to force switching of hash scheme. This could be done during password updates. During update RIPE DB server is receiving plain password and can replace corresponding MD5 field "automagically".
This would work if all the data was regularly updated. A lot of the data in the RIPE Database is static. It is still in use and is still correct. But it is not changed for years.
d) We didn't find any business case for keeping the hashes public.
2- Another scenario could be the case that we use different hash function and still go ahead and hide the hashes, hence in practice we use different hashing system for internal storage of password hashes
a) It is definitely good idea and the way to go, after hiding the hashes we should think about making the internal storage more secure.
b) In long term we may suggest moving the authentication to a system specifically designed for this purpose, for example RIPE Access. That system might even use HSMs to keep hashes safe but it will be that system's responsibility.
There is also couple of things, I think should be discussed.
1) When object is being updated, the copy of it is sent by e-mail. This copy contains unfiltered object. For this case stronger hashing scheme should be preferred to for various reasons (mail interception, when object is sent to internal mail list where only some should know password).
I presume here you refer to updating the MNTNER object. If this is done by Webupdates or by using the API it will be sent over HTTPS. We could recommend as a best practise (or even enforce if required) that MNTNER objects are not updated by email. Then the hash will never be exposed.
2) Proposed updating procedure (when one should enter password to see unfiltered object) prevents updating object that is covered by other types of auth attributes too. For example if we have mntner object, which is maintained by mntner that have MD5-PW and PGP-KEY auth. And we have only PGP-KEY and want to modify the object, then we will be unable to do so, because we will not get unfiltered object without knowing password. Even more, if maintainer object with MD5-PW is protected by separate maintainer object, which have only KEY auth, this pocedure will be broken too.
These are the two corner cases we highlighted in the article on RIPE Labs. In the first example the person with the password will have to take the responsibility for maintaining the MNTNER object. If a MNTNER object has two credentials, which both allow the same data to be updated, we assume there must be some business relationship between the two people who use those credentials. In the second example the separate MNTNER object with only PGP will need to add a password in order to update the first MNTNER object. Regards Denis Walker Business Analyst RIPE NCC Database Group
Again, this is just clarifying our line of thinking for making that technical proposal, we might have missed something or our assumptions might be wrong, that's why we need community's feedback on the issue.
And to emphasize Peter Koch's comments at RIPE 63's Database Session, there is a need to take a look at the bigger picture as well. This proposal only addresses publication of MD5 hashes. The issue of clear text password transport over email is still open and there might be other issues as well and that's why a security analysis of the whole process is useful and needed.
Thank you again for contributing to the subject.
Kind Regards, Kaveh.
--- Kaveh Ranjbar, Database Group Manager, RIPE NCC
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id 83F30341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 15 Nov 2011 13:27:25 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RQI6X-0005ug-SG; Tue, 15 Nov 2011 13:27:13 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RQI6X-0006yg-BK; Tue, 15 Nov 2011 13:27:09 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <green@msu.ru>) id 1RQI6T-0006yb-Ee for db-wg@lists.ripe.net; Tue, 15 Nov 2011 13:27:05 +0100 Received: from pigeon.msu.net ([2a00:f480:0:102::1c]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <green@msu.ru>) id 1RQI6Q-0000p3-11 for db-wg@ripe.net; Tue, 15 Nov 2011 13:27:05 +0100 Received: (qmail 22242 invoked from network); 15 Nov 2011 12:27:01 -0000 Received: from unknown (HELO ?IPv6:2a00:f480:0:2::1:32?) (2a00:f480:0:2::1:32) by pigeon.msu.net with ESMTPS (DHE-RSA-CAMELLIA256-SHA encrypted); 15 Nov 2011 12:27:01 -0000 Message-ID: <4EC25A94.2080107@msu.ru> Date: Tue, 15 Nov 2011 16:27:00 +0400 From: Alexander Zubkov <green@msu.ru> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Denis Walker <denis@ripe.net> References: <4EBD302F.80304@ripe.net> <4EBD3F94.7030509@msu.ru> <CCAA2EC5-FB56-42E6-9202-C7CEC827233D@ripe.net> <4EC22C1B.10009@msu.ru> <4EC23D44.4050107@ripe.net> In-Reply-To: <4EC23D44.4050107@ripe.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-ClamFilter-Status: No X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: e72d347eaef9ca06106f34f87283d21def85c921f47c1b2c3a4ebf40302cdd0a Cc: Kaveh Ranjbar <kranjbar@ripe.net>, db-wg@ripe.net Subject: Re: [db-wg] [ncc-services-wg] Securing MD5 Hashes in the RIPE Database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points
pts rule name description ---- ---------------------- ------------------------------------ -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719ef85c921f47c1b2c3a4ebf40302cdd0a On 11/15/2011 02:21 PM, Denis Walker wrote:
On 15/11/11:47 10:08 AM, Alexander Zubkov wrote:
You are right, we could filter out only the lines with MD5 hashes. The reasons we have proposed to filter all "auth:" attributes are:
You are right. Here pros and cons is on the side of hiding all auth attributes.
Also what about implementing stronger schemes for plain passwords like SHA-256,512?
I can see two different scenarios here:
1- We use different hash function and keep the keys published, In this case:
a) This still leaves the door open for dictionary attacks. A strong hash does not help with a weak password.
b) Processing power is constantly improving. We started with CRYPT-PW until it was considered to be week and was replaced with MD5. Now SHA 256/512 is a strong hashing function, but this might not be the case in 5 years.
c) Experience has shown it takes years for users to change data. When we switched from CRYPT-PW to MD5 we allowed about a year for users to upgrade. At the end of that period we still had to lock many MNTNER objects that still only had CRYPT-PW.
But this fact should not be stopper for implementing this for other users, which think a little more about security. :) By the way, if there is desire to force switching of hash scheme. This could be done during password updates. During update RIPE DB server is receiving plain password and can replace corresponding MD5 field "automagically".
This would work if all the data was regularly updated. A lot of the data in the RIPE Database is static. It is still in use and is still correct. But it is not changed for years.
1) If we do not want to enforce security to others. Then it is there fault that they using weak password schemes, passwords at all, etc... You, I and other people shouldn't care at all. 2) If we wish to enhance security, i.e. take care of people, who don't mind about it. Than this feature, of course, will not fix those, who not updating database. But is it bad because of this? No, it will take care of some people, will not harm others and this is good. :) Also this will reduce number of mails: "You are using obsolete password hash. Change it or you will be deleted". This is less work anyway.
d) We didn't find any business case for keeping the hashes public.
2- Another scenario could be the case that we use different hash function and still go ahead and hide the hashes, hence in practice we use different hashing system for internal storage of password hashes
a) It is definitely good idea and the way to go, after hiding the hashes we should think about making the internal storage more secure.
b) In long term we may suggest moving the authentication to a system specifically designed for this purpose, for example RIPE Access. That system might even use HSMs to keep hashes safe but it will be that system's responsibility.
There is also couple of things, I think should be discussed.
1) When object is being updated, the copy of it is sent by e-mail. This copy contains unfiltered object. For this case stronger hashing scheme should be preferred to for various reasons (mail interception, when object is sent to internal mail list where only some should know password).
I presume here you refer to updating the MNTNER object. If this is done by Webupdates or by using the API it will be sent over HTTPS. We could recommend as a best practise (or even enforce if required) that MNTNER objects are not updated by email. Then the hash will never be exposed.
May be I'm doing something wrong, but when I updating objects through web, I receive result in the browser and by e-mail too. This is handled by udp-to and mnt-nfy attributes, for example. So it is one more way of hash exposure.
2) Proposed updating procedure (when one should enter password to see unfiltered object) prevents updating object that is covered by other types of auth attributes too. For example if we have mntner object, which is maintained by mntner that have MD5-PW and PGP-KEY auth. And we have only PGP-KEY and want to modify the object, then we will be unable to do so, because we will not get unfiltered object without knowing password. Even more, if maintainer object with MD5-PW is protected by separate maintainer object, which have only KEY auth, this pocedure will be broken too.
These are the two corner cases we highlighted in the article on RIPE Labs.
In the first example the person with the password will have to take the responsibility for maintaining the MNTNER object. If a MNTNER object has two credentials, which both allow the same data to be updated, we assume there must be some business relationship between the two people who use those credentials.
This is limiting users in the ways they can maintain there objects. You say "password there => password only for this case", which is bad. And when there is no password at all, "auth:" will be filtered anyway and one should remember what it looks like to update it. On business relationship... what if man with password is on vacation or sick, or it turned to evil?
In the second example the separate MNTNER object with only PGP will need to add a password in order to update the first MNTNER object.
Sounds like workaround, not solution. Also, "MNTNER object with only PGP" can be in sutuation where ha can not "add a password", because it is maintained by third maintainer. :)
Regards Denis Walker Business Analyst RIPE NCC Database Group
Again, this is just clarifying our line of thinking for making that technical proposal, we might have missed something or our assumptions might be wrong, that's why we need community's feedback on the issue.
And to emphasize Peter Koch's comments at RIPE 63's Database Session, there is a need to take a look at the bigger picture as well. This proposal only addresses publication of MD5 hashes. The issue of clear text password transport over email is still open and there might be other issues as well and that's why a security analysis of the whole process is useful and needed.
Thank you again for contributing to the subject.
Kind Regards, Kaveh.
--- Kaveh Ranjbar, Database Group Manager, RIPE NCC
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id B63F0341A2 for <maillists-archiver-wg+db@ripe.net>; Tue, 15 Nov 2011 14:36:50 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RQJBe-0007KN-7j; Tue, 15 Nov 2011 14:36:36 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RQJBd-0007Zk-WC; Tue, 15 Nov 2011 14:36:30 +0100 Received: from dodo.ipv6.ripe.net ([2001:67c:2e8:23::c100:1704] helo=dodo.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <denis@ripe.net>) id 1RQJBc-0007Ze-Iz for db-wg@lists.ripe.net; Tue, 15 Nov 2011 14:36:28 +0100 Received: from denis.vpn.ripe.net ([193.0.21.59] helo=guest138.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from <denis@ripe.net>) id 1RQJBb-0006ca-Ls; Tue, 15 Nov 2011 14:36:27 +0100 Message-ID: <4EC26ADB.9000505@ripe.net> Date: Tue, 15 Nov 2011 14:36:27 +0100 From: Denis Walker <denis@ripe.net> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Alexander Zubkov <green@msu.ru> References: <4EBD302F.80304@ripe.net> <4EBD3F94.7030509@msu.ru> <CCAA2EC5-FB56-42E6-9202-C7CEC827233D@ripe.net> <4EC22C1B.10009@msu.ru> <4EC23D44.4050107@ripe.net> <4EC25A94.2080107@msu.ru> In-Reply-To: <4EC25A94.2080107@msu.ru> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Kaveh Ranjbar <kranjbar@ripe.net>, db-wg@ripe.net Subject: Re: [db-wg] [ncc-services-wg] Securing MD5 Hashes in the RIPE Database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: ---- X-RIPE-Spam-Report: Spam Total Points: -4.1 points
pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b835117196e7287f9e08e971796a3b8c4c3a51464 On 15/11/11:47 1:27 PM, Alexander Zubkov wrote:
On 11/15/2011 02:21 PM, Denis Walker wrote:
On 15/11/11:47 10:08 AM, Alexander Zubkov wrote:
You are right, we could filter out only the lines with MD5 hashes. The reasons we have proposed to filter all "auth:" attributes are:
You are right. Here pros and cons is on the side of hiding all auth attributes.
Also what about implementing stronger schemes for plain passwords like SHA-256,512?
I can see two different scenarios here:
1- We use different hash function and keep the keys published, In this case:
a) This still leaves the door open for dictionary attacks. A strong hash does not help with a weak password.
b) Processing power is constantly improving. We started with CRYPT-PW until it was considered to be week and was replaced with MD5. Now SHA 256/512 is a strong hashing function, but this might not be the case in 5 years.
c) Experience has shown it takes years for users to change data. When we switched from CRYPT-PW to MD5 we allowed about a year for users to upgrade. At the end of that period we still had to lock many MNTNER objects that still only had CRYPT-PW.
But this fact should not be stopper for implementing this for other users, which think a little more about security. :) By the way, if there is desire to force switching of hash scheme. This could be done during password updates. During update RIPE DB server is receiving plain password and can replace corresponding MD5 field "automagically".
This would work if all the data was regularly updated. A lot of the data in the RIPE Database is static. It is still in use and is still correct. But it is not changed for years.
1) If we do not want to enforce security to others. Then it is there fault that they using weak password schemes, passwords at all, etc... You, I and other people shouldn't care at all.
2) If we wish to enhance security, i.e. take care of people, who don't mind about it. Than this feature, of course, will not fix those, who not updating database. But is it bad because of this? No, it will take care of some people, will not harm others and this is good. :) Also this will reduce number of mails: "You are using obsolete password hash. Change it or you will be deleted". This is less work anyway.
It is in everyone's interest for the RIPE Database to be a reliable source of trusted information. When there is a significant improvement made to security this should be rolled out to all users as soon as possible. This should also apply to a user who may not be too concerned themselves with the level of security of data. What we did with the CRYPT-PW -> MD5 change was to allow a period of time for users to make the upgrade themselves. After that period we auto generated new MD5 passwords for all MNTNER objects still containing CRYPT-PW. We then provided a web service so anyone who knew the original CRYPT-PW password that we removed could use it to obtain the new auto generated MD5 password. This password recovery phase lasted for several years, but at least all the passwords had been upgraded to MD5 at the start of it.
d) We didn't find any business case for keeping the hashes public.
2- Another scenario could be the case that we use different hash function and still go ahead and hide the hashes, hence in practice we use different hashing system for internal storage of password hashes
a) It is definitely good idea and the way to go, after hiding the hashes we should think about making the internal storage more secure.
b) In long term we may suggest moving the authentication to a system specifically designed for this purpose, for example RIPE Access. That system might even use HSMs to keep hashes safe but it will be that system's responsibility.
There is also couple of things, I think should be discussed.
1) When object is being updated, the copy of it is sent by e-mail. This copy contains unfiltered object. For this case stronger hashing scheme should be preferred to for various reasons (mail interception, when object is sent to internal mail list where only some should know password).
I presume here you refer to updating the MNTNER object. If this is done by Webupdates or by using the API it will be sent over HTTPS. We could recommend as a best practise (or even enforce if required) that MNTNER objects are not updated by email. Then the hash will never be exposed.
May be I'm doing something wrong, but when I updating objects through web, I receive result in the browser and by e-mail too. This is handled by udp-to and mnt-nfy attributes, for example. So it is one more way of hash exposure.
The "upd-to:" and "mnt-nfy:" attributes are only used when data objects are changed that are maintained by this MNTNER object. However if the MNTNER object has a "notify:" attribute then any change to the MNTNER object itself will result in an email containing the details of the change. We omitted to mention this in the technical proposal but our plan is to filter the objects shown in these notifications. Where the change is to the credentials of the MNTNER object we can also add a comment in the notification that the credentials have changed.
2) Proposed updating procedure (when one should enter password to see unfiltered object) prevents updating object that is covered by other types of auth attributes too. For example if we have mntner object, which is maintained by mntner that have MD5-PW and PGP-KEY auth. And we have only PGP-KEY and want to modify the object, then we will be unable to do so, because we will not get unfiltered object without knowing password. Even more, if maintainer object with MD5-PW is protected by separate maintainer object, which have only KEY auth, this pocedure will be broken too.
These are the two corner cases we highlighted in the article on RIPE Labs.
In the first example the person with the password will have to take the responsibility for maintaining the MNTNER object. If a MNTNER object has two credentials, which both allow the same data to be updated, we assume there must be some business relationship between the two people who use those credentials.
This is limiting users in the ways they can maintain there objects. You say "password there => password only for this case", which is bad. And when there is no password at all, "auth:" will be filtered anyway and one should remember what it looks like to update it. On business relationship... what if man with password is on vacation or sick, or it turned to evil?
If there is no password at all in the MNTNER object the "auth:" attributes will not be filtered in Webupdates and no password will be asked for in order to display the object. There is no requirement for the maintainer of a MNTNER object to be one of the people who have credentials listed in the MNTNER object and it can be a separate MNTNER object. So if the maintainer of a MNTNER object is on vacation and you want to change your password or PGP key right now with the present system there is nothing you can do. As we said in the article on RIPE Labs, the authentication model used by the RIPE Database is complex with many levels of indirection. If there was a simple solution to this problem that covered all possible issues we would have done it years ago. Working within the current design we want the best possible solution to this one issue that covers the majority of use cases and acceptable workarounds for the corner cases that can be implemented in a relatively short time period. Regards Denis Walker Business Analyst RIPE NCC Database Group
In the second example the separate MNTNER object with only PGP will need to add a password in order to update the first MNTNER object.
Sounds like workaround, not solution. Also, "MNTNER object with only PGP" can be in sutuation where ha can not "add a password", because it is maintained by third maintainer. :)
Regards Denis Walker Business Analyst RIPE NCC Database Group
Again, this is just clarifying our line of thinking for making that technical proposal, we might have missed something or our assumptions might be wrong, that's why we need community's feedback on the issue.
And to emphasize Peter Koch's comments at RIPE 63's Database Session, there is a need to take a look at the bigger picture as well. This proposal only addresses publication of MD5 hashes. The issue of clear text password transport over email is still open and there might be other issues as well and that's why a security analysis of the whole process is useful and needed.
Thank you again for contributing to the subject.
Kind Regards, Kaveh.
--- Kaveh Ranjbar, Database Group Manager, RIPE NCC
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 22CEB341A2 for <maillists-archiver-wg+db@ripe.net>; Wed, 16 Nov 2011 10:24:47 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RQbjJ-0007eA-Df; Wed, 16 Nov 2011 10:24:32 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RQbjJ-00041C-39; Wed, 16 Nov 2011 10:24:29 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <green@msu.ru>) id 1RQbjH-000416-Dv for db-wg@lists.ripe.net; Wed, 16 Nov 2011 10:24:27 +0100 Received: from pigeon.msu.net ([2a00:f480:0:102::1c]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <green@msu.ru>) id 1RQbjE-0007do-TY for db-wg@ripe.net; Wed, 16 Nov 2011 10:24:27 +0100 Received: (qmail 28587 invoked from network); 16 Nov 2011 09:24:23 -0000 Received: from unknown (HELO ?IPv6:2a00:f480:0:2::1:32?) (2a00:f480:0:2::1:32) by pigeon.msu.net with ESMTPS (DHE-RSA-CAMELLIA256-SHA encrypted); 16 Nov 2011 09:24:23 -0000 Message-ID: <4EC38147.8040003@msu.ru> Date: Wed, 16 Nov 2011 13:24:23 +0400 From: Alexander Zubkov <green@msu.ru> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Denis Walker <denis@ripe.net> References: <4EBD302F.80304@ripe.net> <4EBD3F94.7030509@msu.ru> <CCAA2EC5-FB56-42E6-9202-C7CEC827233D@ripe.net> <4EC22C1B.10009@msu.ru> <4EC23D44.4050107@ripe.net> <4EC25A94.2080107@msu.ru> <4EC26ADB.9000505@ripe.net> In-Reply-To: <4EC26ADB.9000505@ripe.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-ClamFilter-Status: No X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: e72d347eaef9ca06106f34f87283d21d16a2dc2b00fed98ac2e5e3ca2603a6a4 Cc: Kaveh Ranjbar <kranjbar@ripe.net>, db-wg@ripe.net Subject: Re: [db-wg] [ncc-services-wg] Securing MD5 Hashes in the RIPE Database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points
pts rule name description ---- ---------------------- ------------------------------------ -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b8351171916a2dc2b00fed98ac2e5e3ca2603a6a4 Thank You for this answer. Most qeustions/complains went away. But one is still not clear to me.
If there is no password at all in the MNTNER object the "auth:" attributes will not be filtered in Webupdates and no password will be asked for in order to display the object. ... As we said in the article on RIPE Labs, the authentication model used by the RIPE Database is complex with many levels of indirection. If there was a simple solution to this problem that covered all possible issues we would have done it years ago. Working within the current design we want the best possible solution to this one issue that covers the majority of use cases and acceptable workarounds for the corner cases that can be implemented in a relatively short time period.
This is good point. But it looks like to me that this will bring inconvenience to users of KEY-schemes. Which are more secure and thereby should be encouraged, not punished. :) There should be no case where some information can be got only with password if KEY auth is present too. May be it should be added some possibility to send signed search reqests? Or may be output unfiltered object, encrypted with one of the keys.
There is no requirement for the maintainer of a MNTNER object to be one of the people who have credentials listed in the MNTNER object and it can be a separate MNTNER object. So if the maintainer of a MNTNER object is on vacation and you want to change your password or PGP key right now with the present system there is nothing you can do.
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id BD44B341A2 for <maillists-archiver-wg+db@ripe.net>; Thu, 17 Nov 2011 13:38:48 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RR1Ec-0007jl-GO; Thu, 17 Nov 2011 13:38:32 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RR1Ec-0004LB-3q; Thu, 17 Nov 2011 13:38:30 +0100 Received: from dodo.ipv6.ripe.net ([2001:67c:2e8:23::c100:1704] helo=dodo.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <denis@ripe.net>) id 1RR1EZ-0004L5-JO for db-wg@lists.ripe.net; Thu, 17 Nov 2011 13:38:27 +0100 Received: from denis.vpn.ripe.net ([193.0.21.59] helo=guest138.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from <denis@ripe.net>) id 1RR1EY-0002zA-3i; Thu, 17 Nov 2011 13:38:26 +0100 Message-ID: <4EC50042.20105@ripe.net> Date: Thu, 17 Nov 2011 13:38:26 +0100 From: Denis Walker <denis@ripe.net> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Alexander Zubkov <green@msu.ru> References: <4EBD302F.80304@ripe.net> <4EBD3F94.7030509@msu.ru> <CCAA2EC5-FB56-42E6-9202-C7CEC827233D@ripe.net> <4EC22C1B.10009@msu.ru> <4EC23D44.4050107@ripe.net> <4EC25A94.2080107@msu.ru> <4EC26ADB.9000505@ripe.net> <4EC38147.8040003@msu.ru> In-Reply-To: <4EC38147.8040003@msu.ru> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Kaveh Ranjbar <kranjbar@ripe.net>, db-wg@ripe.net Subject: Re: [db-wg] [ncc-services-wg] Securing MD5 Hashes in the RIPE Database X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: ---- X-RIPE-Spam-Report: Spam Total Points: -4.1 points
You missed the point or I described badly. Let's look at example: mntner: test1-mnt auth: MD5-PW ... mnt-by: test2-mnt mntner: test2-mnt auth: MD5-PW ... auth: PGPKEY-... mnt-by: test2-mnt So test2-mnt have 2 auth options. Let it be 2 different people. In that case only one having MD5-PW can see unfiltered test1-mnt. This is I called "punishing of users of KEY-schemes". pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719bb196b6f230c6f63384f0bc7095d764e Dear Alexander and others The RIPE NCC can put forward technical proposals and provide statistics and reality checks based on our in depth knowledge of the software and design and access to the database contents. But in the end the community will need to formulate a policy, perhaps around a (modified) technical proposal or something completely different. One of the main issues of this latest discussion seems to involve access to password protected data by PGP credential holders. So I thought at this point it would be a good idea to re-run my previous analysis and gather a few additional statistics on the use of different credentials. Then the community can better judge the scale of any problems, the effectiveness of workarounds and consider cost benefit issues. Here is a summary of some of the significant numbers with comments. I have rounded them off (mostly) to integers and ignored the (almost insignificant) X.509 usage. So some summations may be slightly out. All percentages relate to the total number of MNTNERs in use. Total number of MNTNERs in use = 33323 MNTNERs with only password = 28556 86% MNTNERs with only PGP = 1532 5% MNTNERs with password and PGP = 3167 10% Authentication is a logical OR. So password and PGP, in terms of authentication security level (while hashes are exposed) is the same as the lower security of password. So 96% of all MNTNERS use passwords. Now I looked at the issue of MNTNERs maintaining other MNTNERs. This is where the most corner cases exist with any plan to hide password hashes. In this I did not include MNTNERs that maintain themselves and also have additional MNTNERs maintaining them. I assumed these to be self maintained but simply have extra numbers of credentials to authenticate against. Total MNTNERs not self maintained = 1550 5% Subset of these 'not self maintained' MNTNERs that have passwords = 1428 4% (These are the ones that need authentication from their maintaining MNTNER to view the full object.) Number of unique MNTNERs maintaining these 'not self maintained' MNTNERs = 909 3% So the concern is about the 3% of MNTNERs that maintain the 4% of MNTNERS that are not self maintained and have passwords. So I looked at what credentials these 3% (909) MNTNERS use. Password only = 686 2% PGP only = 91 0.3% Password and PGP = 128 0.4% So the two corner cases relate to: a) 0.3% (91) of MNTNERs that would need to have a password added (besides the PGP keys) in order to update the MNTNERs they maintain. b) 0.4% (128) of MNTNERs that 'may' need an extra password adding if the existing password and PGP key do not belong to the same person. This to avoid the situation of needing to update a MNTNER maintained by this MNTNER if the person with the existing password is not available. Maybe another relevant number is the average number of MNTNER objects modified per day over the last 7 days is 22. One final question that comes to mind. If we were to move to SHA512 and hide the password hashes from the public and then address the other issue of passing clear text passwords by insecure methods, would passwords then be considered as a strong authentication? If these issues are considered important enough that they must be addressed in any solution without any weakening of the 0.3% PGP only, indirect authentication, then this must be included in any final policy and design. This can be done but would complicate a designed solution and more thought would be needed to find a way to handle this. I hope this helps with the communities considerations on this issue. Regards Denis Walker Business Analyst RIPE NCC Database Group On 16/11/11:47 10:24 AM, Alexander Zubkov wrote:
Thank You for this answer. Most qeustions/complains went away. But one is still not clear to me.
If there is no password at all in the MNTNER object the "auth:" attributes will not be filtered in Webupdates and no password will be asked for in order to display the object. ... As we said in the article on RIPE Labs, the authentication model used by the RIPE Database is complex with many levels of indirection. If there was a simple solution to this problem that covered all possible issues we would have done it years ago. Working within the current design we want the best possible solution to this one issue that covers the majority of use cases and acceptable workarounds for the corner cases that can be implemented in a relatively short time period.
This is good point. But it looks like to me that this will bring inconvenience to users of KEY-schemes. Which are more secure and thereby should be encouraged, not punished. :) There should be no case where some information can be got only with password if KEY auth is present too. May be it should be added some possibility to send signed search reqests? Or may be output unfiltered object, encrypted with one of the keys.
There is no requirement for the maintainer of a MNTNER object to be one of the people who have credentials listed in the MNTNER object and it can be a separate MNTNER object. So if the maintainer of a MNTNER object is on vacation and you want to change your password or PGP key right now with the present system there is nothing you can do.
You missed the point or I described badly. Let's look at example:
mntner: test1-mnt auth: MD5-PW ... mnt-by: test2-mnt
mntner: test2-mnt auth: MD5-PW ... auth: PGPKEY-... mnt-by: test2-mnt
So test2-mnt have 2 auth options. Let it be 2 different people. In that case only one having MD5-PW can see unfiltered test1-mnt. This is I called "punishing of users of KEY-schemes".
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id 903E1341A2 for <maillists-archiver-wg+db@ripe.net>; Mon, 21 Nov 2011 14:52:56 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RSUIL-0005VL-JV; Mon, 21 Nov 2011 14:52:33 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RSUIL-0004tB-CT; Mon, 21 Nov 2011 14:52:25 +0100 Received: from ayeaye.ipv6.ripe.net ([2001:67c:2e8:23::c100:1705] helo=ayeaye.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <training@ripe.net>) id 1RSUIJ-0004t6-Gy for db-wg@lists.ripe.net; Mon, 21 Nov 2011 14:52:23 +0100 Received: from osx59.ripe.net ([193.0.20.59]) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from <training@ripe.net>) id 1RSUIJ-0002UC-AH for db-wg@ripe.net; Mon, 21 Nov 2011 14:52:23 +0100 Message-ID: <4ECA5791.1020907@ripe.net> Date: Mon, 21 Nov 2011 14:52:17 +0100 From: Training Mailbox <training@ripe.net> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: db-wg@ripe.net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [db-wg] Announcement: RIPE NCC Training Courses X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: ---- X-RIPE-Spam-Report: Spam Total Points: -4.1 points
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id E877F341A2 for <maillists-archiver-wg+db@ripe.net>; Thu, 24 Nov 2011 14:11:03 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RTZ4e-0007dX-9U; Thu, 24 Nov 2011 14:10:47 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RTZ4d-0001V3-4C; Thu, 24 Nov 2011 14:10:43 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <rodolfo.garciapenas@telefonica.es>) id 1RTZ4X-0001Uv-Uh for db-wg@lists.ripe.net; Thu, 24 Nov 2011 14:10:38 +0100 Received: from mail2.telefonica.es ([194.224.58.62] helo=28SBHC11.telefonica.es) by postgirl.ripe.net with esmtp (Exim 4.72) (envelope-from <rodolfo.garciapenas@telefonica.es>) id 1RTZ4T-0007dE-2P for db-wg@ripe.net; Thu, 24 Nov 2011 14:10:37 +0100 X-KeepSent: FA776D44:C4C3E288-C1257952:0046D279; type=4; name=$KeepSent To: db-wg@ripe.net X-Mailer: Lotus Notes Release 7.0.2 CCH4 January 30, 2008 Message-ID: <OFFA776D44.C4C3E288-ONC1257952.0046D279-C1257952.0046B32D@telefonica.es> From: rodolfo.garciapenas@telefonica.es Date: Thu, 24 Nov 2011 13:58:57 +0100 X-MIMETrack: Serialize by Router on 28SBHC11/SRV/PASARELA_EMAIL(Release 8.5.2FP2|March 22, 2011) at 24/11/2011 14:10:32 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=4EBBF3C1DFD554E98f9e8a93df938690918c4EBBF3C1DFD554E9" Content-Disposition: inline X-RIPE-Spam-Level: ----- X-RIPE-Spam-Report: Spam Total Points: -5.4 points pts rule name description ---- ---------------------- ------------------------------------ -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [194.224.58.62 listed in list.dnswl.org] -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3c795ff97eeb0011c43202f16f5d3b8dc128cbcf5dde73ab5e035a747232d1fd Subject: [db-wg] Question about personal info X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: ----- X-RIPE-Spam-Report: Spam Total Points: -5.4 points
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 2209B341A2 for <maillists-archiver-wg+db@ripe.net>; Thu, 24 Nov 2011 15:29:17 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RTaIS-0003hk-Su; Thu, 24 Nov 2011 15:29:10 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RTaIS-0002Ev-M7; Thu, 24 Nov 2011 15:29:04 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <Woeber@CC.UniVie.ac.at>) id 1RTaIR-0002Eq-8Y for db-wg@lists.ripe.net; Thu, 24 Nov 2011 15:29:03 +0100 Received: from grace.univie.ac.at ([2001:62a:4:25::25:115]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <Woeber@CC.UniVie.ac.at>) id 1RTaIP-0003hf-Vj for db-wg@ripe.net; Thu, 24 Nov 2011 15:29:03 +0100 Received: from joan.univie.ac.at ([131.130.3.110] helo=joan.univie.ac.at) by grace.univie.ac.at with esmtp (Exim 4.77) (envelope-from <Woeber@CC.UniVie.ac.at>) id 1RTaIP-0004Qu-E1; Thu, 24 Nov 2011 15:29:01 +0100 Received: from [88.116.251.69] by joan.univie.ac.at with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <Woeber@CC.UniVie.ac.at>) id 1RTaIP-00066F-6e; Thu, 24 Nov 2011 15:29:01 +0100 Message-ID: <4ECE54AB.8040501@CC.UniVie.ac.at> Date: Thu, 24 Nov 2011 14:28:59 +0000 From: "Wilfried Woeber, UniVie/ACOnet" <Woeber@CC.UniVie.ac.at> Organization: UniVie - ACOnet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rodolfo.garciapenas@telefonica.es References: <OFFA776D44.C4C3E288-ONC1257952.0046D279-C1257952.0046B32D@telefonica.es> In-Reply-To: <OFFA776D44.C4C3E288-ONC1257952.0046D279-C1257952.0046B32D@telefonica.es> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Univie-Virus-Scan: scanned by ClamAV on joan.univie.ac.at X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: d04a9d8b6219edc74e3d2b1de6d505ac0b899c16fc3dfd0075b72f9358eba0ac Cc: db-wg@ripe.net Subject: Re: [db-wg] Question about personal info X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Woeber@CC.UniVie.ac.at List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points
pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b835117199df8a16e1101c95d849f9e22a31a715e [Apologies for duplicate e-mails] Dear Colleagues, The RIPE NCC invites you to register for one of our upcoming training courses: - The LIR Training Course This course teaches LIRs how to request Internet number resources and interact with the RIPE NCC. A course outline is available at: http://www.ripe.net/lir-services/training/courses/lir/outline/ - The Routing Registry Training Course This course teaches LIRs how to use the RIPE Database for routing. A course outline is available at: http://www.ripe.net/lir-services/training/courses/rr/ - The IPv6 Training Course This course teaches LIRs about the need for IPv6 and includes basic information on how to plan your deployment. A course outline is available at: http://www.ripe.net/training/ipv6/outline.html To see the location of upcoming courses and to register, please use the LIR Portal or complete the registration form on our website at: RIPE NCC Upcoming Courses List& Registration https://lirportal.ripe.net/training/courses If you have any questions, please do not hesitate to contact us at <training@ripe.net>. Kind regards, Rumy Spratley-Kanis Training Services Manager RIPE NCC pts rule name description ---- ---------------------- ------------------------------------ -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [194.224.58.62 listed in list.dnswl.org] -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719c128cbcf5dde73ab5e035a747232d1fd --0__=4EBBF3C1DFD554E98f9e8a93df938690918c4EBBF3C1DFD554E9 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Dear DB Group, I am trying to clean our objets in the database. I downloaded the datab= ase file from the ftp and all objects are like this: inetnum: 80.58.100.0 - 80.58.104.63 netname: RIMA descr: Telefonica de Espana SAU descr: Red de servicios IP descr: Spain country: ES admin-c: DUMY-RIPE tech-c: DUMY-RIPE status: ASSIGNED PA notify: adminis.ripe@telefonica.es mnt-by: MAINT-AS3352 changed: adminis.ripe@telefonica.es 20020530 changed: adminis.ripe@telefonica.es 20030924 changed: adminis.ripe@telefonica.es 20060118 changed: adminis.ripe@telefonica.es 20090819 source: RIPE remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded= as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: **************************** The admin-c and tech-c fields contains "DUMY-RIPE" and the object inclu= des the remarks about the object modification. After writing to ripe-dbm@ripe.net (reply attached), I have some commen= ts: a) IMHO this is not correct, because: a1. The fields admin-c and tech-c don't contains personal data, is only= a RIPE admin identifier a2. The fields mnt-routers, mnt-by, mnt-lower,... contains "personal da= ta" too b) How can I check my objects? We have a lot of objects (>>300), and is= not possible to get them using the ripe.net/whois webpage. What should I do= ? Probably we could have an option to download "my the LIR part" of the database (like assused). Thanks a lot, Best Regards, Rodolfo Garc=EDa (kix). -- Rodolfo Garc=EDa Pe=F1as =C1rea de Estrategia y Desarrollo de Redes Direcci=F3n de Redes Conmutadas, IP y de Nueva Generaci=F3n Gerencia de Planificaci=F3n de Redes IP Jefatura de Planificaci=F3n del Acceso de Red IP Planta 7, Edificio Este-1 Distrito C 28050 Madrid Tel: 9148 20830 ----- Remitido por Rodolfo Garcia Penas/INFR/TESA con fecha 24/11/2011 13:45 ----- RIPE Database Manager <ripe-dbm@ripe.net>@ripe.net> con fecha 24/11/201= 1 13:48:32 Por favor, responda a RIPE Database Manager <ripe-dbm@ripe.net> Destinatarios: adminis.ripe@telefonica.es CC: Asunto: Re: NCC#201111XXXX Question about personal info = Clasificaci=F3n (Embedded image moved to file: = : pic32521.jpg) = = Dear Rodolfo, Thank you for your email. The RIPE Community Data Protection Task Force met at the RIPE 56 Meeting in Berlin in May 2008 with representatives of the RIPE NCC and their legal advisers. During this meeting the discussions on the issue of bulk access to personal data held in the RIPE Database were concluded. The main points that were considered were: 1. Data Protection laws in the Netherlands and the European Union 2. The reasons why people ask for bulk access 3. Alternative technical solutions After long discussions, it was agreed unanimously that the RIPE NCC cannot allow bulk access to personal data. If you feel there should be a change to this policy, then you may want to raise the issue on the Database Working Group. -- If you have any questions, please feel free to contact us. Best regards, Andrea Di Menna Customer Services RIPE NCC _______________________________________________________________________= ____ Este mensaje se dirige exclusivamente a su destinatario y puede contene= r informaci=F3n privilegiada o confidencial. Si no es vd. el destinatario= indicado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3= n y/o copia sin autorizaci=F3n est=E1 prohibida en virtud de la legislaci=F3n= vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. El correo electr=F3nico v=EDa Internet no permite asegurar la confidenc= ialidad de los mensajes que se transmiten ni su integridad o correcta recepci=F3= n. Telef=F3nica no asume ninguna responsabilidad por estas circunstancias.= This message is intended exclusively for its addressee and may contain information that is CONFIDENTIAL and protected by a professional privil= ege or whose disclosure is prohibited by law.If you are not the intended recipient you are hereby notified that any read, dissemination, copy or= disclosure of this communication is strictly prohibited by law. If this= message has been received in error, please immediately notify us via e-= mail and delete it. Internet e-mail neither guarantees the confidentiality nor the integrit= y or proper receipt of the messages sent. Telef=F3nica does not assume any liability for those circumstances. _______________________________________________________________________= ____= --0__=4EBBF3C1DFD554E98f9e8a93df938690918c4EBBF3C1DFD554E9 Content-type: image/jpeg; name="pic32521.jpg" Content-Disposition: attachment; filename="pic32521.jpg" Content-transfer-encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCAAQABMDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD6/uvD mlaJ4b+Hy6Z8K7bxXPrX2aC9vkjhji09GiBa4nJBdhk9FU98leM8/wCIdX0Xwb8YvB3gG9+GXh3x BP4i8xpLjQPnn0uJQMT3Nu0WFgJyBIZBkggKSK9O8H/FLwjZ+CtEtpPE+k291Fp8EbJLcplHEagg jI6HtxWP8LvF+h+FdJ1E+I/GXg2+1u/vpbue90ONrRJQxyvmCWeZ2ZeVBL4ChFVQFFRqdi5dNjxH 4z+HdL0b4laxZ2OnWtpax+TshhiVVXMKE4AHqSfxoo+M/iHS9Z+JWsXljqFtd2snk7JoZVZWxCgO CD6gj8KK0VzklbmZ/9k= --0__=4EBBF3C1DFD554E98f9e8a93df938690918c4EBBF3C1DFD554E9-- pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b835117190b899c16fc3dfd0075b72f9358eba0ac rodolfo.garciapenas@telefonica.es wrote:
Dear DB Group,
[...]
b) How can I check my objects? We have a lot of objects (>>300), and is not possible to get them using the ripe.net/whois webpage. What should I do?
The "traditional" whois interface is still supported: __________________________________________________________________ [ww@wsww ~]$ telnet whois.ripe.net 43 Trying 2001:67c:2e8:22::c100:687... Connected to whois.ripe.net (2001:67c:2e8:22::c100:687). Escape character is '^]'. % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf -rBTinetnum 80.58.100.0 - 80.58.104.63 % Information related to '80.58.100.0 - 80.58.104.63' inetnum: 80.58.100.0 - 80.58.104.63 netname: RIMA descr: Telefonica de Espana SAU descr: Red de servicios IP descr: Spain country: ES admin-c: ATdE1-RIPE tech-c: TTdE1-RIPE status: ASSIGNED PA notify: adminis.ripe@telefonica.es mnt-by: MAINT-AS3352 changed: adminis.ripe@telefonica.es 20020530 changed: adminis.ripe@telefonica.es 20030924 changed: adminis.ripe@telefonica.es 20060118 changed: adminis.ripe@telefonica.es 20090819 source: RIPE Connection closed by foreign host. __________________________________________________________________ That should be easy to script one way or another, probably with the help of a decent "whois" client or a library function. There's also a flag which tells the server to keep the TCP stream open and wait for a new lookup key (iirc it is -k, just refer to the doc or feed -h to the server :-) ). Hth, regards, Wilfried.
Probably we could have an option to download "my the LIR part" of the database (like assused).
Thanks a lot,
Best Regards,
Rodolfo Garc�a (kix). -- Rodolfo Garc�a Pe�as �rea de Estrategia y Desarrollo de Redes Direcci�n de Redes Conmutadas, IP y de Nueva Generaci�n Gerencia de Planificaci�n de Redes IP Jefatura de Planificaci�n del Acceso de Red IP Planta 7, Edificio Este-1 Distrito C 28050 Madrid Tel: 9148 20830 ----- Remitido por Rodolfo Garcia Penas/INFR/TESA con fecha 24/11/2011 13:45 -----
RIPE Database Manager <ripe-dbm@ripe.net>@ripe.net> con fecha 24/11/2011 13:48:32
Por favor, responda a RIPE Database Manager <ripe-dbm@ripe.net>
Destinatarios: adminis.ripe@telefonica.es CC: Asunto: Re: NCC#201111XXXX Question about personal info
Clasificaci�n (Embedded image moved to file: : pic32521.jpg)
Dear Rodolfo,
Thank you for your email.
The RIPE Community Data Protection Task Force met at the RIPE 56 Meeting in Berlin in May 2008 with representatives of the RIPE NCC and their legal advisers. During this meeting the discussions on the issue of bulk access to personal data held in the RIPE Database were concluded.
The main points that were considered were:
1. Data Protection laws in the Netherlands and the European Union
2. The reasons why people ask for bulk access
3. Alternative technical solutions
After long discussions, it was agreed unanimously that the RIPE NCC cannot allow bulk access to personal data.
If you feel there should be a change to this policy, then you may want to raise the issue on the Database Working Group.
-- If you have any questions, please feel free to contact us.
Best regards,
Andrea Di Menna Customer Services RIPE NCC
___________________________________________________________________________
Este mensaje se dirige exclusivamente a su destinatario y puede contener informaci�n privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado de que la lectura, utilizaci�n, divulgaci�n y/o copia sin autorizaci�n est� prohibida en virtud de la legislaci�n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v�a y proceda a su destrucci�n.
El correo electr�nico v�a Internet no permite asegurar la confidencialidad de los mensajes que se transmiten ni su integridad o correcta recepci�n. Telef�nica no asume ninguna responsabilidad por estas circunstancias.
This message is intended exclusively for its addressee and may contain information that is CONFIDENTIAL and protected by a professional privilege or whose disclosure is prohibited by law.If you are not the intended recipient you are hereby notified that any read, dissemination, copy or disclosure of this communication is strictly prohibited by law. If this message has been received in error, please immediately notify us via e-mail and delete it.
Internet e-mail neither guarantees the confidentiality nor the integrity or proper receipt of the messages sent. Telef�nica does not assume any liability for those circumstances. ___________________________________________________________________________
------------------------------------------------------------------------
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id 4B631341A2 for <maillists-archiver-wg+db@ripe.net>; Thu, 24 Nov 2011 15:59:32 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RTalf-0007AR-HA; Thu, 24 Nov 2011 15:59:17 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RTalf-0002WL-03; Thu, 24 Nov 2011 15:59:15 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <fweimer@bfk.de>) id 1RTald-0002WG-5q for db-wg@lists.ripe.net; Thu, 24 Nov 2011 15:59:13 +0100 Received: from mx01.bfk.de ([193.227.124.2]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <fweimer@bfk.de>) id 1RTalb-0005GA-R1 for db-wg@ripe.net; Thu, 24 Nov 2011 15:59:13 +0100 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1RTafL-0005e8-Dw; Thu, 24 Nov 2011 14:52:43 +0000 Received: by bfk.de with local id 1RTafL-0005Z2-7t; Thu, 24 Nov 2011 14:52:43 +0000 From: Florian Weimer <fweimer@bfk.de> To: Woeber@CC.UniVie.ac.at References: <OFFA776D44.C4C3E288-ONC1257952.0046D279-C1257952.0046B32D@telefonica.es> <4ECE54AB.8040501@CC.UniVie.ac.at> Date: Thu, 24 Nov 2011 14:52:43 +0000 In-Reply-To: <4ECE54AB.8040501@CC.UniVie.ac.at> (Wilfried Woeber's message of "Thu, 24 Nov 2011 14:28:59 +0000") Message-ID: <82ehwxa7yc.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: bbc3c8b599053c7b8a1607e8b0d5630fa2e605d5113f170835fb1c7421e73042 Cc: db-wg@ripe.net, rodolfo.garciapenas@telefonica.es Subject: Re: [db-wg] Question about personal info X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points
pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719a2e605d5113f170835fb1c7421e73042 * Wilfried Woeber:
That should be easy to script one way or another, probably with the help of a decent "whois" client or a library function.
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id EAB1C341A2 for <maillists-archiver-wg+db@ripe.net>; Thu, 24 Nov 2011 16:00:00 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RTamL-0007FK-Kc; Thu, 24 Nov 2011 16:00:00 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RTamL-0002XD-3t; Thu, 24 Nov 2011 15:59:57 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <Woeber@CC.UniVie.ac.at>) id 1RTamI-0002X8-Vs for db-wg@lists.ripe.net; Thu, 24 Nov 2011 15:59:54 +0100 Received: from grace.univie.ac.at ([2001:62a:4:25::25:115]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <Woeber@CC.UniVie.ac.at>) id 1RTamG-0005QB-7L for db-wg@ripe.net; Thu, 24 Nov 2011 15:59:54 +0100 Received: from joan.univie.ac.at ([131.130.3.110] helo=joan.univie.ac.at) by grace.univie.ac.at with esmtp (Exim 4.77) (envelope-from <Woeber@CC.UniVie.ac.at>) id 1RTamD-0002IM-JX; Thu, 24 Nov 2011 15:59:49 +0100 Received: from [88.116.251.69] by joan.univie.ac.at with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <Woeber@CC.UniVie.ac.at>) id 1RTajF-0001jp-B7; Thu, 24 Nov 2011 15:56:45 +0100 Message-ID: <4ECE5B2B.4080405@CC.UniVie.ac.at> Date: Thu, 24 Nov 2011 14:56:43 +0000 From: "Wilfried Woeber, UniVie/ACOnet" <Woeber@CC.UniVie.ac.at> Organization: UniVie - ACOnet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florian Weimer <fweimer@bfk.de> References: <OFFA776D44.C4C3E288-ONC1257952.0046D279-C1257952.0046B32D@telefonica.es> <4ECE54AB.8040501@CC.UniVie.ac.at> <82ehwxa7yc.fsf@mid.bfk.de> In-Reply-To: <82ehwxa7yc.fsf@mid.bfk.de> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Univie-Virus-Scan: scanned by ClamAV on joan.univie.ac.at X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: d04a9d8b6219edc74e3d2b1de6d505ac62fe158559d9bcad01571cdb860ce1ea Cc: db-wg@ripe.net, rodolfo.garciapenas@telefonica.es Subject: Re: [db-wg] Question about personal info X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Woeber@CC.UniVie.ac.at List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points
IIRC, the traditional WHOIS interface has rather stringent rate limits. --=20 Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 pts rule name description ---- ---------------------- ------------------------------------ -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b8351171962fe158559d9bcad01571cdb860ce1ea Florian Weimer wrote:
* Wilfried Woeber:
That should be easy to script one way or another, probably with the help of a decent "whois" client or a library function.
IIRC, the traditional WHOIS interface has rather stringent rate limits.
Correct. But ripe-dbm can configure and/or (temporarily) lift these restrictons to support genuine queries form a particular source. Thanks for pointing this out! Wilfried.
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id 67A2B341A2 for <maillists-archiver-wg+db@ripe.net>; Thu, 24 Nov 2011 16:13:49 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RTaxl-00062s-UR; Thu, 24 Nov 2011 16:13:46 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RTaxl-0002fV-Op; Thu, 24 Nov 2011 16:11:45 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <rodolfo.garciapenas@telefonica.es>) id 1RTaxg-0002fF-Tp for db-wg@lists.ripe.net; Thu, 24 Nov 2011 16:11:41 +0100 Received: from mail2.telefonica.es ([194.224.58.62] helo=28SBHC11.telefonica.es) by postgirl.ripe.net with esmtp (Exim 4.72) (envelope-from <rodolfo.garciapenas@telefonica.es>) id 1RTaxc-00062F-MN for db-wg@ripe.net; Thu, 24 Nov 2011 16:11:40 +0100 In-Reply-To: <4ECE54AB.8040501@CC.UniVie.ac.at> X-KeepSent: 27817EC4:644C4960-C1257952:0052A951; type=4; name=$KeepSent To: Woeber@CC.UniVie.ac.at X-Mailer: Lotus Notes Release 7.0.2 CCH4 January 30, 2008 Message-ID: <OF27817EC4.644C4960-ONC1257952.0052A951-C1257952.0052B63D@telefonica.es> From: rodolfo.garciapenas@telefonica.es Date: Thu, 24 Nov 2011 16:10:09 +0100 X-MIMETrack: Serialize by Router on 28SBHC11/SRV/PASARELA_EMAIL(Release 8.5.2FP2|March 22, 2011) at 24/11/2011 16:11:36 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-RIPE-Spam-Level: ----- X-RIPE-Spam-Report: Spam Total Points: -5.4 points pts rule name description ---- ---------------------- ------------------------------------ -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [194.224.58.62 listed in list.dnswl.org] -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3c795ff97eeb0011c43202f16f5d3b8df4513f8f8bc7f4f628dc2642b60e5bc8 Cc: db-wg@ripe.net Subject: Re: [db-wg] Question about personal info X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719f4513f8f8bc7f4f628dc2642b60e5bc8
Hi Wilfried, thanks a lot for your reply. Is possible to do it using the web interfa= ce: https://apps.db.ripe.net/search/query.html?searchtext=3D-rBTinetnum +80.58.100.0+-+80.58.104.63&search%3AdoSearch=3DSearch but I have *A LOT* of objects. I think that the idea of the telnet/whois/web interface is to query for one/two three objets, but no= t for 1000, 2000, 3000, 4000 objets. On the other hand, if you make some quick queries to the web interface, the system blocks you. I think is better to add the info to the ripe.db file or make a query f= or the LIRs (like assued). Best Regards, kix -- Rodolfo Garc=EDa (kix) = "Wilfried = Woeber, = UniVie/ACOnet" P= ara <Woeber@CC.Uni rodolfo.garciapenas@telefo= nic Vie.ac.at> a.es = Enviado por: = cc db-wg-bounces@ db-wg@ripe.net = ripe.net Asu= nto Re: [db-wg] Question about= personal info = 24/11/2011 Clasificac= i=F3n 15:29 = = = Por favor, = responda a = Woeber@CC.U = niVie.ac.at = = = rodolfo.garciapenas@telefonica.es wrote:
Dear DB Group,
[...]
b) How can I check my objects? We have a lot of objects (>>300), and = is not possible to get them using the ripe.net/whois webpage. What should I = do?
The "traditional" whois interface is still supported: __________________________________________________________________ [ww@wsww ~]$ telnet whois.ripe.net 43 Trying 2001:67c:2e8:22::c100:687... Connected to whois.ripe.net (2001:67c:2e8:22::c100:687). Escape character is '^]'. % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf -rBTinetnum 80.58.100.0 - 80.58.104.63 % Information related to '80.58.100.0 - 80.58.104.63' inetnum: 80.58.100.0 - 80.58.104.63 netname: RIMA descr: Telefonica de Espana SAU descr: Red de servicios IP descr: Spain country: ES admin-c: ATdE1-RIPE tech-c: TTdE1-RIPE status: ASSIGNED PA notify: adminis.ripe@telefonica.es mnt-by: MAINT-AS3352 changed: adminis.ripe@telefonica.es 20020530 changed: adminis.ripe@telefonica.es 20030924 changed: adminis.ripe@telefonica.es 20060118 changed: adminis.ripe@telefonica.es 20090819 source: RIPE Connection closed by foreign host. __________________________________________________________________ That should be easy to script one way or another, probably with the help of a decent "whois" client or a library function. There's also a flag which tells the server to keep the TCP stream open and wait for a new lookup key (iirc it is -k, just refer to the doc or feed -h to the server :-) ). Hth, regards, Wilfried.
Probably we could have an option to download "my the LIR part" of the=
database (like assused).
Thanks a lot,
Best Regards,
Rodolfo Garc=EDa (kix). -- Rodolfo Garc=EDa Pe=F1as =C1rea de Estrategia y Desarrollo de Redes Direcci=F3n de Redes Conmutadas, IP y de Nueva Generaci=F3n Gerencia de Planificaci=F3n de Redes IP Jefatura de Planificaci=F3n del Acceso de Red IP Planta 7, Edificio Este-1 Distrito C 28050 Madrid Tel: 9148 20830 ----- Remitido por Rodolfo Garcia Penas/INFR/TESA con fecha 24/11/201= 1 13:45 -----
RIPE Database Manager <ripe-dbm@ripe.net>@ripe.net> con fecha 24/11/2= 011 13:48:32
Por favor, responda a RIPE Database Manager <ripe-dbm@ripe.net>
Destinatarios: adminis.ripe@telefonica.es CC: Asunto: Re: NCC#201111XXXX Question about personal info
Clasificaci=F3n (Embedded image moved to file:
: pic32521.jpg)
Dear Rodolfo,
Thank you for your email.
The RIPE Community Data Protection Task Force met at the RIPE 56 Meeting in Berlin in May 2008 with representatives of the RIPE NCC an=
d
their legal advisers. During this meeting the discussions on the issu= e of bulk access to personal data held in the RIPE Database were concluded.
The main points that were considered were:
1. Data Protection laws in the Netherlands and the European Union
2. The reasons why people ask for bulk access
3. Alternative technical solutions
After long discussions, it was agreed unanimously that the RIPE NCC cannot allow bulk access to personal data.
If you feel there should be a change to this policy, then you may want to raise the issue on the Database Working Group.
-- If you have any questions, please feel free to contact us.
Best regards,
Andrea Di Menna Customer Services RIPE NCC
_______________________________________________________________________= ____
Este mensaje se dirige exclusivamente a su destinatario y puede conte=
informaci=F3n privilegiada o confidencial. Si no es vd. el destinatar= io indicado, queda notificado de que la lectura, utilizaci=F3n, divulgac= i=F3n y/o copia sin autorizaci=F3n est=E1 prohibida en virtud de la legislaci=F3= n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comuniqu= e inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n.
El correo electr=F3nico v=EDa Internet no permite asegurar la confidencialidad de los mensajes que se transmiten ni su integridad o correcta recepci= =F3n. Telef=F3nica no asume ninguna responsabilidad por estas circunstancia= s.
This message is intended exclusively for its addressee and may contai= n information that is CONFIDENTIAL and protected by a professional
ner privilege
or whose disclosure is prohibited by law.If you are not the intended recipient you are hereby notified that any read, dissemination, copy = or disclosure of this communication is strictly prohibited by law. If th= is message has been received in error, please immediately notify us via e-mail and delete it.
Internet e-mail neither guarantees the confidentiality nor the integr= ity or proper receipt of the messages sent. Telef=F3nica does not assume any=
liability for those circumstances.
_______________________________________________________________________= ____
---------------------------------------------------------------------=
---
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id ACA8B341A2 for <maillists-archiver-wg+db@ripe.net>; Thu, 24 Nov 2011 16:15:46 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RTb1U-0006I9-3F; Thu, 24 Nov 2011 16:15:43 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RTb1S-0002h3-BT; Thu, 24 Nov 2011 16:15:34 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <rodolfo.garciapenas@telefonica.es>) id 1RTb1O-0002gx-20 for db-wg@lists.ripe.net; Thu, 24 Nov 2011 16:15:30 +0100 Received: from mail2.telefonica.es ([194.224.58.62] helo=28SBHC11.telefonica.es) by postgirl.ripe.net with esmtp (Exim 4.72) (envelope-from <rodolfo.garciapenas@telefonica.es>) id 1RTb1K-0006HZ-Rq for db-wg@ripe.net; Thu, 24 Nov 2011 16:15:30 +0100 In-Reply-To: <4ECE5B2B.4080405@CC.UniVie.ac.at> X-KeepSent: 1AE4EA07:E12AAF7E-C1257952:005381C1; type=4; name=$KeepSent To: Woeber@CC.UniVie.ac.at X-Mailer: Lotus Notes Release 7.0.2 CCH4 January 30, 2008 Message-ID: <OF1AE4EA07.E12AAF7E-ONC1257952.005381C1-C1257952.0053109D@telefonica.es> From: rodolfo.garciapenas@telefonica.es Date: Thu, 24 Nov 2011 16:14:01 +0100 X-MIMETrack: Serialize by Router on 28SBHC11/SRV/PASARELA_EMAIL(Release 8.5.2FP2|March 22, 2011) at 24/11/2011 16:15:26 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-RIPE-Spam-Level: ----- X-RIPE-Spam-Report: Spam Total Points: -5.4 points pts rule name description ---- ---------------------- ------------------------------------ -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [194.224.58.62 listed in list.dnswl.org] -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3c795ff97eeb0011c43202f16f5d3b8d125b9503b4c922a13765977804e8e711 Cc: db-wg@ripe.net, Florian Weimer <fweimer@bfk.de> Subject: Re: [db-wg] Question about personal info X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: ----- X-RIPE-Spam-Report: Spam Total Points: -5.4 points
_____________________________________________________________________ Mensaje analizado y protegido por Telefonica Grandes Clientes = pts rule name description ---- ---------------------- ------------------------------------ -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [194.224.58.62 listed in list.dnswl.org] -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719125b9503b4c922a13765977804e8e711
Florian Weimer wrote:
* Wilfried Woeber:
That should be easy to script one way or another, probably with the help of a decent "whois" client or a library function.
IIRC, the traditional WHOIS interface has rather stringent rate limi= ts.
Correct. But ripe-dbm can configure and/or (temporarily) lift these restrictons to support genuine queries form a particular source.
Patching a patch :-) Probably other solution is better.
Thanks for pointing this out! Wilfried.
From Return-Path: <db-wg-bounces@ripe.net> Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by bigos.ripe.net (Postfix) with ESMTP id C1CA9341A2 for <maillists-archiver-wg+db@ripe.net>; Thu, 24 Nov 2011 17:31:17 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RTcCO-00010M-1Q; Thu, 24 Nov 2011 17:31:05 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RTcCN-0003P0-LY; Thu, 24 Nov 2011 17:30:55 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <joao@bondis.org>) id 1RTcCF-0003Ot-W4 for db-wg@lists.ripe.net; Thu, 24 Nov 2011 17:30:49 +0100 Received: from [194.176.119.250] (helo=smtp1.bondis.org) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <joao@bondis.org>) id 1RTcCB-0000zz-SC for db-wg@ripe.net; Thu, 24 Nov 2011 17:30:47 +0100 Received: from [192.168.2.36] (82.158.254.126.dyn.user.ono.com [82.158.254.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: joao) by smtp1.bondis.org (Postfix) with ESMTPSA id 0D3E56202AA; Thu, 24 Nov 2011 17:25:44 +0100 (CET) References: <OFFA776D44.C4C3E288-ONC1257952.0046D279-C1257952.0046B32D@telefonica.es> In-Reply-To: <OFFA776D44.C4C3E288-ONC1257952.0046D279-C1257952.0046B32D@telefonica.es> Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 Message-Id: <39669365-CD4A-48A3-8E47-808DFFF28565@bondis.org> Content-Transfer-Encoding: quoted-printable From: =?iso-8859-1?Q?Jo=E3o_Damas?= <joao@bondis.org> Date: Thu, 24 Nov 2011 17:22:22 +0100 To: rodolfo.garciapenas@telefonica.es X-Mailer: Apple Mail (2.1251.1) X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS 0.0 TO_NO_BRKTS_NORDNS To: misformatted and no rDNS X-RIPE-Signature: 2df91793f5cbd2ee5bae47f4fc8ce157ce5bd1e149e0f7ccf348e6fba220281e Cc: db-wg@ripe.net Subject: Re: [db-wg] Question about personal info X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.1 points
-- Rodolfo Garc=EDa (kix)= pts rule name description ---- ---------------------- ------------------------------------ -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0051] 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719ce5bd1e149e0f7ccf348e6fba220281e On 24 Nov 2011, at 13:58, rodolfo.garciapenas@telefonica.es wrote:
=20 b) How can I check my objects? We have a lot of objects (>>300), and = is not possible to get them using the ripe.net/whois webpage. What should I = do? Probably we could have an option to download "my the LIR part" of the database (like assused).
From Return-Path: <db-wg-bounces@ripe.net> Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by bigos.ripe.net (Postfix) with ESMTP id AAD64341A2 for <maillists-archiver-wg+db@ripe.net>; Fri, 25 Nov 2011 13:32:09 +0100 (CET) Received: from mamba.ripe.net ([193.0.19.40]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <db-wg-bounces@ripe.net>) id 1RTuwX-0005Di-QF; Fri, 25 Nov 2011 13:31:52 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net) by mamba.ripe.net with esmtp (Exim 4.63) (envelope-from <db-wg-bounces@ripe.net>) id 1RTuwX-00008U-5J; Fri, 25 Nov 2011 13:31:49 +0100 Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342] helo=postgirl.ripe.net) by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <shane@time-travellers.org>) id 1RTuwU-00008P-2r for db-wg@lists.ripe.net; Fri, 25 Nov 2011 13:31:46 +0100 Received: from [2a01:4f8:150:8121::e38a:da8c] (helo=time-travellers.nl.eu.org) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <shane@time-travellers.org>) id 1RTuwS-0002wb-6n for db-wg@ripe.net; Fri, 25 Nov 2011 13:31:46 +0100 Received: from [2001:610:719:1:beae:c5ff:fe43:aa00] by time-travellers.nl.eu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <shane@time-travellers.org>) id 1RTuQ8-0005gO-SU; Fri, 25 Nov 2011 11:58:21 +0000 From: Shane Kerr <shane@time-travellers.org> To: rodolfo.garciapenas@telefonica.es Date: Fri, 25 Nov 2011 12:58:19 +0100 In-Reply-To: <39669365-CD4A-48A3-8E47-808DFFF28565@bondis.org> References: <OFFA776D44.C4C3E288-ONC1257952.0046D279-C1257952.0046B32D@telefonica.es> <39669365-CD4A-48A3-8E47-808DFFF28565@bondis.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 (3.0.3-1.fc15) Content-Transfer-Encoding: quoted-printable Message-ID: <1322222300.2995.48.camel@shane-desktop> Mime-Version: 1.0 X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.1 points pts rule name description ---- ---------------------- ------------------------------------ -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS 0.0 TO_NO_BRKTS_NORDNS To: misformatted and no rDNS X-RIPE-Signature: 7dbc47838f18b9f91fca9fb4839f56ddeae4ca77cb448d7e5a39e4dcd555a9a1 Cc: db-wg@ripe.net Subject: Re: [db-wg] Question about personal info X-BeenThere: db-wg@ripe.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: RIPE Database Working Group <db-wg.ripe.net> List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://www.ripe.net/ripe/mail/archives/db-wg> List-Post: <mailto:db-wg@ripe.net> List-Help: <mailto:db-wg-request@ripe.net?subject=help> List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>, <mailto:db-wg-request@ripe.net?subject=subscribe> Sender: db-wg-bounces@ripe.net Errors-To: db-wg-bounces@ripe.net X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.1 points
Making the full object available from within the LIR portal might be the = best approach here to get full access to your own objects. In the meantime perhaps ripe-dbm should realise that data protection = rules don't apply when YOU are trying to access YOUR objects and if = given a list of inetnum objects they could provide a full dump with = which to edit locally and then submit. Best, Joao pts rule name description ---- ---------------------- ------------------------------------ -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0012] 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719eae4ca77cb448d7e5a39e4dcd555a9a1 On Thu, 2011-11-24 at 17:22 +0100, Jo=C3=A3o Damas wrote:
=20 b) How can I check my objects? We have a lot of objects (>>300), and is= not possible to get them using the ripe.net/whois webpage. What should I do= ? Probably we could have an option to download "my the LIR part" of the database (like assused). =20 Making the full object available from within the LIR portal might be
On 24 Nov 2011, at 13:58, rodolfo.garciapenas@telefonica.es wrote: the best approach here to get full access to your own objects. =20 In the meantime perhaps ripe-dbm should realise that data protection rules don't apply when YOU are trying to access YOUR objects and if given a list of inetnum objects they could provide a full dump with which to edit locally and then submit.
Yes, this is probably the best approach. The RIPE NCC maintains a support role for the RIPE Database, for just such help. That's ripe-dbm@ripe.net, I think. -- Shane
At 15:29 05/10/2011 +0200, Denis Walker wrote: Rather than make new toys, sure would have been nice if RIPE saw the justification of fixing up and correcting the country code listing for ERX prefixes (from 2004) in delegated-ripencc-latest, that list all ERX objects as country code=EU. Team Cymru, among others, use that for geolocation. But alas, the answer I received from RIPE was basically - No. -Hank
Dear colleagues,
At the RIPE 62 Meeting in Amsterdam the RIPE NCC Database Group was asked to investigate handling geolocation data in the RIPE Database. We now have a proof of concept prototype for discussion by the community.
Based on input from a number of community sources and the subsequent presentation at RIPE 62, this prototype has two new optional attributes for storing geolocation data and language details.
We have written an article about the design approach on RIPE Labs https://labs.ripe.net/Members/denis/geolocation-prototype-for-ripe-database
This prototype references a sand-boxed TEST Database and does not have any pre-loaded geolocation or language data. But you can create your own data to see how easy it is to manage this new, optional information. We also have a prototype Geolocation Finder tool to search for this data.
Another article on RIPE Labs shows how to create the new optional attributes and use the Geolocation Finder tool to search for this data. No changes in this sand-boxed TEST Database will affect the production RIPE or TEST Database services.
The article is available at: https://labs.ripe.net/Members/denis/example-usage-of-ripe-database-geolocati...
We invite comments or feedback on this design and suggestions for how to move forward if it is seen as a useful addition to the RIPE Database by the community.
Regards
Denis Walker Business Analyst RIPE NCC Database Group
Hank,
What do you propose exactly?
Should we ask the RIPE NCC to e-mail each holder of an ERX block and
help them update their country code?
Should they make a best guess based on routing (RIS probably has a broad
enough view to handle anycast addresses and the like too) and set the
country code to that country if the ERX holder does not get back within
a certain time?
Or... what exactly?
On Thu, 2011-10-06 at 09:25 +0200, Hank Nussbacher wrote:
> At 15:29 05/10/2011 +0200, Denis Walker wrote:
>
> Rather than make new toys, sure would have been nice if RIPE saw the
> justification of fixing up and correcting the country code listing for ERX
> prefixes (from 2004) in delegated-ripencc-latest, that list all ERX objects
> as country code=EU. Team Cymru, among others, use that for
> geolocation. But alas, the answer I received from RIPE was basically - No.
--
Shane
>From hank@efes.iucc.ac.il Thu Oct 06 2011
Return-Path: <db-wg-bounces@ripe.net>
Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66])
by bigos.ripe.net (Postfix) with ESMTP id 5621B341A3
for <maillists-archiver-wg+db@ripe.net>; Thu, 6 Oct 2011 10:02:32 +0200 (CEST)
Received: from mamba.ripe.net ([193.0.19.40])
by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.72)
(envelope-from <db-wg-bounces@ripe.net>)
id 1RBiuK-0007ru-SR; Thu, 06 Oct 2011 10:02:23 +0200
Received: from localhost.localdomain ([127.0.0.1] helo=mamba.ripe.net)
by mamba.ripe.net with esmtp (Exim 4.63)
(envelope-from <db-wg-bounces@ripe.net>)
id 1RBis9-00076J-Gs; Thu, 06 Oct 2011 10:00:05 +0200
Received: from postgirl.ipv6.ripe.net ([2001:67c:2e8:11::c100:1342]
helo=postgirl.ripe.net)
by mamba.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63)
(envelope-from <hank@efes.iucc.ac.il>) id 1RBis6-00076C-NY
for db-wg@lists.ripe.net; Thu, 06 Oct 2011 10:00:02 +0200
Received: from efes.iucc.ac.il ([128.139.202.17])
by postgirl.ripe.net with esmtp (Exim 4.72)
(envelope-from <hank@efes.iucc.ac.il>) id 1RBis4-0007io-NL
for db-wg@ripe.net; Thu, 06 Oct 2011 10:00:02 +0200
Received: from hank-lenovo.efes.iucc.ac.il (adsl-v01-32a5522ebb.tau.ac.il
[132.66.222.13])
by efes.iucc.ac.il (Postfix) with ESMTP id 0578131809A;
Thu, 6 Oct 2011 09:59:59 +0200 (IST)
Message-Id: <5.1.0.14.2.20111006095705.0371e888@efes.iucc.ac.il>
X-Sender: hank@efes.iucc.ac.il
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 06 Oct 2011 09:59:56 +0200
To: Shane Kerr <shane@time-travellers.org>
From: Hank Nussbacher <hank@efes.iucc.ac.il>
In-Reply-To: <1317887377.2388.9.camel@shane-desktop>
References: <5.1.0.14.2.20111006092114.0371d310@efes.iucc.ac.il>
<5.1.0.14.2.20111006092114.0371d310@efes.iucc.ac.il>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-MimeHeaders-Plugin-Info: v2.03.00
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points: -2.4 points
pts rule name description
---- ---------------------- ------------------------------------
-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
X-RIPE-Signature: 57c56c6cbff8e395d6a17d1fa814ff53b4ac6296abfc3d99e09b6056886e9547
Cc: Database WG <db-wg@ripe.net>
Subject: Re: [db-wg] Geolocation data prototype in the RIPE Database
X-BeenThere: db-wg@ripe.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: RIPE Database Working Group <db-wg.ripe.net>
List-Unsubscribe: <https://www.ripe.net/mailman/listinfo/db-wg>,
<mailto:db-wg-request@ripe.net?subject=unsubscribe>
List-Archive: <https://www.ripe.net/mailman/private/db-wg>
List-Post: <mailto:db-wg@ripe.net>
List-Help: <mailto:db-wg-request@ripe.net?subject=help>
List-Subscribe: <https://www.ripe.net/mailman/listinfo/db-wg>,
<mailto:db-wg-request@ripe.net?subject=subscribe>
Sender: db-wg-bounces@ripe.net
Errors-To: db-wg-bounces@ripe.net
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points: -2.4 points
pts rule name description
---- ---------------------- ------------------------------------
-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
X-RIPE-Signature: 3864f41e5f687a91347c2a5b83511719b4ac6296abfc3d99e09b6056886e9547
At 09:49 06/10/2011 +0200, Shane Kerr wrote:
>Content-Transfer-Encoding: 7bit
>
>Hank,
>
>What do you propose exactly?
>
>Should we ask the RIPE NCC to e-mail each holder of an ERX block and
>help them update their country code?
Yes. Take each ERX block that was moved from ARIN to RIPE and autosend an
email to tech-c and admin-c and ask what they prefer to change the country
code in that file to. The inetnum object already reflects the proper
country code in 99% of the cases, but for some reason when ARIN and RIPE
did the transfer years ago the delegated-ripencc-latest was ignored and all
objects got recorded with country=EU. Give a time limit of 3 months after
which no more changes allowed.
Regards,
Hank
>Should they make a best guess based on routing (RIS probably has a broad
>enough view to handle anycast addresses and the like too) and set the
>country code to that country if the ERX holder does not get back within
>a certain time?
>
>Or... what exactly?
>
>On Thu, 2011-10-06 at 09:25 +0200, Hank Nussbacher wrote:
> > At 15:29 05/10/2011 +0200, Denis Walker wrote:
> >
> > Rather than make new toys, sure would have been nice if RIPE saw the
> > justification of fixing up and correcting the country code listing for ERX
> > prefixes (from 2004) in delegated-ripencc-latest, that list all ERX
> objects
> > as country code=EU. Team Cymru, among others, use that for
> > geolocation. But alas, the answer I received from RIPE was basically
> - No.
>
>--
>Shane
participants (7)
-
Arkley, Patrick -
Denis Walker -
Dennis Yusupoff -
Hank Nussbacher -
Hendrik T. Voelker -
Randy Bush -
Shane Kerr