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

[Amir Herzberg <herzbea@xxxxxxxxxxxxxx>]

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