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
