ietf
[Top] [All Lists]

Re: "Principles" of "Spam-abatement"

2004-03-17 13:17:25
On Wed, 17 Mar 2004, Eric A. Hall wrote:

A better analogy is with new checking accounts. Many places won't accept
checks numbered below 1000, since they indicate that the account has not
established a track record. Other places will accept the checks after
verification, other places will accept them with thumbprint or some other
identifier. In all these cases, the organization is able to determine its
risk limits and act accordingly.

Which is really pretty silly, right?  Since anybody will print you
checks that start with any number you like, completely legally.  In
fact, you can print your own checks with any number(s) you like,
completely legally, as long as the bank information at the bottom is
there and is correct and you actually own the account in question and
don't commit fraud or pass bad checks.

This kind of silly response is no obstacle to a criminal or spammer; it
is merely an inconvenience (a pain in the ass) to the innocent.  It also
leaves one with all sorts of catch-22 problems -- one cannot get a "track
record" until one is let onto the track, and one cannot get onto the
track without a track record.

Besides, this is all talking about >>IP numbers<<, right, since we all
AGREED that user "identies" were transient artifacts and impossible to
regulate.  In the checking account metaphor above, on the internet I can
print a new check with whatever numbers you like for each and every
transaction, and back it up with a shiny new driver's license and any
other "identification" tokens you require unless and until you create a
huge government bureaucracy to regulate it and harsh laws to punish
abuse.  Sort of like the ones we have for real driver's licenses and
checking accounts and human identities.  Banking (and other human
metaphors) are not correct for addressing IP number trust.  It's more
like can you trust the current residents of this neighborhood or that
house down the street...when you never get to see them, only their
masks.

And IF we're talking about IP addresses, we can pretty much stop
talking.  As Vernon has repeatedly pointed out, "trust"-like facilities
at the IP level are either ALREADY THERE and proving to be moderately
ineffective against spam or run square against the economics and
realities of the SP business.  We cannot do anything silly like "not
trust" a new IP number assigned by an SP to a new customer "until they
have a track record".  Trusted has to be the default or the Internet and
a variety of business become impossible and incredibly burdensome on the
innocent (far more so than spam).  But I don't care if you agree -- as
you note, you can "not trust" any parts of IP space you choose according
to any criterion you select, within your own hosts or networks.  Just
don't blame anybody else when things stop working because you've punched
a hole through a path to a critical service or human.

Note that this is nothing new. We already do this with IP numbers.
If you send me a packet with a non-verifiable source IP there 
will be no communication possible. Why should it be different 
with email addresses?

Verification is different from trust. My position is that you need to be
able to validate and verify before you can successfully apply any kind of
trust (otherwise the trust is meaningless). Paul's message that I replied
to was specifically describing a minimum threshold of trust (it was akin
to the "no checks below #1000" position).

You have to be able to quantify "trust" as well, in order to be able to
use it as a filtering criterion.  I fear that your metaphor is exact --
it is NO more difficult for a spammer to achieve whatever level of
"trust" is required for acceptance for long enough to spew than it is
for me to ask the bank to start the checks for my brand new checking
account at #2000 "since of course some merchants won't take them
otherwise".  Or going home and printing some new ones.

Somebody (Dean?) pointed out that if you can really solve the problem of
"trust" at the electronic level, scalably and more or less for zero
marginal cost, you're missing the real point.  These are the SAME
problems that are incredibly difficult to solve in the financial
industry where the penalties are large and expensive, laws that severely
punish identity theft artists and check forgers are vigorously enforced,
and where instruments for reasonably reliably affirming identity (photo
drivers' licenses, passports, birth certificates all abound and are
tightly constrained by law and expensive government agencies and
services.  It's hard to trust even paper money, let alone that some
stranger is who they assert themselves to be.

In that sense it is an excellent milieu to look for metaphors to the
network/spam/identity problems, just as paper spam and phone spam are
also good places.  If you can solve one, you can solve the other IF you
are willing to pay similar costs.

So next time anyone wants to advance a human-scale metaphor for a trust
model, please a) ensure that it actually is relevant and WORKS (check
numbering obviously is less than useless); b) discuss the costs.  Human
identification mechanisms are awesomely expensive and still don't
prevent identity theft, forgery, and all sorts of abuse.  And they don't
apply to IP number trust.

Don't get me wrong -- I do think that there is something to be said for
focussing on IP numbers (NOT humans) and "trust" (if that's what you
want to call blacklisting).  I jut think Vernon, and Dean, and Jeff are
all correct.  The IETF will not fix spam in protocol.  Spammers will
work around and through any holes left available.  SPs leave holes.
Until they stop doing so spam will continue.  This isn't QUITE an
impasse -- but suggestions need to focus on this particular kernel and
become concrete and less metaphorical.  I think we are all agreed that
IF SPs really tried to police their IP spaces the spam problem would be
ameliorated to some degree.  Even Vernon said as much, and Vernon seems
to be both insanely realistic and perhaps a touch, shall we say,
cynical?

So:

 A) Let's stop talking about trust models as if they extend to humans.
We aren't talking about trusting the "sender" of any message; we are
talking about trusting the IP number of the originating host of that
message, or alternatively the DNS owner of the subnet blocks where that
IP number resides (the SP).

 B) Trust is going to be the default.  This is OK because network
addresses have sufficient persistence in time and are sufficiently
difficult to change and are hierarchically organized.  Besides, the
network will rapidly break if trust isn't the default.

 C) No solution will work until the SPs buy in.

 D) SPs >>might<< buy in if spam reporting is streamlined, spam
reporting is independently tallied, blacklist decisions were made on the
basis of an open and clearly defined process and on the basis of
publically available data (e.g. the number of spam reports made back to
a given subnet in a given time window).  Jeff thinks this is a place to
start work and I agree.

 E) We're really talking about all forms of local-origin mail-based
network abuse, not just spam.  Virus reporting and response is in the
same category -- done haphazardly in an expert-friendly fashion (if done
at all).  As Dean has pointed out, many spam agents are architecturally
identical to viruses and sometimes appear to BE viruses, long out of
control of their creators and hawking products that no longer exist with
links to dead webspaces.

I personally think that "trust" is the wrong metaphor for a
trusted-default network.  D) is the meaty one above.  If there is
anything that the IETF CAN do to help cut this particular knot, it is to
create a relatively simple extension to mail that facilitates reporting
mail abuse, and collection of abuse reports by multiple parties for
tallying and blacklist decisions.  This puts real pressure on the SPs to
clean up their nets.  I'm not even sure that this pressure would be
necessary if spam were reported agressively and in a timely way and with
the data required to actually RESOLVE the complaint included IN the
complaint (note that Dean, obviously an expert, has to work to extract
it from certain bounces -- what hope does an ordinary user have?). Most
SP admins I've met or talked to are decent humans and take managing
their networks seriously.  Give them the tools to police their networks
and I think they'd prove responsive.

   rgb

-- 
Robert G. Brown                        http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     
email:rgb(_at_)phy(_dot_)duke(_dot_)edu