Mark Delany wrote:
Only once tools and UAs take advantage of DKIM, do these attacks
become relevant. That's why I think this is a DKIM problem. We are
wanting tools and UAs to take advantage of DKIM but by doing so they
are possibly making themselves more vulnerable to attackers.
+1
And this is why
1) we MUST establish the DKIM boundary conditions for 100% success and
100% failure. You have to move all parties into the same playing
field and those that are not compliant are pushed out.
2) the conflict in the deployment to allow for unrestrictive resigners
with no willingness to establish 3rd party policies simply makes
everything even more indeterminate. How can we tell when the
"valuable" signer identity is good, bad and/or exploiting the
originating domain?
Unless we get an solid anchor for 100% Zero False Positive boundary
conditions, it makes all this very hard in what is already very complex.
DKIM has the high potential to become the next relaxed "Return Path"
dilemma the industry knew since the 80s was insecure, but not yet
highly exploited where we didn't do much about it.
Every good idea has a solid well defined problem it solves. DKIM was
one suppose to be the alternative to SPF because it has the "PATH"
problem.
By deemphasizing policy and opening the door for unrestricted
resigners, its now become a last signer authentication protocol.
Anyway, to get back to the problem, we need to do less subjective
analysis and just try to get the deterministic bits of DKIM well
defined - valid input and it needs to check it probably is only thing
left.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html