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

From: Dave Crocker <[email-masked]>
Date: Tue, 01 Jul 2014 09:00:43 -0700

On 6/20/2014 12:38 PM, Dave Crocker wrote:
> Here is some draft text to consider for a DMARC working group charter:

G'day,

I've looked over the small amount of mail posted about the draft charter
and do not see any changes mandated.

Apologies if I've missed something, and I assure you it wasn't
intentional.  So please do re-state the suggestion.

Otherwise, I think the major question now is whether there is general
consensus on submitting this draft charter text to the IESG?

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Tim Draegen <[email-masked]>
Date: Tue, 1 Jul 2014 12:53:02 -0400

> consensus on submitting this draft charter text to the IESG?

Dave, I'm not sure if you're asking, but I think the WG Charter is good enough.  Consensus++

---

From: Douglas Otis <[email-masked]>
Date: Tue, 1 Jul 2014 10:45:10 -0700

> consensus on submitting this draft charter text to the IESG?

Dear Dave,

I do not think the charter is adequate.  It needs to address the topic related to authorizing third-party use.  Otherwise, it is not possible to address the resulting disruption when reject is ever desired in conjunction with a mixed use domain.   At this point, it seems wrong to expect this problem will somehow evaporate.

Several have suggested things like DKIM-Delegate, CDKIM, and the like.  Frankly, your DKIM-Delegate distributes less data than would using the TPA-Label.  However,  TPA-Label requires much smaller DNS resources assuming public key retraction is to remain an important control aspect.  IMHO, reliance on expiry represents a poor option.

Improvements in DMARC features (identifier alignment, reporting, policy
preferences) will be considered, such as:

   - Enumeration of data elements required in "Failure" reports
        (specifically to address privacy issues)
   - Handling potential reporting abuse
   - Aggregate reporting to support additional reporting scenarios
   - Alternate reporting channels
   - Utility of arbitrary identifier alignment
   - Utility of a formalized policy exception mechanism

  +- Domain Federation or Authorization scheme.  See DKIM-Delegate or TPA-Label drafts as examples.
     Our company is willing to work with any large ISP to demonstrate use of TPA-Label.

http://tools.ietf.org/html/draft-otis-tpa-label

Such a conclusion is easily supported since only the DMARC domain receives feedback necessary to acknowledge and mitigate abuse of the From header field.  As such, ONLY the DMARC domain is able to indicate which other domains are permitted (authorized or federated).
Phishing and spoofing is an extremely serious problem NOT addressed using anti-SPAM techniques. If there is some time available in any upcoming meeting, I would like to take a few minutes to review this matter and relate our company's experience.

Regards,
Douglas Otis

---

From: Mike Jones <[email-masked]>
Date: Tue, 1 Jul 2014 11:19:37 -0700

I believe the WG charter is adequate as written.  The activities described
in section one of the working group activities addresses third-party email
and DMARC.  That section says that the working group will document the
effects of DMARC on such mail flows and "consider mechanisms for reducing
or eliminating DMARC's effects on indirect mail flows".

I am in favor the of the WG charter as written.

Thanks,
Mike

On Tue, Jul 1, 2014 at 10:45 AM, Douglas Otis <[email-masked]> wrote:

> I do not think the charter is adequate.  It needs to address the topic
> related to authorizing third-party use.  Otherwise, it is not possible to
> address the resulting disruption when reject is ever desired in conjunction
> with a mixed use domain.   At this point, it seems wrong to expect this
> problem will somehow evaporate.
>
> Several have suggested things like DKIM-Delegate, CDKIM, and the like.
>  Frankly, your DKIM-Delegate distributes less data than would using the
> TPA-Label.  However,  TPA-Label requires much smaller DNS resources
> assuming public key retraction is to remain an important control aspect.
>  IMHO, reliance on expiry represents a poor option.
>
> Such a conclusion is easily supported since only the DMARC domain receives
> feedback necessary to acknowledge and mitigate abuse of the From header
> field.  As such, ONLY the DMARC domain is able to indicate which other
> domains are permitted (authorized or federated).
> Phishing and spoofing is an extremely serious problem NOT addressed using
> anti-SPAM techniques. If there is some time available in any upcoming
> meeting, I would like to take a few minutes to review this matter and
> relate our company's experience.
>
> Regards,
> Douglas Otis
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 1 Jul 2014 11:34:37 -0700

> problem will somehow evaporate.

One of the bullet items in the charter is "Utility of a formalized policy
exception mechanism".  I consider that to cover the thing you're talking
about, meaning there's no need to call it out separately and explicitly.

-MSK

---

From: Terry Zink <[email-masked]>
Date: Tue, 1 Jul 2014 18:38:41 +0000

I am in favor of it, as written, as well.

-- Terry

From: dmarc [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Tuesday, July 1, 2014 11:20 AM
To: Douglas Otis; Dave Crocker
Cc: Pete Resnick; [email-masked]; Barry Leiba
Subject: Re: [dmarc-ietf] Draft DMARC working group charter

I believe the WG charter is adequate as written.  The activities described in section one of the working group activities addresses third-party email and DMARC.  That section says that the working group will document the effects of DMARC on such mail flows and "consider mechanisms for reducing or eliminating DMARC's effects on indirect mail flows".

Thanks,
Mike

On Tue, Jul 1, 2014 at 10:45 AM, Douglas Otis <[email-masked]<mailto:[email-masked]>> wrote:

On Jul 1, 2014, at 9:00 AM, Dave Crocker <[email-masked]<mailto:[email-masked]>> wrote:

G'day,

Dear Dave,

Regards,
Douglas Otis

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

---

From: Brandon Long <[email-masked]>
Date: Tue, 1 Jul 2014 12:53:24 -0700

In favor as written.

Brandon

On Tue, Jul 1, 2014 at 11:38 AM, Terry Zink <[email-masked]>
wrote:

> *From:* dmarc [mailto:[email-masked]] *On Behalf Of *Mike Jones
> *Sent:* Tuesday, July 1, 2014 11:20 AM
> *To:* Douglas Otis; Dave Crocker
> *Cc:* Pete Resnick; [email-masked]; Barry Leiba
> *Subject:* Re: [dmarc-ietf] Draft DMARC working group charter
>
>
>

---

From: Steven M Jones <[email-masked]>
Date: Tue, 01 Jul 2014 17:14:18 -0700

As a couple people have observed it's a complicated charter, but then
it's a complicated situation... I think this does the trick. +1.

That said, one small point to consider:

> The task of defining a
> standard mechanism for identifying organizational domain is out of scope
> for this working group. However the working group can consider extending
> the base DMARC specification to accommodate such a standard, should it
> be developed during the life of this working group.

By limiting this consideration to "during the life of this working
group," do we preclude the possibility of defining (in whole or in part)
how such work completed outside and after this WG could be plugged in?
Why not have the flexibility in the charter, if it doesn't make it a
required deliverable?

--S.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 02 Jul 2014 11:30:48 +0900

> consensus on submitting this draft charter text to the IESG?

consensus += (1 if tpa_labels_and_similar__may_be_discussed else 0)

I have no opinion on the value of tpa-labels as a device to extend
DMARC alignment to certain 3rd party (re)senders, but I did read the
draft charter as including discussion of that, among other remedies,
and would be upset if the charter was interpreted otherwise.

In particular, none of the in-band proposals can address the issues of
3rd party senders in non-forwarding scenarios.  I don't know if they
need mitigation as much as mailing lists do, but I don't know that
they don't.

python-3-cally y'rs

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 02 Jul 2014 11:58:45 +0900

Steven M Jones writes:

 > > The task of defining a standard mechanism for identifying
 > > organizational domain is out of scope for this working
 > > group. However the working group can consider extending the base
 > > DMARC specification to accommodate such a standard, should it be
 > > developed during the life of this working group.
 > 
 > group," do we preclude the possibility of defining (in whole or in
 > part) how such work completed outside and after this WG could be
 > plugged in?

I think "precluding" is advisable.  Identifying organizational domains
is a very big issue affecting security of essentially all applications
on the Internet, and trying to specify an interface in advance seems
useless -- either it will be obvious how to do so, or central elements
of DMARC/DKIM/SPF will need to be revised/replaced anyway.

By "obvious", I mean the following.  For DMARC, we know that we're
aiming at identity alignment of the mailbox in the From field with
either the SMTP connection's remote host (SPF) or a specified domain
in the DKIM-Signature field (DKIM).  AFAIK in those cases the DNS
record to retrieve keys to *authenticate* the sender's identity is
well-defined and not affected by the issue of "organizational domain".

DMARC policy (ie, author-domain-based *authorization* of senders) is
specified by a DNS record.  The core of DMARC is the algorithm to find
the appropriate DNS record.  If a later definition of "organizational
domain" invalidates that algorithm, DMARC (v1) is dead, and needs to
be resurrected with a new algorithm (v2) to find that record
compatibly with "organizational domain".  I don't see how we can
really "define" a plug-in beyond "new algorithm", while that algorithm
is a well-defined component of DMARC (ie, could be considered to be
the "socket").

If changes beyond that are needed, I guess the Grinch stole Christmas.

Steve

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 02 Jul 2014 10:45:56 +0200

> intentional.  So please do re-state the suggestion.

My question about the stance toward DKIM tweaks[1] was never answered.
 To re-state, while preclusion is apparent for the organizational
domain issue, it is not clear for DKIM.  The charter says:

   The working group will not develop additional mail authentication
   technologies, but may document authentication requirements that
   are desirable.

Something similar to the example I-D in [1] was expressed in recent
discussions, so I hope for additional developments of existing mail
authentication technologies not being precluded.  Please clarify.

Clarity and comprehensibility are very important from my POV[2].  For
that sake, I suggest the charter mention candidate solutions such as
DKIM-Delegate and TPA-Labels explicitly.  Some further wordsmithing
may be advisable too.

Thank you
Ale

[1] http://www.ietf.org/mail-archive/web/dmarc/current/msg01419.html

[2] I'm a (very) small mailbox provider, and I think the IETF ought to
provide some suitable-for-all specifications for running effective
MTAs, the 'S' in SMTP.  Otherwise we might as well limit ourselves to
using Google or Apple and be happy.  That's why I try and participate
in some WGs.

---

From: Steven M Jones <[email-masked]>
Date: Wed, 02 Jul 2014 09:10:30 -0700

On 07/01/2014 07:58 PM, Stephen J. Turnbull wrote:
>  [ ...]
> I think "precluding" is advisable. [...]
>
> I don't see how we can

I don't have such a definition in-hand, I just observed the potential
synchronization issue / exclusion with respect to another working group
and thought, "Do we have to create that dependency on
completing/publishing?" - thinking back to Jim Fenton's comments. Maybe
a year into this work such a definition would be clear, who knows?

I'm not worried we'll run out of work so quickly that no other WG will
have a chance to make progress. :)

And from being around a previous WG I can appreciate the need to define
a scope carefully to avoid potential time sinks. I didn't see that being
the case with this particular small clause, but perhaps others have that
concern.

Again, not something I'd hold up adopting the charter over, just thought
it would bear some public comment.

Appreciate your feedback,
--S.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 02 Jul 2014 09:22:40 -0700

> Why not have the flexibility in the charter, if it doesn't make it a

1. I'd like to do that.  Good and important issue.

2. However, defining interfaces in the absence of knowledge about the
details of what is being interfaced to pretty much never works.

3. It occurs to me that the charter /should/ make some comment about
this wg's helping that other effort, beyond just 'using' its output.  As
a real and immediate consumer of that work, we can provide some guidance
about what is needed.  We aren't the sole 'experts' on the topic, but
again, our need is real and immediate and concrete.

So perhaps the most useful thing we can do is try to get the wg to
formulate 'needs' -- I think the word 'requirements' is overblown,
overused, distracting, and often inappropriately-constraining -- to
communicate to that other effort?

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 2 Jul 2014 09:51:11 -0700

>    technologies, but may document authentication requirements that

It also says:

The working group will consider mechanisms for reducing or eliminating
the DMARC's effects on indirect mail flows.  Among the choices are:

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

   - Collaborative or passive transitive mechanisms that enable an
     intermediary to participate in the trust sequence, propagating
     authentication directly or reporting its results.

   - Message modification by an intermediary, to avoid authentication
     failures, such as by using specified conventions for changing the
     aligned identity.

Consideration also will be given to survivable authentication through
sequences of multiple intermediaries.

So I think you're covered.

> DKIM-Delegate and TPA-Labels explicitly.  Some further wordsmithing

It probably wouldn't be harmful to list them as possible inputs to the
work, so that people reviewing the charter have some context, so long as
doing so doesn't also constrain the WG's options.

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Wed, 2 Jul 2014 09:59:23 -0700

On Jul 2, 2014, at 9:51 AM, Murray S. Kucherawy <[email-masked]> wrote:

> It probably wouldn't be harmful to list them as possible inputs to the work, so that people reviewing the charter have some context, so long as doing so doesn't also constrain the WG's options. 

Agreed, as it seems such efforts have been excluded by the charter language.  It would be a shame, since there needs to be a remedy permitting back-office services such as those offered by Intuit and the like.  It seems such efforts are easily within the realm of being practical without effecting DKIM.

Regards,
Douglas Otis

---

From: Dave Crocker <[email-masked]>
Date: Wed, 02 Jul 2014 09:59:27 -0700

> doing so doesn't also constrain the WG's options.

The charter won't be directing the wg to 'start with' or 'work from' or
'build upon' or any equivalent constraint, for these drafts, I think the
simplest approach is just to add these citations to the References
section.  (Actually meant to do that originally.)

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 2 Jul 2014 10:08:08 -0700

On Wed, Jul 2, 2014 at 9:59 AM, Douglas Otis <[email-masked]> wrote:

> Agreed, as it seems such efforts have been excluded by the charter
> language.  It would be a shame, since there needs to be a remedy permitting
> back-office services such as those offered by Intuit and the like.  It
> seems such efforts are easily within the realm of being practical without
> effecting DKIM.
>

To repeat: I disagree that they've been excluded.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Wed, 2 Jul 2014 14:01:46 -0400

> section.  (Actually meant to do that originally.)

That seems like the right approach.

Barry

---

From: Hector Santos <[email-masked]>
Date: Wed, 2 Jul 2014 14:34:23 -0400

So what are  we looking for? A new R&D effort? What about all the threat analysis and functional requirement design done (RFCs)?  Does this suggest new or renewed signing authorization proposals are welcome? 
 
--
Hector Santos
http://www.santronics.com

---

From: Pete Resnick <[email-masked]>
Date: Wed, 2 Jul 2014 23:46:34 -0500

> and do not see any changes mandated.

Nothing mandated, but here are some changes that I think clarify and/or 
simplify. You can find a diff here:

<https://www.ietf.org/rfcdiff?url1=http%3A%2F%2Fresnick1.qualcomm.com%2Fdmarc-charter-00.txt&difftype=--html&submit=Go%21&url2=http%3A%2F%2Fresnick1.qualcomm.com%2Fdmarc-charter-00a.txt>

Details below (including a question). Let me know if you've got any 
concerns.

I think we can get this to the IESG for review before Toronto.

> Domain-based Message Authentication, Reporting&  Conformance (DMARC)
> extends stable, domain-level validation to the RFC5322.From field. DMARC
> builds upon existing mail authentication technologies (SPF and DKIM),
> using DNS records to add policy-related requests for receivers and
> defining a feedback mechanism from receivers back to domain owners. This
> can allow a domain owner to advertise that mail, which does not
> authenticate use of the domain name in the From field, can safely
> receive differential handling, such as rejection. Existing deployment of
> DMARC has demonstrated utility at internet scale, in dealing with
> significant email abuse, and has permitted simplifying some mail
> handling processes.

Simplifying:

"Domain-based Message Authentication, Reporting & Conformance (DMARC) 
uses existing mail authentication technologies (SPF and DKIM) to extend 
validation to the RFC5322.From field. DMARC uses DNS records to add 
policy-related requests for receivers and defines a feedback mechanism 
from receivers back to domain owners. This allows a domain owner to 
advertise that mail can safely receive differential handling, such as 
rejection, when the use of the domain name in the From field is not 
authenticated. Existing deployment of DMARC has demonstrated utility at 
internet scale, in dealing with significant email abuse, and has 
permitted simplifying some mail handling processes."

Then move this bit up:
> The existing base specification is being submitted as an Independent
> Submission to become an Informational RFC.

and put a paragraph break.

> The working group will seek to preserve interoperability with the
> installed base of DMARC systems, and will provide careful justification
> for any non-interoperability.

I think we can strike the word "careful". It doesn't add anything.

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

I'm not sure what this means. Can someone explain?

> Working group activities will pursue three tracks:
>
>       1. Inter-Specification -- Organize and document "DMARC
>          interoperability issues", developing suggestions for
>          improvements
>    

"     1.  Addressing the issues with indirect mail flows"

It wasn't clear precisely what was being talked about.

> The working group will document the effects of DMARC on indirect mail
> flows, including deployed behaviors of many different intermediaries,
> such as mailing list managers, automated mailbox forwarding services,
> and MTAs that perform enhanced message handling that results in message
> modification.
>

We can make this smaller:

"The working group will specify mechanisms for reducing or eliminating 
the DMARC's effects on indirect mail flows, including deployed behaviors 
of many different intermediaries, such as mailing list managers, 
automated mailbox forwarding services, and MTAs that perform enhanced 
message handling that results in message modification. Among the choices 
for addressing these issues are:"

The specific work items appear below, so I think we can keep it simple here.

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

"     2. Reviewing and improving the base DMARC specification"

> The base specification relies on the ability of an email receiver to
> determine the organizational domain responsible for sending mail. An
> organizational domain is the basic domain name obtained through a public
> registry, such as example.com or example.co.uk. While the common
> practice is to use a "public suffix" list to determine organizational
> domain, it is widely recognized that this solution will not scale, and
> that the current list often is inaccurate. The task of defining a

I think we can strike the second sentence. Other than reducing this 
being marked as spam ;-), I don't think it adds anything. I have no 
better understanding of what an organizational domain is from those two 
examples. (So is my organizational domain "qti.qualcomm.com" or 
"qualcomm.com"? Is it more like example.com or example.co.uk, or is it 
something different?) I think the most we're going to be able to say is 
that an organizational domain is the domain that represents the top 
level of the organization, which doesn't help much.

>       3.  DMARC Usage
>
> The working group will deliver an implementation and deployment guide.
> The guide will catalog best current operational practices in terms of
> configuration, installation, monitoring, diagnosis and reporting. It
> will also develop advice on practices that are not yet well-established
> but which are believed to be appropriate.
>    

Simplifying again:

"     3.  DMARC Usage

The working group will document operational practices in terms of 
configuration, installation, monitoring, diagnosis and reporting. It 
will catalog currently prevailing guidelines as well as developing 
advice on practices that are not yet well-established but which are 
believed to be appropriate."

>     Goals and milestones
>     --------------------
>
> Phase I:
>
>     Draft description of interoperability issues and plausible methods
> for eliminating or reducing them.  This will not include final choices.
>
>     Draft Guide on DMARC Usage
>
>
> Phase II:
>
>     Specification of DMARC improvements to support better
>     interoperability
>
>     Review and refinement of the DMARC specification
>
> Phase III:
>
>     Completion of Guide on DMARC Usage
>    

First, I think the title should be "Work items". We already have a 
separate milestones list for documents. Also, I think we should make 
Phase I just figuring out the indirect mail flow thing and get some 
proposals sorted for that and then bump stuff forward:

"Work items
----------

Phase I:

    Draft description of interoperability issues for indirect mail flows 
and plausible methods for reducing them.

Phase II:

    Specification of DMARC improvements to address indirect mail flows

    Draft Guide on DMARC Usage

Phase III:

    Review and refinement of the DMARC specification

    Completion of Guide on DMARC Usage"

>     References
>     ----------
>
> DMARC - http://dmarc.org
> SPF - RFC7208
> DKIM - RFC6376
> Internet Message Format - RFC5322
> OAR / Original Authentication Results - draft-kucherawy-original-authres
> Using DMARC -  draft-crocker-dmarc-bcp-03
>    

There was some mention of adding existing proposals to this list. Seems 
like a good idea to me.

That's all I have. Hope you find it helpful.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 03 Jul 2014 15:03:31 +0900

Dave Crocker writes:

 > formulate 'needs'

I don't see that we have "needs" here.  We know how to do this stuff
as long as we can get access to certain non-MTA resources (the DNS, in
particular).  The thing about "organizational domain" is that
depending on how it's defined we may be able to dramatically reduce
demand for organizational resources (and for a caching service like
DNS, extra-organizational resources) by defining a canonical mapping
from authorized Author Domains to an Organizational Domain, which
maintains a single organization-wide policy.

So it's not a "need", it's a "bone of contention".  How about
"formulate use cases we would like such a definition to serve"?

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 03 Jul 2014 10:50:43 +0200

>>    technologies, but may document authentication requirements that

If MSK's interpretation is correct, I suggest rewording the paragraph
quoted above more or less like so:

  The working group may document what authentication requirements
  are desirable, but will not consider other mail authentication
  methods than DKIM and SPF.

I suggest that because the other passages, quoted below, can be done
without updating RFC 6376.  For example, draft may-forward specified a
form of DKIM signature in terms of "h=from; d=fromdomain; c=relaxed;
l=0; mf=targetdomain".  So the first bullet below wouldn't imply that
modifying DKIM is admissible if a new c14n algorithm were considered
an additional mail authentication technology.

> So I think you're covered.

In that case I support the charter, albeit its text can be improved.

Ale

---

From: Dave Crocker <[email-masked]>
Date: Thu, 03 Jul 2014 06:55:52 -0700

> I don't see that we have "needs" here.  We know how to do this stuff

Stephen,

First, note that the industry has operated for quite a long time with
only a highly deficient mechanism.  My understanding is that it has
broadly known that the mechanism was only moderately accurate.

Second, note that there has already been significant discussion within
the IETF about this topic and no readily-apparent mechanism has
developed enough traction to approach consensus.  That is, we don't yet
have an identifiable constituency that says "here's the perfect solution
and we want to promote it."  Rather, we have a few different folk
exploring -- From my reading of their postings, I don't think even the
advocates yet qualify as strong proponents -- approaches.

This does yet look like "we know how to do this stuff."  In fact, from
the long history and the recent discussions, my personal view is that
this looks like a difficult topic that needs rather careful thought
about design, deployment and use issues, and that it mostly will come
down to tradeoffs.

> "formulate use cases we would like such a definition to serve"?

In looking for a word to describe what the wg can reasonably do about
the external work, I settled on 'need' because I think it's /is/ pretty
straightforward for us to describe what we want to /do/ with a reliable
organizational domain mechanism, independent of how the mechanism might
work.

d/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 03 Jul 2014 07:11:42 -0700

> simplify. You can find a diff here:

I think Pete's changes mostly improve the text in terms of clarity
and/or conciseness.

> I think we can strike the word "careful". It doesn't add anything.

I put that word in intentionally.

The requirement being imposed here is a bit unusual, since it is
intended to make the wg fully document its reasons for creating changes
that break backward compatibility.  The word 'careful' is meant to
elicit thoughtful and thorough language for the justification.

In other words, it is meant to bias things against something like text
that just says "the wg reached consensus" and instead solicit "here are
the reasons...".

> level of the organization, which doesn't help much.

A sentence defining organizational domain is essential.

The term does not have wide, common use.  Yet it refers to a core
construct for DMARC.  So the charter should both use the term and
provide a basic definition for it.

Here's my (latest) suggestion for the paragraph, with each sentence
separated:

   The base specification relies on the ability of an email receiver to
   determine the organizational domain responsible for sending mail.

   An organizational domain is the 'base' name that is allocated from a
   public registry, such as ".com" or ".co.uk".

   Existing mechanisms for discerning the organizational domain have
   long-standing problems and there is community interest in a better
   solution.

   The task of developing that solution is out of scope for this
   working group.

   However the working group will provide input to any development
   effort for a standardized organizational domain mechanism.

>>     References

And we need to add:

   Delegating DKIM Signing Authority - draft-kucherawy-dkim-delegate-01

   Third-Party Authorization Label - draft-otis-tpa-label-04

d/

---

From: Pete Resnick <[email-masked]>
Date: Thu, 3 Jul 2014 10:07:25 -0500

> that just says "the wg reached consensus" and instead solicit "here are

OK, I see what you wanted to capture, but I guess what struck me about 
"careful" was that it implied that the default was "careless". How about 
this instead:

    The working group will seek to preserve interoperability with the
    installed base of DMARC systems, and will fully document the
    justification for any non-interoperability.

Seems a little less judgmental to me.

>>       2. Reviewing and improving the base DMARC specification"
>>      

I'm willing to believe that. I think *I* know what's meant, but perhaps 

>     public registry, such as ".com" or ".co.uk".

I think the "such as" clause confuses things because it leaves an 
ambiguity in the sentence as constructed: Is ".com" a public registry, 
or is it a 'base' name that is allocated from a public registry? (I 
believe you meant the former.) If you strike what's after the comma, I 
think that's OK, but not a great definition. Perhaps you want to say 
something like, "An organizational domain is the 'base' name that is 
allocated from a public registry over which the registrant is assigned 
authority" (or something to that effect), but I suspect there's some 
nuanced DNS-ese that could be used here.

pr

---

From: Dave Crocker <[email-masked]>
Date: Thu, 03 Jul 2014 08:47:10 -0700

>    justification for any non-interoperability.

I finally recognized the right keyword in my earlier note, so I've
modified your text to:

    The working group will seek to preserve interoperability with the
    installed base of DMARC systems, and provide detailed
    justification for any non-interoperability.

     An organizational domain is the 'base' name that is allocated from a
     public registry; examples of registries include ".com" or ".co.uk".

That says what's needed, says no more, and says it unambiguously.

The nuance of 'assigned authority' invites icann and dns debates we
don't need.  It's not that the phrasing is wrong but that it refers to
an issue that isn't relevant here, IMO.

d/

---

From: Pete Resnick <[email-masked]>
Date: Thu, 3 Jul 2014 11:10:09 -0500

> installed base of DMARC systems, and provide detailed justification 
> [...]

Both of those are fine with me.

I'll wait until tomorrow for any other comments, but then I'll get this 
onto the IESG agenda for internal review next week. Obviously approval 
won't happen until after (or during) Toronto, but if I can rope in the 
chair(s) in the meanwhile, we can start informally organizing the work 
here on the list.

Well done, folks.

pr

---

From: Pete Resnick <[email-masked]>
Date: Thu, 3 Jul 2014 11:22:18 -0500

> I'm not sure what this means. Can someone explain?

I still don't understand. Can we just strike this text?

pr

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 Jul 2014 12:26:25 -0400

> I still don't understand. Can we just strike this text?

I'll bet a pretty good lunch that it's the way of saying, "Rewriting
[email-masked] to [email-masked] is not
allowed."  That's something that people have started doing for mailing
lists.  But I can't say for sure that's what it means.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Pete Resnick <[email-masked]>
Date: Thu, 3 Jul 2014 12:20:50 -0500

> lists.  But I can't say for sure that's what it means.

Oh. If so, perhaps we could come up with a slightly less obscure way of 
saying it?

pr

---

From: "John Levine" <[email-masked]>
Date: 3 Jul 2014 18:31:01 -0000

>> lists.  But I can't say for sure that's what it means.

I thought it was also about address rewriting hacks like this one:

  From: "Your Name ([email-masked]) via foo list" <[email-masked]>

or even this one:

  From: Your Name <[email-masked]>

Insert by reference here 30 years of Reply-To: arguments.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 3 Jul 2014 18:32:39 -0000

>Both of those are fine with me.

That's fine with me, too, but be prepared for arguments from domains
like uk.com that sell subdomains underneath a different registry.

R's,
John

---

From: Pete Resnick <[email-masked]>
Date: Thu, 3 Jul 2014 19:32:38 -0500

On 7/3/14 12:20 PM, Pete Resnick wrote:
> Oh. If so, perhaps we could come up with a slightly less obscure way 
> of saying it?

Well, nobody has stepped up to the plate to help, so I'm going to go 
with the following:

"As the working group develops solutions to deal with indirect mail 
flows, it will seek to maintain the end-to-end nature of existing 
identifier fields in mail, in particular avoiding solutions that require 
rewriting of originator fields."

If you've got concerns with that, we'll take them up as "comments to the 
IESG on the proposed charter."

pr

---

From: Hector Santos <[email-masked]>
Date: Thu, 03 Jul 2014 22:15:11 -0400

On 7/3/2014 8:32 PM, Pete Resnick wrote:
> identifier fields in mail, in particular avoiding solutions that
> require rewriting of originator fields."
>
> If you've got concerns with that, we'll take them up as "comments to
> the IESG on the proposed charter."

I know this is just being all being ignored. Maybe you are reading it. 
But it has to go on the record.

There should not be any advocation for any form of 5322.From 
tampering, ever, especially as a justification for bypassing a 
security protocol, EVER.  I have a hard time that I even have to 
bother to highlight it.  Like you, I've been doing mail systems for 
30+ years, predating 822. This is a shop stopper (ignore this work) 
and also put pressures on IETF appeals.

This already highlights the need to add new rewrite filtering checks 
in the security section.  Its worst than the multiple 5322.From 
theoretical potential exploit.  Its more realistic that it can happen 
with folks with an negative affinity towards author domain policies. 
It puts ethical engineering pressure on list developers that we really 
should not be confronted with.  We don't want to encourage this type 
of mail tampering practice.  Please lets not crack up this door, 
Pandora Box, can of worms, etc, etc.  As a core mail principle, it 
MUST NEVER be valid to tamper with 5322.From, especially as a way to 
bypass a security protocol.

The entire idea needs to be out of scope.

-- 
HLS

---

From: Pete Resnick <[email-masked]>
Date: Thu, 3 Jul 2014 22:04:33 -0500

>> require rewriting of originator fields."

First an off topic comment, but I am doing so on list because everyone 

> But it has to go on the record.

If you feel you are being ignored or otherwise mistreated on this list 
(or anyone else feels that they are), by me or by another participant, 
posting to the list is *exactly* the wrong way to say something about 
it. It's completely inappropriate. It's disruptive, and it sets a 
terrible tone for everyone else. Send personal mail to me, or to the 
list moderator, or to the IETF Chair if need be. But doing it here is 
wrong and must stop.

End of admonition.

Deleting the rest of the "color commentary" and sticking to the specific 
issue you've brought up:

> security protocol, EVER. [...]

I don't understand: Are you saying that the text I have above in some 
way *advocates* for changes to the originator fields? I thought it is 
saying exactly the opposite.

> This is a shop stopper (ignore this work) and also put pressures on 
> IETF appeals.

Are you saying, "This is a show stopper. If we end up with a protocol 
that requires the rewriting of originator fields, this work will be 
ignored (by me? by others?), and the decision to do so will be appealed 
(by me? by others?)."? If you're saying any of those things, let's not 
get ahead of ourselves. There's no need to threaten appeals. It is 
simply important that when solutions get discussed, if a proposal is 
made for one that involves rewriting originator fields, those of us who 
feel that it is a show stopper need to clearly, concisely, and 
professionally lay out the arguments for why doing so is very 
problematic. A good chair should recognize the technical issues and will 
not call consensus if they are not satisfactorily addressed. Appeals are 
for when things go wrong, not when we're worried about things going wrong.

> [...]As a core mail principle, it MUST NEVER be valid to tamper with 
> 5322.From, especially as a way to bypass a security protocol.
>

So do I understand you to say that you think the text is not strong enough?

pr

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 04 Jul 2014 18:23:09 +0900

> > I don't see that we have "needs" here.  We know how to do this stuff

Let me clarify that by "this stuff" I mean authenticating *some*
domain as taking responsibility for injecting the mail.  This domain
is not necessarily the "organizational domain".

The problem I understand you to be excluding is that of mapping from
the information in the mail to an organizational domain which *should*
be taking responsibility, and which is the source for authoritative
information about authentication and authorization.  This is a
dreadfully hard problem.  Even in a "simple" direct mail case, the
(human) author, the originating system, the destination system, and
the (human) recipient may have different views on "optimal" definition
of the organizational domain that the originating system belongs to.
These differing views may or may not correspond to issues resulting
from interorganizational delegation in the DNS, but that's a biggee
(presumably technically solvable, not all of the differences are).  On
top of that there are the issues of alternative roots (all bets are
off?) and the syntactic issues about the difference in component
counts between .co.jp and .com.

