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