ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] ADSP stats

2011-04-20 02:10:15
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

<Prev in Thread] Current Thread [Next in Thread>