But once somebody digests that hairball, I think we pretty much know
what to do with the resulting identifier: put it in d= in the DKIM
signature.  That's not enough to satisfy Hector and Doug, of course,
but that identifier also tells us where to find the information needed
to implement the third-party authorization mechanisms they want and

 > organizational domain mechanism, independent of how the mechanism might

I prefer to describe such 'needs' as 'use cases', 6 of one, half dozen
of the other I guess, except that 'use case' focuses on what we do,
and 'need' focuses on what they do.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 04 Jul 2014 09:27:06 -0700

> is not necessarily the "organizational domain".

Time to be pedantic, to get ducks lined up properly:

The sub-thread is about discerning the organizational domain (OD).  It's
not about authentication and it's not about 'responsibility'.  Those are
separate, higher-level topics.

As of now, there is no community history of delivering an acceptable
solution to identify OD and there is no community convergence on what to
even try, for doing it.   So with respect to OD, we have no community
agreement that we know how to do /that/.

Finding the OD is, of course, extremely important to DMARC.  No debate
about that.  However this sub-thread about the charter concerns what, if
any, activities should take place in the working group with respect to
organizational domain.

Besides DMARC, a mechanism for finding the OD is important to other
activities, too, and it is a discrete, DNS-related topic.  And there is
already an initiative in that space.

I think the DMARC wg can and should play a role in that other activity,
but we need to be careful that we don't confuse 'play a role' with 'work
on the solution', nevermind 'try to deliver a solution'.

Hence, my suggestion is that our chartered 'task' be one of providing
input to the other effort.

Hmmm... I suppose we should also cite adding the mechanism into the
DMARC spec, if there is a standard developed in time?

> information about authentication and authorization.

It's probably worth some redundancy:  Finding the OD in a domain name is
a mechanical process that has nothing to do with email, responsibility
or the like.  Those are layered on top.  Finding the OD is a component
mechanism, like finding the top-level domain, but harder.

The only thing that might be interesting here, in terms of DMARC
'needs', is to make sure we properly characterize how we are going to
use the OD, so that the other folk developing the OD mechanism can make
sure that what they produce is usable to us.  (Given the range of
functionality suggestions already made for finding the OD, the question
of how it will get used seems to be more complicated than one might
naturally have guessed.)

d/

---

From: "John Levine" <[email-masked]>
Date: 4 Jul 2014 16:53:54 -0000

>DMARC spec, if there is a standard developed in time?

Considering what we're (not) doing in DBOUND, I wouldn't hold my breath.

