On 18/Sep/10 01:43, Douglas Otis wrote: > On 9/17/10 3:12 PM, J.D. Falk wrote: >>>> Today's reputation systems aren't static; the operators are >>>> constantly changing them in reaction to what the spammers >>>> do. >> Adjustments to reputation systems are necessary because spammers >> keep changing tactics, attempting to get around the reputation >> systems. > > When DKIM is used to white-list domains, this then runs the risk > of white-listed messages being replayed and directed to recipients > not intended by the signing domain.
Indeed, if replay attacks did not exist, there would be little reasons to be picky about message integrity. We would sign just "From" and get away with it --as some domains do. I wonder why the idea of binding messages' signatures to their destination domains hasn't been considered before. As Ian pointed out, this would limit replay attacks to a single destination domain. A different, though possibly related, idea is to use sequence numbers of some sort. For example, coupled with monotonically increasing "Message-Id"s, signatures can identify message streams consistently. This would require stateful verifications, though. Such wags should be interesting for DKIM as a whole, because they do limit replay attacks. It is not coincidental that they sprout on tackling MLMs, given the paradox these pose to DKIM, which is well stated in RFC 4686: Many mailing lists, especially those that do not modify the content of the message and signed header fields and hence do not invalidate the signature, engage in a form of signed message replay. The use of body length limits and other mechanisms to enhance the survivability of messages effectively enhances the ability to do so. The only things that distinguish this case from undesirable forms of signed message replay is the intent of the replayer, which cannot be determined by the network. -- I save reputation considerations for another list... _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
