ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] draft Errata on RFC 4871

2009-01-30 19:02:11

Suresh Ramasubramanian wrote:

On Sat, Jan 31, 2009 at 12:15 AM, Douglas Otis <dotis at mail- 
abuse.org> wrote:

Large domains will almost always have some small percentage of  
problematic accounts.  If the d= parameter becomes a significant  
basis for acceptance, then replay abuse will need to be controlled.

You are confusing authentication with reputation.

Authentication is going to be managed with a whole lot of other  
ways rather than being solely dkim based

As for rep - one individual sender's rep really shouldnt taint all  
the ISP (or all the d=) rep unless it is pretty damned bad.

Suresh,

Normally, acceptance is based upon the IP address of the SMTP client  
where DKIM offers an identifier that is independent of SMTP clients.

Unfortunately, this independent freedom allows DKIM messages to be  
replayed.  Resolving acceptance for DKIM (d=, i=) instead of just DKIM  
(d=) can remedy possible replay abuse with smaller data-sets than what  
is likely required to extend SMTP client data-sets to include IPv6  
addresses.

 And if the ISP / ESP lets the cause of that bad rep continue ..  
well, they deserve the bad rep.

There are hundreds of large domains with good reputations, where 1% or  
more of their outbound is comprised of spam or malware.  This level of  
abuse appears fairly representative, where some large domains send  
billions of messages daily.  1% of these messages quickly becomes  
fairly expensive to track, where even Bloom filters do not offer much  
relief.  However, when an account is rate limited to 500 daily  
messages, using the i= parameter reduces the size of the distributed  
information by a factor of 500.  In addition, the i= value allows  
receivers to anticipate what is likely to be abusive as well.

Currently, there are hundreds of millions of botnet systems  
erratically distributing email.  The number of sources, as well as the  
number of messages, used by botnets has grown in a dramatic and  
exponential fashion since 2005.

Large domains with good reputations control this situation by rate  
limiting accounts.  Unfortunately, replaying a DKIM message defeats  
rate limits whenever acceptance is based upon a DKIM domain.

Ever tried putting a single gram of (say) cyanide in a gallon of  
water?  The entire water is poisoned as a result.  In other words  
replay attacks arent the attack vector I am concerned about here -  
they are moot, to be frank and all due respect to the bee in your  
bonnet.

Unless there is a way to defend the use of a DKIM domain, there is no  
point in expending resources on DKIM domains.  The i= parameter allows  
the poison to be reduced to normal levels.  Without the i= parameter,  
the IP address of the SMTP client will need to be associated with the  
DKIM domain.  Such path registration makes DKIM less robust.

While replay abuse is not currently a pressing concern, this is likely  
due to DKIM domains not playing a significant acceptance role yet.    
As such, it seem premature to start changing RFC 4871 until there is  
greater reliance upon the DKIM domain, and after learning what is  
needed to defend its use.

-Doug







_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html