On Mon, 2005-08-08 at 15:20 -0700, Jon Callas wrote:
Forgive me my ignorance, but I don't understand what's meant by a
replay.
There are three things that I think of as a replay. None of them are
affected by features like "user-level" keying. Furthermore, none of
them are to me distinguishable from a forwarder (like .forward).
A replay would be both a valuable feature of DKIM, but also a problem
when this feature is abused. Replay would be reissuing the same message
to different recipients. There is no need to define abuse.
So, obviously, I'm missing something. Can we simplify this down to a
short description of what a replay is. Quick little scenario.
For example, here's one thing that I could envision being called a
replay:
Advertiser.com sends a legitimate mail to Alice. Alice takes that mail
and sends it to 50 million of her closest friends. These 50 million
people get angry at advertiser.com.
This would be describing replay abuse. When keys are shared among a
large portion of the domain users, rapid key invalidation is not
practical due to the collateral damage it would cause. The domain could
use the expiry tag to ensure perhaps there would be only a few days
where the messages appear valid. Of course, the abuser may also utilize
the old trick of adding a false bounce address in hopes this signature
check happens after the message has been received, should the signature
expire.
The accountable domain may become aware of replay abuse via feed-back
mechanisms within minutes of an onset of a spam run. Alas, unless this
domain employs user-keys with short TTLs, the duration permitted the
miscreants is extended to the duration alloted for normal delivery. If
this delivery duration, in an effort to abbreviate replay abuse
exposure, is made too short, signature expiration may simply become
ignored as an ongoing nuisance.
Without any other mechanism to rapidly address a replay abuse issue,
user-keys currently represents the solution provided by DKIM. However,
this user-key mechanism should be removed or the number of selectors
constrained to avoid allowing DNS being abused by an inordinate number
of keys as a reaction to this replay abuse problem.
As described, a revocation-identifier would enable an alternative
solution which does not pose the same risks, and yet can rapidly address
replay abuse. All users could share the same signature key, yet there
would be no collateral damage when a specific account is disabled
following reports of abuse. This mechanism could be used irrespective
of there being replay abuse. This would permit removal of messages
still in transit, in addition to preventing messages being reissued.
The revocation-identifier offers several benefits such as improving
abuse correlation and offering domain action feed-back, so perhaps I
should ask why is there resistance to permitting this mechanism, in lieu
of issuing user-keys?
-Doug
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim