Subject: [dmarc-ietf] Draft DMARC working group charter

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 21 Jun 2014 15:23:06 +0900

Dave Crocker writes:

 > The existing base specification is being submitted as an Independent
 > Submission to become an Informational RFC.

[...]
 >      2. Intra-Specification -- Audit each part of the DMARC
 >         specification (reporting, policy, auth), making improvements as
 >         appropriate.

This last role seems to conflict with "Independent Submission".
"Suggesting improvements" would be better?

---

From: Dave Crocker <[email-masked]>
Date: Sat, 21 Jun 2014 04:16:04 -0700

> "Suggesting improvements" would be better?

Hmmm.  Interesting challenge in writing.

What the text means to impart is that it is possible to make changes to
the base specification, for publication as a new version of the
specification.  So, the current version goes as an Independent
submissions, and a new one would go as a working group document.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 21 Jun 2014 22:45:31 +0900

> submissions, and a new one would go as a working group document.

How about making that explicit:

    2.  Intra-Specification -- Audit each part of the DMARC
        specification (reporting, policy, authentication).
        Improvements and extensions developed may be considered for
        incorporation in a future standard.

or similar language?

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 23 Jun 2014 14:05:53 +0200

> submissions, and a new one would go as a working group document.

That reminds the 4870/4871 split.  Its usefulness may not be obvious
to all, so some explanation might help.

For the problem at hand, it is not clear how the WG is going to
operate about the "choices", such as:

   - A form of DKIM signature that is better able to survive transit
     through intermediaries.

Can the WG propose solutions that modify DKIM or is that out of scope?
For example, something like the following I-D could be part of a
solution.  Would the proposed charter allow it?
http://datatracker.ietf.org/doc/draft-vesely-smooth-canon/

Ale

---

From: Dave Crocker <[email-masked]>
Date: Mon, 23 Jun 2014 08:39:44 -0700

>         incorporation in a future standard.

How about:

     2. Intra-Specification -- Audit each part of the DMARC
        specification (reporting, policy, auth), making improvements to
        an incremental version as appropriate.

Best to leave out statements of intended status and just focus on the work.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Jun 2014 12:28:51 -0700

On Sun, Jun 22, 2014 at 10:44 PM, Barry Leiba <[email-masked]>
wrote:

> Please have at it.  (And please remove me from the CC list when you
> reply to this; I subscribe to the list from another email address, and
> don't want a separate copy.)
>

I think this looks like a reasonable charter.  I'm hoping this:

> The working group will seek to preserve interoperability with the
> installed base of DMARC systems, and will provide careful justification
> for any non-interoperability. The working group will seek to maintain
> the viability of stable domain-level identifiers in mail, and will
> document existing mail streams that do not conform to the DMARC model.
>

...is a reasonable compromise with respect to the thing that derailed us
last time.

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 26 Jun 2014 03:14:02 +0900

> Best to leave out statements of intended status and just focus on the work.

OK.  Kinda picky, but how about "revised specification" instead of
"incremental version"?

---

From: Dave Crocker <[email-masked]>
Date: Wed, 25 Jun 2014 12:06:56 -0700

> OK.  Kinda picky, but how about "revised specification" instead of

Well, the language I offered was also produced from pickiness.  In
reaction to a possible misunderstanding of the earlier draft charter text.

The problem is that 'revised specification' might be taken to mean a
'replacement' for the existing version, as in not publishing the current
version but instead publishing the revision.  By contrast, incremental
is meant to imply that both current and new get published...

d/

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 26 Jun 2014 12:18:03 +0900

> reaction to a possible misunderstanding of the earlier draft

"Incremental version" is not a "term of art", then?  (That occurred to
me after hitting send.)

Surely this terminological problem (foreseeing updates to another WG's
-- or external body's -- in-progress specification, but not stepping
on their toes) has been encountered by working groups before?

(If nobody has examples off hand, I'll go research other charters for
similar language, no reply necessary.)

---

From: "John Levine" <[email-masked]>
Date: 26 Jun 2014 20:37:47 -0000

>I don't see how this can be considered out of scope without a viable
>alternative. The identification of the Administrative Domain is a
>normative requirement in DMARC, and if this problem is not solved, the
>specification will be stuck. Having tried and failed to solve this
>problem several years ago, I am convinced that this is a very difficult
>problem.

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.

In practice, until something better shows up everyone downloads and
uses Mozilla's PSL.  It's a crock, but it's what people use.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Fri, 27 Jun 2014 04:09:32 -0400

> [removed the SPAM tag from subject]

Which the mailing list put right back on.  It seems that something in
the charter text is causing that, and I've asked the Secretariat IT
support to look into it.  The worst part of this is that none of the
charter discussion is in the archive.

I have put the proposed charter in the appsawg wiki:
http://trac.tools.ietf.org/wg/appsawg/trac/wiki/DMARC

> I'm not sure if this belongs in the charter, but in any case I wonder if
> it creates market confusion to pursue both an Informational Independent
> Submission and a Standards-track working group RFC. Are there other
> examples of where that has been done? As a counter-example, note that
> the publication of DomainKeys (RFC 4870) was delayed until DKIM
> published to avoid confusion, and there the names were somewhat different.

HTTP 1.0 (RFC 1945) and OAUTH 1.0 (RFC 5849), to name two.

Barry

---

From: Douglas Otis <[email-masked]>
Date: Fri, 27 Jun 2014 10:35:39 -0700

> HTTP 1.0 (RFC 1945) and OAUTH 1.0 (RFC 5849), to name two.

Dear Barry,

This type of problem is emblematic of anti-spam and also why anti-spam has not flatten the attack surface enough to be a meaningful deterrent for the problem DMARC addresses.  DMARC constrains "trust" to validated elements from known sources as a tremendous benefit to recipients.

Placing an expiry on trusted elements that can be replayed with indeterminate content from unvalidated sources takes this into the statistical area best described as anti-spam.  In effect, this says we'll make this hard by asking spammers to jump this high beyond the bayesian mean.  After deploying such schemes, this then becomes the well practiced height and we are back to where we started.   

Regards,
Douglas Otis

---

From: Jim Fenton <[email-masked]>
Date: Fri, 27 Jun 2014 12:26:27 -0700

> 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.
> uses Mozilla's PSL.  It's a crock, but it's what people use.

But I can't see IETF publishing a standards-track specification that
uses the PSL, or anything like that. So given that the dbound effort is
behind this one, I'm concerned that this WG would face a very long
normative reference dependency wait before it could publish anything
standards-track.

-Jim

---

From: "John R Levine" <[email-masked]>
Date: 27 Jun 2014 15:59:38 -0400

> uses the PSL, or anything like that.

The current DMARC spec just waves its hands and says use something like 
the PSL without specifically pointing at the PSL.  We've done worse.

Having said that, it is not my impression that producing a standards track 
DMARC-bis is a goal of this group.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 27 Jun 2014 14:38:03 -0700

On Jun 27, 2014, at 12:59 PM, John R Levine <[email-masked]> wrote:

> The current DMARC spec just waves its hands and says use something like the PSL without specifically pointing at the PSL.  We've done worse.
> 
> Having said that, it is not my impression that producing a standards track DMARC-bis is a goal of this group.

Dear John,

It seems one solution for the PSL would be to cull out domains not directly assigned by a registrar recognized by the global Internet.  It may mean some domain holders will then be unable to control their domain. They never did.  Such a change may motivate those holders to seek a safer name basis.

Regards,
Douglas Otis

---

From: "J. Trent Adams" <[email-masked]>
Date: Fri, 27 Jun 2014 18:06:06 -0600

IMO, either term will do fine in this context.  If one or the other
results in a prolonged discussion within the WG that hinges on this that
the Chair can't resolve, we've got bigger issues.

Let's not let this issue wrap around the axle and slow things down.

My $0.02,
Trent

On 6/25/14 9:18 PM, Stephen J. Turnbull wrote:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: Hector Santos <[email-masked]>
Date: Sat, 28 Jun 2014 13:39:18 -0400

> 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

---

From: Tim Draegen <[email-masked]>
Date: Mon, 30 Jun 2014 09:29:01 -0400

On Jun 23, 2014, at 1:44 AM, Barry Leiba <[email-masked]> wrote:
> Let's please stop all the other discussions for now, and say that the
> purpose of the <[email-masked]> mailing list is, for now, to discuss
> the charter proposal and converge on a charter for a working group.
> 

IMO, the proposed Charter does a good job of recognizing the complexity of the topic, which is why it seems to be long.

Two points stick out to me.  One of emphasis and one of clarity.

1. I like the break out of different tracks.  The divide and conquer approach would give time and attention to all facets of the work (I don't see any missing tracks at a high level).

	As a bonus, maybe specific areas of work can be announced in advance so that everyone involved knows what to expect.  This would help keep list conversations relevant to the focus of the WG, and would also allow people time to solicit feedback/participation on specific topics from interested communities.

2. "The working group will seek to maintain the viability of stable domain-level identifiers in mail.." This is a powerful statement.  I take this to mean that the WG won't have to focus on the "Why" of stable domain-level identifiers in mail?  If this is the case, I'm suddenly seeing the WG as being able to focus on the technical work.

=- Tim

---

From: "John Levine" <[email-masked]>
Date: 30 Jun 2014 15:44:14 -0000

>2. "The working group will seek to maintain the viability of stable domain-level
>identifiers in mail.." This is a powerful statement.  I take this to mean that the WG
>won't have to focus on the "Why" of stable domain-level identifiers in mail?  If this
>is the case, I'm suddenly seeing the WG as being able to focus on the technical work.

I hope we can assume that people who don't see the utility of stable
identifiers will consider this project a waste of time and won't
bother us.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Mon, 30 Jun 2014 08:51:55 -0700

> identifiers will consider this project a waste of time and won't

I'm not in love with this phrasing in the current charter draft, but I
do believe it useful to state core principles, given the confusion
common in this arena of discussion.