Re: [Asrg] C/R Thoughts: Take 1

Vernon Schryver <vjs@calcite.rhyolite.com> Tue, 13 May 2003 19:32 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26818 for <asrg-archive@odin.ietf.org>; Tue, 13 May 2003 15:32:55 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DIx5m21905 for asrg-archive@odin.ietf.org; Tue, 13 May 2003 14:59:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DIx4B21902 for <asrg-web-archive@optimus.ietf.org>; Tue, 13 May 2003 14:59:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26814; Tue, 13 May 2003 15:32:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FfXZ-00076m-00; Tue, 13 May 2003 15:34:21 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FfXY-00076j-00; Tue, 13 May 2003 15:34:20 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DIvBB21759; Tue, 13 May 2003 14:57:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DIuxB21711 for <asrg@optimus.ietf.org>; Tue, 13 May 2003 14:56:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26709 for <asrg@ietf.org>; Tue, 13 May 2003 15:30:19 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FfVX-00075H-00 for asrg@ietf.org; Tue, 13 May 2003 15:32:15 -0400
Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx with esmtp (Exim 4.12) id 19FfVW-00075E-00 for asrg@ietf.org; Tue, 13 May 2003 15:32:15 -0400
Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h4DJXG9k022281 for asrg@ietf.org env-from <vjs>; Tue, 13 May 2003 13:33:16 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305131933.h4DJXG9k022281@calcite.rhyolite.com>
To: asrg@ietf.org
Subject: Re: [Asrg] C/R Thoughts: Take 1
References: <5.2.0.9.2.20030513135742.00ba06b8@std5.imagineis.com>
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/asrg/>
Date: Tue, 13 May 2003 13:33:16 -0600

> From: Yakov Shafranovich <research@solidmatrix.com>

> ...
> Instead of storing the actual email address in the database, we might store 
> a one-way hash of it, lets say MD5. When emails are sent and received, the 
> sender's email address is hashed and compared against the database. This 
> way if anyone ends up wanting to use the database, it would be impossible 
> since there will be no email addresses in it. Of course it would still be 
> possible to check a specific email address against or use some form of a 
> dictionary attack, ...

Which implies that in the cases that matter, nothing is hidden.  Dictionary
attacks are easy when you know what you're looking for.  This is one
reason why the DCC procotol does not include a checksum for the target.
That's not a complete solution, but it's not as bad as the C/R case
where the database would consist of a recipient and a set of senders.

It seems me that the right answer for a C/R system is to treat the
data as equally sensitive as users' addressbooks.  Do not use
crypto-hashes, lest you tempt the unthinking or salescritters into
claiming that the data is not sensitive.  Never unthinkingly trust
third parties with the C/R database.


> ...
> And last, another concern that has been bothering me with C/R, is the 
> possible death of anonymous remailers with such system. ...

Such concerns assume that C/R systems might be used by a majority of
users.  Doesn't experience with existing C/R systems show that is unlike?

One of the saving graces of a C/R system is that it does not need to
be deployed over most of the Internet before it has any effect.  Don't
waste that advantage by treating it as if it were or could be the final
solution against spam.


Vernon Schryver    vjs@rhyolite.com
_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg