Re: [dmarc-ietf] Time for a change

["Douglas E. Foster" <[e-mail]>]

The reality is that IETF has mostly provided followership, not leadership, on matters of security.  This forum is replicating history.   As has been mentioned in the historical review, SPF, DKIM, and DMARC were independently successful projects, as was SSL.  IETF provided after-the-fact blessing.   It is time to follow the same model.

If there is an opportunity to accelerate DMARC adoption, I think it is in the area of third-party authentication, presumably based on ATSP.   To move the possibility forward, we need to move off this list.  The target audience for this capability will be organizations that are non-DMARC or DMARC p=none specifically because DKIM delegation is an obstacle.    I have no idea whether that category is a trivial or non-trivial group, so we would need to find out.  Major ESPs are successfully implementing DKIM scope delegation to comply with DMARC, so maybe it is not the issue.   DKIM delegation creates complexity which becomes an obstacle to new entrants, so big ESPs may like the status quo just fine.   These are all things need to be assessed, and are more important than writing a new specification.

Then, we need to expand the base of participants to include people who would be willing to implement the third-party authentication scheme after it is defined.   I think that list would need to look something like this:

A national government representative to ensure that any new proposal is not vetoed, A financial services industry representativeAn Email Service Provider industry representativeA large organization that is holding back on DMARC p=reject because DKIM delegation is an obstacle.One or more commercial product representativesI would love to have Verizon Media participate, but I have asked and had no response.
If you want to participate, send me a direct email.    More importantly, if you have connections with people who could play the role of influencers, reach out to them.

If there are other topics that would move DMARC forward, we can put them up for consideration.  If you want to discuss special treatment for mailing lists, you are specifically disinvited.

Doug Foster

----------------------------------------
From: hsantos=[e-mail]
Sent: 8/16/20 1:19 PM
To: [e-mail]
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
On 8/13/2020 8:21 PM, Murray S. Kucherawy wrote:
> On Mon, Aug 10, 2020 at 10:27 AM Dave Crocker <[e-mail]
> <mailto:[e-mail]>> wrote:
>
> > We have had a lot of attempts at third-party authorization schemes
> .....
> > With this in mind, I cannot see any point in designing yet another
> > vouching or authorization scheme unless we have evidence that an
> > interesting fraction of the world's mail systems want to use it. I
> > don't see that, and honestly see no chance that we ever will.
>
> +1
>
>
> I'm disappointed that the experiment never really got its day in
> court,

+1 and I want to give you credit for trying. Without you, I might
have been long gone from the DKIM project WGs. So I thank you for
keeping it interesting, but....

> but the consensus is clear. +1.

Here I have to disagree. I don't ask anyone to agree with me but to
understand my viewpoint as a long time participant and advocate of the
DKIM Policy Model. Early on, we had limited policy proponents. But
not today.

I have a different viewpoint, a viewpoint that really that was blocked
by the two controlling cogs who had DKIM interest else where, namely
Levine, Crocker. Crocker has been more open ended. Not Levine. Since
day 0, Levine never liked policy and to his credit, he admitted it as
much. He killed SSP with the "poison pill" (crippled draft) ADSP
replacement he knew would never make it pass LC. Levine was always
for the 3rd party trust/list signer idea - never a 1st party
authorization. But he narrowed down the scope to the restrictive
policy, removing any 3rd party consideration. The same will most
likely be true with DMARC with the same problems. Yet, why would any
list developer deny new security options for list operations? I never
got that and that was before ADSP or even ATPS. When it comes to
DKIM, if Levine didn't like it, it simply wasn't happening. Sad to say
and I don't see that changing. So now that we have the top three cogs
DKIM agreeing, there is not much reason to even bother anymore when
one of them is the AD. What is one to think at this point? "Follow
the Chieftain" syndrome?

Just consider, we are 15+ yrs into all this and nothing was
accomplished with DKIM in regards to LIST systems. DMARC, with the
same exact problems as ADSP, snuck on via an informational status.
Nothing wrong there, but it was pushed as a standard and ventures were
started. Who wins? who loses?

I believe it would be prudent for the AD to look at the reasons why
the IETF has failed with this DKIM Project. If a cog is not for ADSP
but for DMARC with the same problems, then what is that to say about
this process? It has not been a fair process to say the least. A lot
of wasted time, money and energy. It has been a long 15+ yrs and has
become very tiring. :-(

Despite the 3rd party authorization brush back, the concept has never
gone away. It says a lot and it will never go away under the current
DKIM POLICY model using the required hash bound Author Domain anchor
as the forcing function for authorization.

At this point, I would suggest to give the new generation IETF mail
developers a new chance at DKIM-based security. Rewrite DKIM as v3.0
as you guys want it for 3rd party trust. Remove the Author Domain
dependency so that the world can nip the Mail tampering bug opened
with Levine's Rewrite crud.

I wouldn't worry about backward compatibility. Two different streams,
only the newer one will matter.

--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

_______________________________________________
dmarc mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dmarc