DKIM implementations SHOULD support replay protection (was: Re: [ietf-dkim]Re: Replay attacks and ISP business models

Amir Herzberg herzbea at macs.biu.ac.il
Mon Aug 8 08:10:33 PDT 2005


John R Levine wrote:
>>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.
> 
> 
> Eeewww.  When the SPF crowd said that every mail forwarder in the world
> would have to be upgraded to rewrite the envelope to work around a flaw in
> SPF's design, we all threw rotten tomatoes at them.
> 
> Surely you do not want to send DKIM down the same road.

Of course not. Existing mailing lists and other forwarders can happily 
exist in DKIM world as-is. It is just that they do not provide `full` 
DKIM, but `only` DKIM without replay protection (class 2) - which is the 
_only_ option we'll have, if we don't provide the (optional) replay 
protection.

Actually, I'm not precise here, since forwarders could also provide 
`full` DKIM (with replay protection) by simply signing their messages - 
i.e., taking responsibility for them (and using their favorite 
mechanisms to deal with bad senders/subscribers). Again, of course, this 
is optional.

The point is that replay protection is _critical_ for automated 
reputation and compensation mechanisms. So it would be a real loss if 
DKIM does not allow replay protection, which will work fine in many 
cases, e.g. without forwarding. OTOH, I agree that we should not require 
recipients to discard incoming mail just because it is not 
replay-protected. Recipients still have DKIM guarantee of origin in this 
case, and can decide whether they are willing to take the replay-risk 
based on the sending MTA identity, reputation, etc.

I admit this is some added complexity. I even agree that in the desire 
to KISS, we may prefer to make support for it optional (MAY/SHOULD not 
MUST). But it seems to me that we should make a goal of DKIM supporting 
(optional) replay protection. Unless there is some reason I'm missing.

-- 
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


More information about the ietf-dkim mailing list