ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: Replay attacks and ISP business models

2005-08-08 05:22:12

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.
--
Best regards,

Amir Herzberg

Associate Professor
Department of Computer Science
Bar Ilan University
http://AmirHerzberg.com
Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame