From: "Wietse Venema" > Apologies. Let me phrase this better. > > None of these loopholes would exist if signatures could vouch only > for rfc822.from domains that match the signature's d= domain (*). > Third party signatures are part of the problem. Making them "work > right" requires additional complexity. Complexity leads to error, > vulnerability and exploitation.
Wietse, you won't find me arguing this point! :-) That's been my position for the past 18+ months (*). Now we just need convince everyone else who is bent on allowing open ended 3rd party signatures (2822.From != signing domain). If we allow them, then we just can't ignore the exploitation. We need would some "kind" of control. The basic idea is that DKIM should first concentrate on protecting the author domain owner of the message. Nothing should alter this protection. Acknowledging the extra integration design issues (but not necessarily overly complex and impossible) to get it "right," I had proposed at the beginning of this new round of SSP discussions a consideration to punt on 3rd party signatures and concentrate on the more important 1st party signature concepts where the biggest benefits are achieved. Then, if possible, work in 3rd party signatures in the future. How to proceed with SSP http://mipassoc.org/pipermail/ietf-dkim/2006q3/004464.html In my opinion, this will serve the techical selling and marketing of this very promising DKIM technology. We can not shoot of the gate with thorns on our side. Ignoring the concerns now is not going to make it go away. PS: Concentrating on 1st party signatures protection will massively improve DKIM-BASE itself. And this should not exclude the teriary "Black Box" DKIM Appliance business market that is expected to emerge. They just have to assume more 1st party signing behavior. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html