Re: [Asrg] Projecting

On Nov 29, 2008, at 1:08 PM, Barry Shein wrote:
> On November 29, 2008 at 11:07 mike(_at_)mtcc(_dot_)com (Michael Thomas) wrote:
> > Bart Schaefer wrote:
> > > On Nov 29,  7:49am, Michael Thomas wrote:
> > > > That's pretty much why this email postage stuff is a waste of  
> > > > time. Even if it were wildly successful, what other part of the  
> > > > net would you want the spammers to focus their huge resources on  
> > > > instead?
> > > Don't bother treating your termite problem, they'll just move next  
> > > door?
> > Not really. It's more like we have a pretty well known front line  
> > for this war. We're "winning" at an abstract level because email is  
> > still usable, even at the cost of its war of escalation. If we  
> > really "won" a final victory in email, they'd just pick a new  
> > battlefield to play on. So we get the choice of containment where  
> > we're doing ok, or fighting on a completely new battlefield where  
> > who knows what the dynamics will be. Wishing for what you might  
> > get, and all of that.
> This projects an image of one, unified "enemy".
>
> Closer to the truth is many miscreants, most unrelated, each also  
> competing with each other so each fully motivated to do whatever  
> they possibly can right now.
If DKIM's  i= values were assured by the d= value to opaquely  
represent the entity authenticated when accepting the message sent,  
then it would be possible for a (~30,000x scaled) reputation systems  
to identify sources of abuse.  Often, these sources represent several  
hundred million compromised systems, and _not_ individuals.   DKIM was  
not intended to track the message's "author", rather it tracks the  
domain and "on-behalf-of" identifiers.  These identifiers could  
represent a shared account, a client's IP address, or even a trusted  
relay.   Even if there was a scheme that ensured "author" identities  
(a dangerous notion),  it would be much less effective at locating the  
real culprits, compromised systems.
It is not hard to imagine why large providers wish to ignore accounts  
using compromised systems, as these represent extremely expensive  
support issues.  Once IPv6 opens the door to 340,000 decillion (10^33)  
IP addresses, the granularity of evidence collection and blocking can  
not be retained at the IP address.  Any attempt at using IPv6 will  
require granularity that approximates network routes.  Such  
granularity would be analogous to using large IPv4 CIDR blocks.   
Granularity at this level often results in collateral blocking, the  
bane of network providers.  While the infection rate of computers  
remains high, an escalation in the battlefield should at least  
represent a means that tracks the true culprit.  Blaming an often  
hapless email-address that a provider pretends to authenticate does  
not represent a fair solution, and is one likely to benefit confidence  
artist that will exploit a pretense of "author" authentication.
To scale a system that attempts to comprise such enormous scale of  
either the entire domain/on-behalf-of or IPv6 address space, this will  
likely require two transactions.  One transaction to squelch abuse at  
higher granularities, and a second transaction reserved for those that  
exhibit reasonable levels of abuse.  The complexity of the IPv6  
addressing, which includes carrier grade NATs or third-party  
translation services, means IPv6 addresses will not be stable enough  
to track compromised systems.  Currently, compromised system activity  
already transitions to different systems daily where repeated use may  
span months.  The use of IPv6 will make any reputation service a  
futile whack-a-mole game using a hammer that can not reach across the  
vast number of holes.  A solution for the reach of the hammer should  
not advocate a bigger hammer covering more holes.  This game may  
require the use of two hammers.  The cost of playing the game may  
require the use of DKIM.
-Doug


_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg