Mark Delany wrote:
On Jan 24, 2008, at 6:14 PM, Hector Santos wrote:
But to disagree with you, I voted +1 precisely for technical reasons. I
want a simple solution that non-WG-specialists can grok. I don't think
we have that today.
Well Mark, I'm surprise if you really mean that. If you are saying this
from a managerial standpoint just to get this effort rubber stamp, then
I suggest to get an engineer on top of this. If you are saying this
from an engineering standpoint, then I have to believe you have it in
your vains to see how issue 1521 is going to negatively impact the
general wide adoption of DKIM/SSP.
In short, if we accept 1521, then receivers can only implement DKIM/SSP
with a "batteries required" concept - 3rd party reputation services.
Here is a synopsis of the situation:
In 5016 requirement #9, we have:
9. SSP MUST NOT be required to be invoked if a valid first party
signature is found.
We got it to this point where everyone compromise based on the secured
idea that forging a 1st party key would need to be done with internal
theft in order to exploit it.
Now with the new text, the desire is that SSP doesn't apply even for
valid 3rd party signatures.
So the "new requirement #9" based on ISSUE 1521, we would have to change
it to:
9. SSP MUST NOT be required to be invoked if any valid
(first or third party signature) is found.
Well, we been through this exercise before and it was proven that this
can be a major exploit. We shown over and over again during the DKIM
Threat Analysis.
Today, as shown by the deployment guide, the only way to honor this is
to implement reputation services when there is a VALID signature. And
please note very strongly, the guide also says that no
accreditation/reputation scheme, not even the valid signature is good.
I see this "strategic" as a major technical design mistake.
We do have implementation issues with ESP. But there are not ones that
are not solvable and no one is suggestion that reputation services are
not valuable. But to require a non-standard procedure (batteries) as
part as RFC standard IMV is going to raise the barrier of wide adoption.
--
Sincerely
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