> (Given the range of

No kidding.  We're having trouble even coming up with a draft that
lists all of the different ways PSL data are used.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Jul 2014 12:59:05 -0400

On Fri, Jul 04, 2014 at 09:27:06AM -0700, Dave Crocker wrote:

> use the OD

> Considering what we're (not) doing in DBOUND, I wouldn't hold my breath.

Ok, but I still think Dave is right that DMARC should specify how it's
going to use this thing and either (1) leave it for someone else to
define a general mechanism or (2) give up on a general mechanism and
specify a DMARC-specific solution.  I think (2) is much worse than (1).

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Fri, 04 Jul 2014 09:58:56 -0700

> Considering what we're (not) doing in DBOUND, I wouldn't hold my breath.

Just trying to be thorough.  My real expectations match yours.  The only
point competing against that expectations is that the problem is a
rather narrow one... if we keep it that way.

d/

---

From: "John R Levine" <[email-masked]>
Date: 4 Jul 2014 13:05:43 -0400

> rather narrow one... if we keep it that way.

The reason it's hard is that there are a bunch of similar but different 
narrow problems, and approaches that work great for one work poorly or not 
at all for others.

Anyone who cares about this is welcome to join the dbound list.

https://www.ietf.org/mailman/listinfo/dbound

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

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 05 Jul 2014 16:35:18 +0900

Dave Crocker writes:

 > The sub-thread is about discerning the organizational domain (OD).
 > It's not about authentication and it's not about 'responsibility'.
 > Those are separate, higher-level topics.

I thought the subthread was about why *we* aren't going to talk about
discerning an OD beyond saying that once you've done that, you use it
in the relaxed alignment algorithm.  That's our use case, and ISTM
that's all we really have to offer to the DBOUND debate.

 > the DMARC wg can and should play a role in that other activity, but
 > we need to be careful that we don't confuse 'play a role' with
 > 'work on the solution', nevermind 'try to deliver a solution'.

I strongly agree both with playing a role and with your caveats.  I
think that's a consensus (at least from the posts so far).

 > DMARC spec, if there is a standard developed in time?

Doesn't the sentence from the proposed charter:

    However the working group can consider extending the base DMARC
    specification to accommodate such a standard, should it be
    developed during the life of this working group.

which is referring to OD, express that well enough?  You could move it
to a bullet point, I guess.

 > or the like.

We probably "must" define it in terms of a mechanical process, but we
should recognize that we're probably screwing some users when we do.
It forces some domains into using adkim=s and/or aspf=s when they'd
rather not (IIUC, the customers of com.uk are an example for some
definitions of OD).  It is not clear to me that we will be able to
serve all such needs simultaneously.

 > (Given the range of functionality suggestions already made for
 > finding the OD, the question of how it will get used seems to be
 > more complicated than one might naturally have guessed.)

My profession is economics: it's very natural for me to think in terms
of the variety of human ends being addressed rather than a collection
of technical proposals, and to therefore expect complexity.

What surprises me is how often a rather simple technical proposal
generates consensus because cooperation offers sufficient advantages
to all the individuals to offset the costs of overcoming human and
organizational inertia.

Unfortunately, I don't think "organizational domain" is susceptible to
that kind of solution ... but I'll keep hoping.

---

From: Hector Santos <[email-masked]>
Date: Sat, 05 Jul 2014 12:59:26 -0400

> It is simply important that when solutions get discussed, if a
> proposal is made for one that involves rewriting originator fields,
> those of us who feel that it is a show stopper need to clearly,
> concisely, and professionally lay out the arguments for why doing so
> is very problematic.

And there is where my concern lies.

This puts an unnecessary heavy burden on proving why it was a long 
time ethical engineering taboo to tamper with the "From" field of any 
communications I/O in the annals of telecomputing, especially for the 
purpose of breaking and getting around a new layer of mail security. 
  The mail comm I/O infrastructure was never designed for it and for 
long time historical good, legitimate and legal reasons.

Do we need to go into a justification why 5322.From is the only 
required header to be hash bound to the DKIM signature?  Thus making 
it technically impossible of disassociating the purported author 
identity from the signer identity?

Maybe we should do a DKIM errata to relax the 5322.From header hashing 
requirement? Or do so with the DKIM v=2 talks?

The DKIM threat analysis work considered the condition where a bad guy 
can purposely invalidate a signature and since DKIM mandates a MUST to 
ignore the signature as it was never signed, it was still possible to 
still protect the domain using a DKIM signature author domain 
authorization protocol policy. This was not something the signer 
domain could handle because it was invalidated. While the rewrite idea 
opens the door for good intention guys to bypass downlink DKIM related 
security checks, it opens the door on the bad guys to do the same thing.

> A good chair should recognize the technical
> issues and will not call consensus if they are not satisfactorily
> addressed. Appeals are for when things go wrong, not when we're
> worried about things going wrong.

Engineering training and experiences gives us the ethical and 
engineering insights to know what is right and wrong.  We don't need 
to waste time in waiting for the obviously bad thing to go wrong 
before action is taken and with the IETF appeal process, its generally 
too late. I am absolutely worried that indirect endorsement or 
redesign considerations for rewrites will not only seriously damage 
DKIM and any policy work, it can have a drastic impact on decades of 
integrated mail design expectations across the board.

> So do I understand you to say that you think the text is not strong

Probably. Whats stronger than strong?  Outlawed?

By specifically highlighting it in the charter text as you suggest, it 
is presented as the specific alternative solution to the DKIM 
signature identity authentication/authorization problem.

It is not an alternative solution in the same way a double From wasn't 
a alternative to bypassing DKIM security checks.  It should to be 
presented among the potential serious security problems and not as the 
"path of least resistance" alternative to get around a mail security 
wall.

Thanks

-- 
HLS

---

From: Pete Resnick <[email-masked]>
Date: Sat, 5 Jul 2014 22:20:33 +0300

On 7/5/14 7:59 PM, Hector Santos wrote:
> This puts an unnecessary heavy burden on proving why...

Well, let's be clear: The current charter text says that the WG is going 
to avoid such solutions. So the *initial* "burden of proof" (so to 
speak) is going to be on those proposing a solution that rewrites 
originator fields. It is only once they make a case that it *is* 
reasonable to do such a thing, both at a technical level and as a matter 
of doing something against the charter, that folks might be asked to 
explain why it is still problematic in light of the new information 
brought forth by the proponents.

At least that's the way I read the current charter text.

> We don't need to waste time in waiting for the obviously bad thing to 
> go wrong before action is taken and with the IETF appeal process, its 
> generally too late.

Many tend to forget that the appeal process does not start with an 
appeal to the IESG at Last Call or later. In fact, it doesn't start with 
an "appeal" at all. If anyone disagrees with a WG decision, whether a 
strictly technical objection or because the WG simply failed to properly 
consider an alternative view, that should get brought to the chair 
immediately. No waiting.

> I am absolutely worried that indirect endorsement or redesign 
> considerations for rewrites...

I don't see this "indirect endorsement or redesign considerations for 
rewrites" in the charter text.

> Probably. Whats stronger than strong?  Outlawed?

The current text is now in front of the IESG for internal review. 
Assuming we approve it for external review on Thursday, you will see a 
announcement soliciting comments. A simple comment, with specific 
suggested textual changes, would be welcomed.

pr

---

From: Hector Santos <[email-masked]>
Date: Sat, 05 Jul 2014 16:09:05 -0400

> suggested textual changes, would be welcomed.

    Rewrites of 5322.From headers are a serious security problem
    that will damage the efficacy and purpose of mail security
    goals of the DMARC protocol and also set a dangerous precedence
    for the mail framework as a whole.  It is therefore out of scope.
    The WG will not justify nor promote rewrite proposals and will
    consider them as security problem to mitigate in the security
    section.

Thanks

-- 
HLS

---

From: Pete Resnick <[email-masked]>
Date: Sat, 5 Jul 2014 23:44:15 +0300

>    consider them as security problem to mitigate in the security

Your suggestion will be taken into consideration. I will certainly 
forward it to the IESG during external review if you don't.

(I should say that I *personally* don't think it's necessary to make 
such a strong statement, as I don't think it's going to change the 
outcome. So if others think that the statement needs strengthening along 
these lines, do speak up at external review time. Either way, I will 
make the IESG aware of the comment.)

pr

---

From: Andreas Schulze <[email-masked]>
Date: Mon, 7 Jul 2014 21:33:20 +0200

>   From: "Your Name ([email-masked]) via foo list" <[email-masked]>

Hello,

while we discussing about obscuring From lines my customers get such messages:
From: "Paypal Customer Server ([email-masked])" <random_user@random_non_dmarc_domain>

Spammers adopt fast ...

Andreas