On Saturday 09 September 2006 12:45, Wietse Venema wrote:
Scott Kitterman:
On Saturday 09 September 2006 12:07, Dave Crocker wrote:
Wietse Venema wrote:
Here is an example why first-party signatures can be dangerous.
...
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.
This is exactly the trap that I was describing in the mail cited above.
I believe that I understand your point and I don't think it is.
Blindly believing DKIM-SSP gives a false sense of security, and
provides criminals with even more convincing ways to rob people.
I really recommend that you read my entire email message.
If you had said that Blindly believing [positive indications from]
DKIM-SSP ... then I would agree 100%. I do not think that SSP can help
assert anything about the goodness of a message. I think it's only utility
is in finding some that are definitely bad.
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?
See my point above. We're already raising expectations too high,
by claiming that DKIM-SSP will block phishing mail. It will only
make phishing mail look more authentic.
I fear we are talking past each other some how.
I agree that if anyone takes an SSP 'Pass' as meaningful, that is exactly what
would happen. I agree that users and systems should not do that.
To narrow the scope to where I think there is some potential utility, I think
SSP could be helpful for the case of what I would call 'exact domain
phishing'. The utility is that exact domain phishes could be rejected and so
the potential phishee never sees the message. While many users might mistake
mail from look-alike domains, getting the exact domain phishes out of the
message stream is, I think, useful.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html