Indeed lack of support for 3rd party signers was where I gave up any interest at all in adsp
-----Original Message----- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Wednesday, April 20, 2011 3:08 AM To: ietf-dkim@mipassoc.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