[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

At 10:48 AM 5/13/2003 +0100, Jon Kyme wrote:


> Per the request to put together ideas regarding C/R systems below is a
> brief
> inventory of some possible areas for a C/R standardization effort. I'm
> not
> advocating standardization of any of these...but rather identifying areas
> that to some are obvious.  The MUST, SHALLs, and MAY's can follow later:
>

I wonder if there's a case for taking some position on the privacy issues
involved in CR systems?

Issues like this:
http://www.toyz.org/SpamArrestSpams.html

Summary: Alleges SpamArrest harvests sender addresses
SpamArrest behavior is no different from a regular MTA operator or an ISP harvesting email addresses from all incoming and outgoing email. The only difference is since a C/R system must keep a list of verified email addresses, this makes it easier.

There are a few additional concerns. For example, the entire "verified" sender list as related to a specific email account is essentially a record of all people who sent emails to that user (its his address book essentially). What keeps the government from issuing subpoena against that information or some hacker breaking in and stealing it? I can easily hear an industry executive, lets say john.doe@microsoft.com, being fired for flirting with competitors via some email system after Microsoft obtained the his verified senders list via a subpoena. Or a Chinese dissedent being executed after a government hacker steals his "verified" senders database. One other possible concern is the possibility of spammer stealing the entire "white list" database. The same concerns also apply to a block list that is kept by users. Even though it is possible to avoid SOME issues by using a system wide white-list of verified senders instead of user-specific white-lists, a block or blacklist must be specific to each user.

A possible way around might be is based on approaches outlined by Peter Wayner in his book "Translucent Databases" regarding storing private data. 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, but that is left to be discussed (using a salt value will not help since we are trying to avoid the possibility of someone who has access to the database from using the data).

And last, another concern that has been bothering me with C/R, is the possible death of anonymous remailers with such system. There are numerous one-way anonymous remailers in existence, many of which are mixmaster-based. They allow people to send anonymous email one way which may be very important for people in countries with oppressive regimes. With a C/R system these remailers would essentially be killed unless their administrator starts replying to each message individually. Spammers currently do not use anonymous remailers (at least I am not aware of it) since they have many other ways to send spam. Will they start using them, if other tactics will not work?

Yakov

---------------------------------------------------------------------------------------------------
Yakov Shafranovich / <research@solidmatrix.com>
SolidMatrix Research, a division of SolidMatrix Technologies, Inc.
---------------------------------------------------------------------------------------------------
"One who watches the wind will never sow, and one who keeps his eyes on
the clouds will never reap" (Ecclesiastes 11:4)
---------------------------------------------------------------------------------------------------
_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg