On Sat, 2006-09-09 at 12:35 -0400, Scott Kitterman wrote: > On Saturday 09 September 2006 12:07, Dave Crocker wrote: > > Wietse Venema wrote: > > > Here is an example why first-party signatures can be dangerous. > > > > Right. > > > > They key point, to me, is that a signature by the rfc2822.From > > domain is likely to help control against some existing types of > > phishing, but it clearly will not help against others. > > I don't think anyone would disagree with this. > > > Worse, we have no empirical data about what is or is not effective, > > in helping end-users to detect phishing. So, to the extent that > > end-users figure into anyone's expectations about DKIM's benefits > > against phishing, we are flying quite blind.
This is _not_ an accurate statement. While treating DKIM base in isolation may expedite its completion, ignoring how policy relates to the employment of this mechanism minimizes vital protections needed in the face of a growing threat. Effective strategies have been demonstrated. > The best way to help end-users avoid getting phished it to not accept > phishing messages for delivery. DKIM-SSP where strict policy > statements are published offer a mechanism for this. From my > perspective, the utility of DKIM as it relates to end-users is, I > agree, quite uncertain. A blocking strategy is reactive, and not proactive. Blocking is unlikely to keep pace and be effective against a highly dynamic phishing problem. Blocking should not be considered a primary method of protection. > > Therefore, to the extent that anyone touts a DKIM-based mechanism as > > defeating phishing, we run the risk of undermining all of DKIM's > > credibility, by setting expectations far too high. > > Agreed. Is anyone doing this? DKIM used in isolation will be ineffective at defeating phishing. Anyone who thinks DKIM + Policy defeats phishing is also confused. For DKIM to be effective against phishing, DKIM MUST be used in conjunction with a list of recognized email-addresses. These email-addresses could be in the form of a trusted domain-list with some out-of-band offering of local-part components, or some method of publishing this local-part information. These email-addresses can also be gleaned from the recipient's address-book as well. It is common place to use the address-book to enable message related components or features. DKIM provides a means for making "safe" associations with retained email-addresses and those seen within a message. - The signing domain MUST be associated with the email-address. - The signing domain MUST indicate that the email-address is valid. When a retained email-address association has been discovered between an assured email-address, the message can receive annotations making this association apparent to the recipient. These annotations do not require the recipient to visually recognize the email-address. Safe placement into the address-book can be established by using pass-phrases and an out-of-band method of communication, such as a web page. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
