Re: [db-wg] Geolocation data prototype in the RIPE Database

7 Oct 2011

      ...
...
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