-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of
Bill(_dot_)Oxley(_at_)cox(_dot_)com
Sent: Wednesday, April 20, 2011 7:37 AM
To: hsantos(_at_)isdg(_dot_)net; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] ADSP stats
Indeed lack of support for 3rd party signers was where I gave up any
interest at all in adsp
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hector Santos
Sent: Wednesday, April 20, 2011 3:08 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] ADSP stats
Murray S. Kucherawy wrote:
Bill Oxley:
In my mind the whole adsp degenerated into a use case only for well
recognized narrowband senders such as banks. Had nothing to do with
reputation sellers, and judging by a recent exit from the market a
reputation is only as good as it is maintained.
That's my recollection as well. I never saw any concerted
or even accidental attempt to block, prevent, quash,
overthrow or otherwise prevent policy work from being done.
Its hard to not see the gradual removal of all semantics, insights,
words related to policy and the refusal to consider the natural
identity "authorized signer" as anything but a concerted efforts to
marginalized it and reduce incentive to support it. Otherwise, what is
the reasoning for for the genocide of the "authorized signer" concept
in DKIM?
When there is a desire to have a (reasonable) unrestricted 3rd party
signer model to work, then you to need to technically eliminate author
domain rights to restrict it. ADSP represented that concerted effort.
It was not done in the blind.
Is that evil? No, but it needs to be explained.
I believe the original policy work was a victim of the fact
that it's very hard to get such things right in this
operational environment, and there was insufficient
operational evidence to support some of the original
proposals.
The same can be said for a trust only model. Where is the operational
payoff evidence? It is very hard to make it work with a high
dependency and risk for an yet to emerge wide trust market place. It
can also be said, like ADSP, trust is a very narrow because it can
only work today in isolated scenarios between sites with common trust
information. ADSP had a consistent result model for all verifiers.
Trust does not. Trust is a long term idealized model where
centralization information is required in order to have consistency in
results.
Ultimately, we simply couldn't reach consensus
on the rich solutions people wanted.
Murray, since day one, since SSP, hell, since MARID, the lack of
consensus was how to deal with anonymous unknown 3rd party trust
assertions. For DKIM, we couldn't agree of a DNS solution because it
had to COVER all scenarios, even for the largest.
But the conflict came with ADSP excluding the basic idea for the
allowance of a 3rd party signer. So even if we didn't have a feasible
solution to to explicitly authorized 3rd party signers, we lost the
ability to make DKIM operationally consistent with 3rd parties with a
basic author domain policy declaration:
"MY MAIL IS ALWAYS SIGN BY ANYONE"
I don't think it is fair to use lack of consensus because ADSP threw
out the WG consensus built RFC4686 security concerns and we didn't
have an opportunity to properly vote to void the WG Consensus Built
security concerns. Instead, it was flipped. We were force to prove
again why 3rd party policies are necessary. It was a guarantee
scenario for failure. Yet when the ADSP broken part solutions was
proposed (can DKIM=ALL be used to allow the above policy), the
document author had no interest to solve it nor remove it from its
status broken mode, no consensus quo.
I also can't see the current language as endorsing any
particular layer on top of DKIM. Indeed, we've published an
RFC that presents a (limited) policy solution, but have
deliberately avoided doing any work on reputation at all.
That seems to counter to what's being alleged here.
Section 2.5 and section 2.7 specifically describes a layered model for
an independent trust assessment service module using an mandatory SDID
authenticated output. Isn't that whats written and desired?
A fresh reader of DKIM-BASE would conclude there is only one layer
model and not conclude there is an well considered security based
policy assessment model possible.
Finally, please consider that whoever selects a SDID to sign a
message, whether its a 1s party author domain, 3rd party delegated or
not, or MLM list operator, there are all still an authorized signer
selection concept. A verifier using an SDID for trust assessment
comes with an inherent operational presumption for an authorized
signer selection and certainly not believed to be an unauthorized
signer selection. From a functional standpoint, by making it harder
in ADSP to have the simple declaration "always signed by anyone" we
make it harder for the 3rd parties to fit well, even trusted ones. And
in my view, from an IETF protocol standpoint by intentionally removing
all ideas for a natural protocol identity concept in DKIM to exist,
well, that doesn't seem IETF Kolser and doesn't play well with the
IETF idea to lead the way for flexibility and not get locked into a
controversial "batteries required" method.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html