ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] draft-ietf-dkim-threats-00 Overlooking a practicalsolution while also recommending a highly unfair solution

2006-01-24 19:11:59

On Jan 24, 2006, at 4:55 PM, <Bill(_dot_)Oxley(_at_)cox(_dot_)com> <Bill(_dot_)Oxley(_at_)cox(_dot_)com> wrote:

I would like to say that the only thing that a properly resolved dkim sig suggests is that the message came from the signing domain, no more no less. It allows better resolution of responsibility without any absolute assigning of same.

Without a strategy to prevent replay abuse, DKIM is indeed limited to identifying the initial domain of a message. Within the typical domain, a torrent of abuse may be derived from an extremely difficult to detect series of messages sent slowly from perhaps thousands of compromised systems. However, these messages may be replayed a billion fold when redirected. Identifying the initial domain does not indicate whether the domain is also capable of preventing even small amounts of abuse bearing their signature. Most can not. The use of the signature as a means for basing acceptance, either by way of white-listing, or by reputation, will be eviscerated by replay abuse. The signature will not remain suitable as a basis for acceptance.

The signature may still permit differentiation between a phish and a financial enterprise using registered recognitions at the MUA or within filters. Phishers will be able to sign messages, and that also greatly weakens a sending policy conformance strategy.

Holding the recipient domain accountable for replay abuse would be a viable means to control this exploit. The recipient domain needs to ensure all signatures are overlaid with the verification results prior to delivery to the mailbox, preferably at the edge of the AdmD. The sending domain needs to ensure the recipient domain is secure and has adopted the overlay practice.

-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org