Subject: [Asrg] DCC and IP addresses

From: "David F. Skoll" <[email-masked]>
Date: Fri, 7 Mar 2003 16:50:45 -0500 (EST)

> The DCC can also collect hashes of IP addresses.  At Paul Vixie's
> suggestion, early versions could answer questions like "how many messages
> with this body checksum had this source IP address?"

That's not what we want.  We want to answer this question:

"Has the message with this checksum originated from more than X distinct
IP addresses in the last Y hours?"

This query lets you detect open-relay and proxy abusers.

Although it looks like the DCC servers have to collect the IP
information, they don't have to give it out.  So the potential for
abuse is limited to the people who run the DCC servers, not to anyone
who can query them.

> Please also consider the amount of data you are talking about.  You
> will probably collect 500 or 1000 bytes per mail message.

No; way less than this.  For a mail message, we collect the body
checksum, the sending-IP checksum and maybe a few flags indicating
failed RCPT commands.  At most 60-100 bytes/message.

> If you sample 1% of mail, and accept my guess that's 100 M msgs/day,
> you're talking about collecting and reducing 100 GBytes of data/day.

I'm thinking 10GB/day.

You're right; the current DCC scheme of flooding breaks down.  So we
use a DNS-like approach.  A network of DCC servers are responsible for
different portions of the checksum space.  So if we're interested in
a message with checksum abcd1234..., the "root" DCC servers tell us which
servers collect statistics for the abcd... subspace.  Within a given
subspace, you can use flooding for redundancy.

> You'd need to
> repeat your measurements every day for a week, because spam varies
> during the data and during the week.  You'd also want to repeat it
> every few weeks to catch long term changes.  Arithmetic gives numbers
> that would need a serious source funds.

Or a more scalable architecture than flooding the database.

--
David.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 7 Mar 2003 16:01:35 -0700 (MST)

> From: "David F. Skoll" <[email-masked]>

> ...

That's not an effective response to the privace issues.  As I said,
that reasoning seemed almost ok when it was thought that DCC servers
would be run by one organization.  The current, real life global
network of ~120 DCC servers already involves far more people and
organizations than I think can be trusted.  It's not that any single
DCC server operator is untrustworthy, but that every group of 120 or
more people is untrustworthy.

> ...

If I thought you knew how to make a single checksum that is fuzzy
enough to ignore "hashbusters" but not so fuzzy that it has false
positives, I'd ask you in private about it.  I've spent years
thinking about that problem and listening to other people's ideas.
My imperfect current solution involves 3 checksums.  A single naive
checksum would discover no two IP addresses ever send the same
message, except for trivial cases such as some virus warnings,
because its answers would all differ.

> ...
> You're right; the current DCC scheme of flooding breaks down. 

I suspect you don't understand it, because the DCC scheme of flooding
doesn't just break down for what you are talking about; it's irrelevant.
DCC serves database currently run at 100-400 MByte.  The default
non-spam expiration for the cheksums in the databases averages 1.5
days.  At 20 Mmsgs/day, that's 30 Msgs, or 1-4 bytes message.  While
I'm a hopeless, old-school bit-fiddler, I can't cram 3 16-byte MD5
body checksums, flags, pointers, and the rest of the stuff needed for
a database into 1-4 bytes message.

> ...

While this mailing list is under the auspices of the IRTF, it should
not be used for unsupported wouldn't-it-be-nice-if speculation.
"Running code" often matters even IRTF lists.  I've already said more
than I should have about the practicality what the proposal.

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 7 Mar 2003 20:46:33 -0500

>would be run by one organization.  The current, real life global

So why give you the IP address?  Why not encode it with a one-way 
hash/encryption?  All IP addresses will code the same, but the 
database will have no way to determine what IP addresses were passed.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 7 Mar 2003 22:39:42 -0700 (MST)

> From: Kee Hinckley <[email-masked]>

> database will have no way to determine what IP addresses were passed.

One-way hash functions are relevant only when the plaintext is
unknown.  If the bad guy knows the plaintext such as an SMTP sender
or an IP address, then the bad guy can compute the hash.  He can
trivially invert the hash function.

For example, assume the checksum database has records that contain
"cksum(IP address) sent cksum(msg)" and you can somehow guess the
contents of the message and the block 10.1.0.0/16 of addresses. 
Then you can make a few thousand queries of the form "how many messages
with cksum M were sent from the address with with cksum I" to discover
whether that message was sent and if so from which IP address.

The privacy problem is like that of the U.S. Census.  How do you
release some of the Census data without releasing all of it?  For
example, assume the system refuses to answer the question "what was
the household income of the family as 124 Main Street?" but will answer
general queries like "how many families living on the 100 block of
Main St. have at least 2 children and an income of more than $10,000?"
or "how many families on the North side of Main Street and fewer than
3 children have an income of less than $20,000?"  Unless the system lies,
you can trick it blabbing the forbidden answer.  Even if the system lies,
it's hard to be sure it won't blab through a tricky series of questions.