[ietf-dkim] Re: Replay attacks and ISP business models
herzbea at macs.biu.ac.il
Mon Aug 8 06:07:58 PDT 2005
John R Levine wrote:
>>>indistinguishable from a "replay attack." I'm still waiting for someone
>>>to explain how you stop replay without also wrecking mailing lists, other
>>>that by implausibly labor intensive approaches like manually whitelisting
>>>every legitimate remailer in the world.
>... what mailing lists
> normally do, with no abuse at all, no spammers involved, nothing other
> than what they do every day in correct operation, is identical to a
> "replay attack",
> Any so-called replay prevention scheme is a direct attack on the normal
> operation of mailing lists. Can I make that any clearer?
Good point: automatically rejecting forwarded DKIM mail may interfer
with current mailing lists. However, I think John is too quick in
concluding that this prevents any `so-called replay prevention scheme`.
Or in other words, maybe we can control replay, rather than flatly
reject (prevent) any replay.
Controlling replays implies that when we receive e-mail, we identify
three DKIM classes:
Class 1 (non-DKIM) - Unsigned mail (i.e., no DKIM services).
Class 2 (no-replay-protection DKIM) - Signed (DKIM) mail w/o
replay/destination protection. Here, the current destination is not
covered by the signature (typcially, the original destination was
mailing list, which just forwarded this message).
Class 3 (`full` DKIM) - Signed (DKIM) mail with replay/destination
protection. Here, the destination is signed (or just a hash of the
destination, possibly using hash tree, for privacy and efficiency).
Mailing lists and other forwarding services will need special
DKIM-enhancements to provide this DKIM service. This will not work of
course for current forwarding and mailing list systems (but will work
for enhanced, DKIM-supporting systems)
Recipients do not have to discard e-mail from classes 1 or 2. Indeed,
they are not likely to do so, at least in the near to medium term.
However, this does give DKIM the ability to protect against replay.
Namely, blacklist servers will be aware that class 2 DKIM does not
protect against replay - and will not be hasty to conclude that the
responsibility for the spam is on the original sender. It may be on the
forwarding agent - a mailing list or a Zombie.
p.s. this message is cross posted to MASS WG since John sent there his
post (and also I sent my orignal note there), but please respond to
IETF-DKIM since discussion moved there.
Department of Computer Science
Bar Ilan University
Try TrustBar - improved browser security UI:
Visit my Hall Of Shame of Unprotected Login pages:
More information about the ietf-dkim