Re: [dmarc-ietf] Time for a change

[Murray S. Kucherawy]

On Mon, Aug 17, 2020 at 6:09 PM Dave Crocker  wrote:

>  DKIM was a synthesis within the IETF of two things (DomainKeys and IIM)
> that started outside.  It underwent significant evolution in the IETF --
> not once, but twice.
>
> Actually, it wasn't.
>
> The constituent parts were separately proposed, during the same initial
> IETF discussions, and the IETF said to go away and come back after
> reconciliation.  That work was done by an ad hoc industry team and there
> was a complete spec and initial implementations before the IETF was again
> approached.
>
Yep, I still have the t-shirt.

> https://tools.ietf.org/html/draft-allman-dkim-base-00
>
> (and note that in the working group field on the title page, it says
> "pre-MASS"...)
>
> The work in the IETF was a refinement of a complete, integrated spec.
>
But it was quite a bit of refinement -- I would even say 'evolution" -- in
comparison to how little SPF and DMARC changed before publication.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Time for a change

[Dotzero]

On Mon, Aug 17, 2020 at 9:09 PM Dave Crocker  wrote:

>
>  DKIM was a synthesis within the IETF of two things (DomainKeys and IIM)
> that started outside.  It underwent significant evolution in the IETF --
> not once, but twice.
>
> Actually, it wasn't.
>
> The constituent parts were separately proposed, during the same initial
> IETF discussions, and the IETF said to go away and come back after
> reconciliation.  That work was done by an ad hoc industry team and there
> was a complete spec and initial implementations before the IETF was again
> approached.
>
> https://tools.ietf.org/html/draft-allman-dkim-base-00
>
> (and note that in the working group field on the title page, it says
> "pre-MASS"...)
>
> The work in the IETF was a refinement of a complete, integrated spec.
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorkingbbiw.net
>
> +1
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Time for a change

[Dave Crocker]

 DKIM was a synthesis within the IETF of two things (DomainKeys and 
IIM) that started outside.  It underwent significant evolution in the 
IETF -- not once, but twice.


Actually, it wasn't.

The constituent parts were separately proposed, during the same initial 
IETF discussions, and the IETF said to go away and come back after 
reconciliation.  That work was done by an ad hoc industry team and there 
was a complete spec and initial implementations before the IETF was 
again approached.


https://tools.ietf.org/html/draft-allman-dkim-base-00

(and note that in the working group field on the title page, it says 
"pre-MASS"...)


The work in the IETF was a refinement of a complete, integrated spec.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Time for a change

[Murray S. Kucherawy]

On Mon, Aug 17, 2020 at 6:52 AM Dotzero  wrote:

> On Sun, Aug 16, 2020 at 3:09 PM Douglas E. Foster  40bayviewphysicians@dmarc.ietf.org> wrote:
>
>> 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.
>>
>
> Doug, as someone who has been involved in this space for decades, I think
> you are sorely mistaken in your understanding of things. Many of the people
> involved in the email authentication space interact with each other in
> other places, both online and in person and have been doing so for a very
> long time.
> We don't always agree on the path forward but that is because we come from
> different perspectives. IETF did not provide "after-the-fact" blessing. SPF
> was experimental for a very long time. DMARC is still informational. One of
> the mantras for IETF is "running code and rough consensus". There is
> running code for DMARC but what we are lacking so far is rough consensus.
>

+1.  I would add that SPF and DMARC started outside of the IETF, but DKIM
was a synthesis within the IETF of two things (DomainKeys and IIM) that
started outside.  It underwent significant evolution in the IETF -- not
once, but twice.

This line of thinking also seems to ignore the troubled path that SPF took
to reach the standards track (as RFC 7208).

Or you could apply for M3AAWG membership where all of those constituencies
> participate already.
>

I was just going to say that.  And, at least the last time I went, most of
the same debates happened over there too.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Time for a change

[Dotzero]

On Sun, Aug 16, 2020 at 3:09 PM Douglas E. Foster  wrote:

>
> 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.
>

Doug, as someone who has been involved in this space for decades, I think
you are sorely mistaken in your understanding of things. Many of the people
involved in the email authentication space interact with each other in
other places, both online and in person and have been doing so for a very
long time.
We don't always agree on the path forward but that is because we come from
different perspectives. IETF did not provide "after-the-fact" blessing. SPF
was experimental for a very long time. DMARC is still informational. One of
the mantras for IETF is "running code and rough consensus". There is
running code for DMARC but what we are lacking so far is rough consensus.

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.
>

You can move anywhere you want and write any specification you want but you
still have to attract meaningful interest and adoption in order for it to
become a standard.



>
> 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,
>
> What? Which national government are you referring to? Do you understand
that the IETF is international in it's participation? If you are referring
to the U.S. Government, can you show me a single example of the government
vetoing a technical standard?

>
>- A financial services industry representative
>- An Email Service Provider industry representative
>- A large organization that is holding back on DMARC p=reject because
>DKIM delegation is an obstacle.
>- One or more commercial product representatives
>- I would love to have Verizon Media participate, but I have asked and
>had no response.
>
> and why would you expect them to respond to you?


> 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
>

Or you could apply for M3AAWG membership where all of those constituencies
participate already.

I wish you luck in your endeavors but I think you are doomed to failure.

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Time for a change

[Douglas E. Foster]

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=40isdg@dmarc.ietf.org
Sent: 8/16/20 1:19 PM
To: dmarc@ietf.org
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  > 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 h