Re: [ietf-dkim] Replay isn't the problem, spam is the problem

On Aug 8, 2005, at 11:20 AM, John R Levine wrote:

> > The point is that replay protection is _critical_ for automated
> > reputation and compensation mechanisms.
> People keep saying this as though it's obvious.  I must be  
> unusually dim
> today because it's not obvious at all to me, and doesn't seem to  
> have been
> obvious to designers of previous signature systems.
>
> Do you check CRLs on S/MIME mail?  (They are turned off by default  
> in many
> MUAs.)  PGP seems to have no way to deal with replay at all.  Is  
> that why
> it hasn't caught on?
Neither S/MIME or OpenPGP are widely used, nor is there a reputation  
system supporting these schemes.  DKIM has different goals.  DKIM  
lowers the efforts for wide deployment by using domain-wide keys.   
The strong domain authentication permits name-based reputation  
systems which are freed from concerns of collateral damage or path  
registrations.  Should DKIM prove successful at deterring abusive  
traffic, there _will_ be efforts to defeat the protection DKIM offers.
> Doug has offered the only scenario so far of a replay attack, which is
> very helpful to figuring out what the threat is.  His scenario  
> boils down
> to one of a domain's users being a spammer, which would be a problem
> whether or not his spam was being remailed.
While indeed a domain will still need to deal with abusive accounts,  
this is normally done by disabling access.  However, this approach  
will not offer reasonable protections against replay tactics.  The  
revocation-identifier could help identify accounts that attempt to  
distribute through the signing servers, AND that attempt to  
distribute replays through other servers.  Revocation-identifiers  
would be an effective tool in either case, and is often used by large  
providers for the same reason.  Revocation-identifiers simply  
establish an optional convention to permit this opaque identifier be  
a means for replay protections.
> That's a reasonable concern, we should look at ways to deal with it.
> One approach is to give each user (or at least each untrustworthy  
> user) a
> separate selector, so you can withdraw the selector if the user turns
> bad.
This user-key solution is not as good, in my view.  A domain with 40  
million accounts would be offering about 16 GB of public keys to  
support this approach.  Large domains, or even smaller domains, would  
not find any account particularly trustworthy, due to the prevalence  
of zombie systems and the relative ease these systems become  
compromised.  Should many domains of this size employ this approach  
of providing separate user-keys, there would be a potential for  
needing a cache exceeding typical server memory constraints.  Not  
caching keys further exacerbates the orders of magnitude of traffic  
increase this approach already requires.  Here things tend to break.
>   It might be worth adding a flag to the DNS record that says that
> even though the signature is good, the mail is bad, a stronger  
> statement
> than merely voiding the selector.
The revocation-identifier allows a domain-wide public key to be used  
while also providing a solution for replay abuse, and thus creates  
less of a DNS burden.  Just as black-hole lists are commonly queried  
per connection, a query to a bad-list should provide roughly the same  
overhead.  The impact on the cache should be minor, as the vast  
majority would be negative results.  Even this query can be mitigated  
by authenticating the HELO first.
> But really, the threat model for replay isn't there.  The examples  
> are all
> exotic, contrived, and implausible, the remedies worse than the  
> purported
> disease.  Let's deal with serious threats, OK?
Only having user-keys as a solution for replay abuse is a concern.   
Should DKIM become successful at providing a name basis for  
reputation, there will be motivation to steal good reputations.  User- 
keys have been problematic, but then this is suggested as a solution  
should replay becomes a problem.  User-keys in DNS may also be worse  
than the disease, and could be a serious threat in my view.
I don't think it would be implausible for someone to send themselves  
spam at a different account just to have it signed.  The period of  
time that must be alloted to ensure delivery affords a significant  
grace period where it would be impractical to disqualify this  
particular account without using user-keys or having a revocation- 
identifier mechanism.  For the user-key approach to be effective, it  
would need to have short TTLs as well.  In all likelihood, these keys  
would be excluded from the cache anyway, but to the detriment of  
overall email performance.
As an alternative, when there is an abusive account detected, the TTL  
on the bad-list based upon a revocation-identifier could be long to  
ensure low overhead for even the most egregious cases of a replay  
attack.  I don't see dealing with a replay attack that seeks to  
utilize the access provided by a domain's otherwise good reputation  
as exotic, contrived, or implausible.  Having a revocation-identifier  
mechanism which is relatively DNS friendly is simply being prepared.
DKIM provides a strong means to verify an accountable domain.  HELO  
authentication in combination with DKIM offers a means to establish  
DoS protections and to mitigate the overhead related to revocation- 
identifier replay protection.  This does not require user-keys.  This  
does not require abusing DNS as a solution for a probable threat.   
Why then and not now is answered when DKIM becomes a common mechanism  
supporting reputation.
-Doug
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim