On October 29, 2005 at 06:44, Eric Rescorla wrote: > S 5: > One of the most fundamental bad acts being attempted is the delivery > of messages which are not authorized by the alleged originating > domain. As described above, these messages might merely be unwanted > by the recipient, or might be part of a confidence scheme or a > delivery vector for malware. > > This seems to me to be too concrete. At a meta-level, the bad > act being attempted is the delivery of messages which the receiver > doesn't want to see (see Section 2 again).
Only the receiver knows what they want and do not want to see. The bad act is the deliberate deception by the sender upon the recipient to avoid accountability and/or obtain a false sense of trust in order to entice the recipient to perform actions based on that false trust. A spam message does not mean that any identities are being spoofed. > But doesn't this effectively say "DKIM (or any sender signing scheme) > doesn't work against attacks that attempt to involve impersonating > a specific source address"? What class of specific impersonation > attacks does this technology actually work against in practice? "Exact" domain spoofing. I.e. There is a desire to at least deal with cases to avoid unauthorized use of an exact domain. Look-alike attacks are a much more difficult problem since human factors are more involved. > S 5.2.3: > I don't see how you can reasonably deal with replay attacks > by revoking the key that was used to sign the message. This > enables a trivial DoS attack on any message sender--just > get some messages from that sender and generate some replays. Key revocation is also a heavy method for dealing with replay, and may be impractical for many when a single private key is used to sign messages for multiple senders. Revoking a key can invalidate many legitimate messages. Doug's opaque ID method is more suitable for revocation of a known message. It is still TBD, FMPOV, if the opaque ID is still sufficient enough to deal with replay since the window of opportunity may still be large enough that when revocation is done: the damage has already been done. > Again, I realize that the DKIM designers have chosen not to > handle replay, but that doesn't mean there's no way to handle > it with a server-based signing scheme. This seems like exactly > the kind of issue that a threat analysis should cover. Replay is a major problem for DKIM. I agree that it needs to be addressed. If not by DKIM itself, at least strategies spelled out on how it can be handled. --ewh _______________________________________________ ietf-dkim mailing list http://dkim.org
