On 6/27/2014 3:26 PM, Jim Fenton wrote:
There's a proto-wg called dbound thinking about this topic. Marc
Blanchet and I are trying to write up a problem statement before the
Toronto cutoff, so we can at least try and see if there is any
agreement on what problem we're trying to solve.
That's good acknowledgment of the problem, and I agree with Dave
Crocker's comment that this problem is bigger than this WG.
My suggestions on the draft charter are below. But I have a few
summary comments of my thoughts on this matter.
We did have the wider disciplines of industry vendors and participants
involved. But I would suggest more than half them were "pushed out" in
the name of TRUST signer algorithms. Remember, very powerful and
conceptually popular author domain policies were pushed out of the
framework. It was "outlawed" and it had to be "outlawed" in order to
allow the resigner/list market to blindly exist unchanged.
IMO, mail integrity list problems was the least of our concerns
because we did have a major consensus of a secured concept and idea of
using a "trusted" additional/last signature resigner for these cases.
The possible different types were:
1 - Mail integrity not changed, no resigner
2 - Mail integrity changed, no resigner
3 - Mail integrity not changed, resigner
4 - Mail integrity changed, resigner
The only real case we did not have control over was #2 when the
integrity was changed and there was no resigning. The only way to deal
with that was to wait for a wider market of list outbound resigned mail.
We just didn't agree on how to get the "trusted resigner" part.
DKIM STD did come up with a model as a function of the Signer Domain
Identity (SDID) and the Agent/User Identity (AUID) but it
intentionally excluded the Author Domain Identity (ADID). This STD
model did not get industry wide implementation support. It was a
"batteries required" concept -- DKIM did not have a payoff without the
"Trust Batteries" that you would most likely have to buy from some
future trust service "DKIM CA" vendor. VBR was the closest thing. No
traction. DAC was started by Levine. Abandoned. Levine started
other lookup GOOD REPUTATION zones too. I have no idea where that
went. But now this PSL?
So rhetorically, where is this "repository" of centralized trust
located? Who will own it? How do you get in? What will cost a
domain? Will it be fair? Will the DMA members "buy" their way into
it? etc, and so on with all these "monopolistic" long term concerns
with this trust concept.
You did not fail with your and Eric's SSP efforts. I was among those
disappointed that it was replaced with a weaker "poison pill" ADSP
that was non-supported, non-championed by it author. So in my
opinion, the lack of getting it fixed didn't apply because we didn't
have the right "technical sales" team on it. If they are not
interested in fixing it because there were other product plans related
to trust repositories, well, of course, its going to fail.
But DMARC today, proves you did not fail. The whole concept of DKIM +
POLICY did not fail. Three expected migration goals were finally
reached:
1) More Publishers of Author Domain Mail Policies
2) More Receivers performing the DNS lookup,
3) More Receivers honoring the strict policies, not just recording
and/or reporting results.
We all expected this to be a short term migration path. Until wider
publishing took place, we would see a high waste in NXDOMAINS and also
relaxed records. But eventually, we expected domains to turn on the
"reject" handling switches and that finally happen with DMARC.
So you did not fail. It just took awhile and we are back to square one:
How to authorize and scale resigners.
Personally, I would like the DMARC WG to concentrate on:
1) Split DMARC into REPORTING and POLICY.
2) Refine DMARC to make sure flexible EXTENSIONS and possible.
3) Add 3rd party semantics starting allow any resigner option.
4) Pick and chose a flexible 3rd party authorization extension,
modified version of ATPS, TPA, etc, for a PS track item or
allow them both to be experimental.
6) Develop an in-band optimizer for the exclusive policies.
5) Draft some BCP for scaling and management.
Foremost, the IETF must endorse the 3rd party authorization effort.
Nothing will work if its not championed with the level of integrated
product development required. That was lacking before. It it
continues, I don't have the confident there will be success. We are
beyond the R&D. The Yahoo"s did the first step to doing the lookup and
honoring strong policies. Now, if it desires, it needs to figure out
how to scale the authorization of resigners. For most domains, this
isn't going to be a problem and the IETF should support a framework
that satisfies all scales, even if the larger ones are going to have a
larger management problem with it. The IETF already has small vs
large scale dilemma in other protocol areas. I personally do not
believe it will be that big of a problem once the larger domains get
rolling with it. We can handle "Big Data" problems, can we? Thats a
separate problem and it should not stop progress with the basic 3rd
party authorization model that is fundamentally needed. To argue that
its no good because it doesn't scale is not a good idea. Many ideas
didn't scale when they were introduced, but we learned how to optimize
and scale them over time.
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
