Subject: Re: [dmarc-ietf] dmarc - Requested session has been scheduled for IETF 100

From: Hector Santos <[email-masked]>
Date: Wed, 01 Nov 2017 13:02:39 -0400

On 10/31/2017 10:57 AM, Barry Leiba wrote:

> In a couple of days I will ask Alexey to cancel the dmarc session in
> Singapore, unless someone very quickly shouts, “Noooooooo, don’t do
> that!  We need to meet and talk about <this>.”
>
> Barry, as chair

Once again, my expectations were off about what the key DKIM cogs 
would do to complete this long time project in regards to DKIM policy 
and even trust layers.

I've been waiting for over a decade for the DKIM Policy layer to be 
established.  Spent much dollars, engineering time, product 
development, sweat and tears working on ADSP, a then proposed 
standard, only to be "replaced" with non-proposed standard "Super 
ADSP" DMARC that did not solve the complaints about ADSP, but instead 
carried the problem on, and pushed it into the market place like the 
problem never existed.

So are we going to complete this thing or what?  I have been waiting 
and willing to "follow" the leaders to finally complete this thing. 
Is ARC resolving these 3rd party issues?  It doesn't look that way, or 
at least I don't see it, other than ramming the overhead down our 
throats.

You should at least have a meeting to decide what you are going to do 
with DMARC.  It should be turned into a Proposed Standard.  It needs 
3rd party policy considerations.  It needs more policy options, 
including describing how ARC is expected to work by domain owners who 
expect to use it.

I really don't quite understand the engineering difficulty in 
completing a 3rd party solution we all know will work for "cheaper and 
better" than any ARC plan.

DMARC is very limiting.  I am proposing:

1) Rewrite DMARC as a IETF proposed standard,
2) Incorporate 3rd party authorization concepts like ATPS into DMARC 
as extension tags,
3) Incorporate ARC somehow into Policy that tells receivers what to 
expect, i.e. # of hops, etc.

I would like to think these are all just DMARC options but it needs to 
be IETF sanctioned in order to get support which will finally give 
people a confident chancee to explore these options in earnest.

-- 
Sincerely

Hector Santos
http://www.santronics.com

-- 
HLS

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 1 Nov 2017 18:05:50 +0000

On Wed, Nov 1, 2017 at 5:02 PM, Hector Santos <[email-masked]> wrote:

> You should at least have a meeting to decide what you are going to do with
> DMARC.  It should be turned into a Proposed Standard.

This is on the roadmap charter for the working group but we are not yet to
the point of working on that milestone.

--Kurt

---

From: Barry Leiba <[email-masked]>
Date: Thu, 2 Nov 2017 09:13:28 +0400

> the point of working on that milestone.

Yes, but more broadly, Hector is not wrong.

We started with ADSP, which we thought was what we needed, but we
quickly found that it had basic flaws that made it not work well.  We
rescinded it.  That's good.

So then some major email providers got together and beat out what they
thought they *actually* needed.  That's also good.  They brought what
they came up with to the IETF, but what that *is* is substantially the
same as ADSP with the addition of feedback/reporting features.  It
suffers from very similar flaws to ADSP, and we're seeing the
unfortunate results of that.

That is bad.

And so we're working on ARC, which attempts to partially address the
flaws.  Again, good, but it's taking quite some time to get it done.
We initially planned to get it done quickly and then to move on to the
next step with DMARC.  We need to get there.

We also need to understand whether there's really anything we intend
to do with DMARC.  Do we *know* what we might do?  Do we have any plan
for a way forward?  Are we hoping that ARC will fix enough of it that
we can make the combination into a standard?

As always, I know this is all volunteer work, and we do things as can
find the time to do them.  That said, we really need to push this
stuff up in priority, because we really need some mitigation to the
DMARC damage, and developers such as Hector need to know what they
should code into their products so they can get something stable in
there and move on to other features.

Barry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 3 Nov 2017 01:01:35 -0700

> we can make the combination into a standard?

I've been proceeding under the assumption that the last sentence is the
plan.  Am I the only one?  Is something else the plan?

-MSK

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 3 Nov 2017 16:47:25 +0000

> plan.  Am I the only one?  Is something else the plan?

While the exact method and details of accomplishing said "combination" are
TBD, that is the general idea.

--Kurt

---

From: Brandon Long <[email-masked]>
Date: Fri, 03 Nov 2017 19:32:12 +0000

If you look at RFC 7960, ARC is intended mostly for the mediators case,
though it would also be for the MDA/MTA case.  It does nothing for the MSA
case, though there have been some proposals about having a hop=0 or just
falsifying hop=1 for that.

Most of the MSA issues, though, are mostly of the type "well, dmarc
p=reject/quarantine means the domain holder doesn't want you doing that",
so I'm not clear there's a solution there.

Brandon

On Fri, Nov 3, 2017 at 9:47 AM Kurt Andersen (b) <[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Hector Santos <[email-masked]>
Date: Sun, 05 Nov 2017 22:29:55 -0500

On 11/3/2017 3:32 PM, Brandon Long wrote:
> If you look at RFC 7960, ARC is intended mostly for the mediators
> case, though it would also be for the MDA/MTA case.  It does nothing
> for the MSA case, though there have been some proposals about having a
> hop=0 or just falsifying hop=1 for that.
>
> p=reject/quarantine means the domain holder doesn't want you doing
> that", so I'm not clear there's a solution there.
>

If I still understand ARC and its attempt to do a chain of trust 
concept, I think there would still be a need for a 3rd Party Seal 
authorized domain or "registration" concept, otherwise, only the 
entire chain validity matters. We can have policies for strong and 
relaxed ARC seal requirements.

Overall, the integrated DKIM policy solution begins with RFC7489.DMARC 
Tag Extensions:

    3.1.3.  Alignment and Extension Technologies

    If in the future DMARC is extended to include the use of other
    authentication mechanisms, the extensions will need to allow for
    domain identifier extraction so that alignment with the RFC5322.From
    domain can be verified.

We can consider an "atps=" tag and "arc=" tag as experimental 
concepts.   One is DNS-based, no additional RFC5322 overhead, the 
other has additional RFC5322 modification and processing requirements. 
  I suggest there will be a significant percentage of smaller/private 
domains that will not have the same requirements as the larger "public 
service" ESP domains.

If a DMARC record has an "atps=1"  it uses rfc6541 to check the 3rd 
party signer DKIM.SDID domain.

If a DMARC record has an "arc=1"  it uses the ARC proposal and some 
new "policy" proposal (TBD) to check the 3rd party seals and probably 
1 or more sealer domain.

I would even consider adding to the experiment the exploration of 
Levine's Conditional DKIM Signer proposal, with a "cond=1" tag.  This 
proposal is a non-DNS lookup idea to authorize an expected 3rd party 
signer I believe added to the original signature.  The DMARC extended 
"cond=1" tag could say  "a failed p=reject message can be promoted to 
pass with valid 3rd party conditional signer."

-- 
HLS