Subject: [dmarc-ietf] WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc)

From: The IESG <[email-masked]>
Date: Mon, 14 Jul 2014 09:42:12 -0700

A new IETF working group has been proposed in the Applications Area. The
IESG has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2014-07-24.

Domain-based Message Authentication, Reporting & Conformance (dmarc)
------------------------------------------------
Current Status: Proposed WG

Assigned Area Director:
  Pete Resnick <[email-masked]>

Mailing list
  Address: [email-masked]
  To Subscribe: https://www.ietf.org/mailman/listinfo/dmarc
  Archive: http://www.ietf.org/mail-archive/web/dmarc/

Charter:

   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.

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

   However, DMARC is problematic for mail that does not flow from
   operators having a relationship with the domain owner, directly to
   receivers operating the destination mailbox. Examples of such
   "indirect" flows are mailing lists, publish-to-friend functionality,
   mailbox forwarding (".forward"), and third-party services that send
   on behalf of clients. The working group will explore possible updates
   and extensions to the specifications in order to address limitations
   and/or add capabilities. It will also provide technical
   implementation guidance and review possible enhancements elsewhere in
   the mail handling sequence that could improve could DMARC
   compatibility.

   Specifications produced by the working group will ensure preservation
   of DMARC utility for detecting unauthorized use of domain names,
   while improving the identification of legitimate sources that do not
   currently conform to DMARC requirements. Issues based on operational
   experience and/or data aggregated from multiple sources will be given
   priority.

   The working group will seek to preserve interoperability with the
   installed base of DMARC systems, and provide detailed justification
   for any non-interoperability. 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.

   Working group activities will pursue three tracks:

      1. Addressing the issues with indirect mail flows

   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:

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

      2. Reviewing and improving the base DMARC specification

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

   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; examples of registries include ".com" or ".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 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.

   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

      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.

   The group will consider separating configuration and other deployment
   information that needs to be in the base spec, from information that
   should be in a separate guide.

   Among the topics anticipated to be included in the document are:

      - Identifier alignment configuration options
      - Implementation decisions regarding "pct"
      - Determining effective RUA sending frequency
      - Leveraging policy caching
      - Various options for integrating within an existing flow
      - Defining a useful, common set of options for the addresses to
        which feedback reports are to be sent
      - When and how to use local policy override options

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

Milestones:

TBD

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Jul 2014 12:21:23 -0700

(re-posted under my ietf-dmarc subscription address, rather than ietf
one.  content otherwise the same.  /d)

> your comments to the IESG mailing list (iesg at ietf.org) by 2014-07-24.

The first paragraph of a charter is circulated independently of the
rest, such as when announcing the working group.

As such, it needs to serve as a kind of abstract.  This is why there is
a requirement, specified in RFC 2418 (WG Guidelines & Procedures),
"Description of working group:

     "The first
      paragraph must give a brief summary of the problem area, basis,
      goal(s) and approach(es) planned for the working group..

>    the mail handling sequence that could improve could DMARC

The DMARC draft charter's first paragraph does not state any goals.
This can be fixed by moving the last two sentences of the third
paragraph, to the end of the first.

That is, end the first descriptive paragraph with:

  "The working group will explore possible updates

and delete it from it's current position.

>    References

This is missing two citations that I thought were supposed to be
included, since they touch on indirect email flows:

   Delegating DKIM Signing Authority - draft-kucherawy-dkim-delegate-00
   DKIM Third-Party Authorization Label - draft-otis-dkim-tpa-label-03

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Jul 2014 10:31:23 -0700

"The first

d/

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 14 Jul 2014 16:47:19 -0400

>    DKIM Third-Party Authorization Label - draft-otis-dkim-tpa-label-03

If we're adding references, I think RFC 7001,  Message Header Field for 
Indicating Message Authentication Status, should be included as well.  It's, I 
think a matter for the WG to decide if RFC 7001 provides enough or if an 
extension like OAR is needed.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 16 Jul 2014 12:51:44 -0400

>   DKIM Third-Party Authorization Label - draft-otis-dkim-tpa-label-03

Why not ATPS RFC6541 production?

http://tools.ietf.org/html/rfc6541

Consider ATPS the "lite version" of Doug's TPA. The same lookup hashing algorithm is used in both.  Further, there is real high quality commercial "running code" implementations supporting rfc6541.  All of our installations have DKIM+ADSP+ATPS out of the box with their primary domain used for automated first time setup plug and play readiness.

--
Hector Santos
http://www.santronics.com

---

From: Pete Resnick <[email-masked]>
Date: Wed, 16 Jul 2014 12:42:31 -0500

Folks, can I ask that you please remove [email-masked] from the recipient 
list if you want to have discussion that doesn't pertain to the charter 
itself.

I'm hoping to recruit a prospective chair in the next few days to start 
moderating the discussion on the DMARC list itself while we're still 
dotting i's and crossing t's of the charter. I'm happy to have 
free-wielding discussion go on a bit, but please let's try and keep it 
to a dull roar while we're getting organized.

Thanks.

pr

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

---

From: Douglas Otis <[email-masked]>
Date: Sat, 19 Jul 2014 21:27:49 -0700

Dear Hector,

See comments inline:

On Jul 16, 2014, at 9:51 AM, Hector Santos <[email-masked]> wrote
> Consider ATPS the "lite version" of Doug's TPA. The same lookup hashing algorithm is used in both.  Further, there is real high quality commercial "running code" implementations supporting rfc6541.…

ATPS is not the "lite version" of TPA-Label.  This is explained in 
http://tools.ietf.org/id/draft-otis-tpa-label-04.html#rfc.appendix.C

ATPS requires DKIM signatures used by Third-Party Services to somehow determine different label encoding methods permitted by ATPS.  ATPS also lacks any discovery or exchange method for this. In contrast, TPA-Label makes NO demands on third-Party services.  None.  Since there is only one encoding method, there is NO guesswork discovering the listing encoding method. 

The extra processing is only done when DMARC indicates non-complaince where the DMARC domain can then indicate whether they have informally federated the domain in question and what if any additional information must be included in the message.  In comparison, processing a new DKIM-ike signature involves greater overhead than that needed to obtain a TPA-Label resource which happens only after the domain in question has been validated.  It seems TPA-Label represents far easier deployment and far less overhead since the Third-Party makes no change to their process and only a single, small, cacheable TPA-Label resource is provided by the DMARC domain.

While the DMARC domain can delegate the domain offering the TPA-Labels, a single server is more than able to handle what would be needed to satisfy the largest email provider, although two should be deployed for redundancy.  If a domain is being abusive, a TPA-Label can even offer a cacheable negative federation response.  TPA-Label is also able to selectively enable specific uses of Sender header fields or specific use of List-IDs.  When there is a problem with a third-party domain that ignores DMARC, the TPA-Label can also require use of OAR headers.  Unlike ATPS, TPA-Label is far easier and is capable of enabling all valid email without causing disruption.

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Sun, 20 Jul 2014 11:50:29 -0400

On 7/20/2014 12:27 AM, Douglas Otis wrote:>

> ATPS requires DKIM signatures used by Third-Party Services to somehow determine different label encoding methods permitted by ATPS.

Hi Doug,

ATPS just requires the existing of the record. It puts no meaning in 
the content or data returned from a successful ATPS lookup:

    NXDOMAIN:  No resigner authorization found
    SUCCESS:   Resigner authorization found

Either the record exist or it doesn't. Both ATPS and TPA offer similar 
lookup as a function of author and signer domain:

    YesNo = IsSignerAuthorized(ADID, SDID)

where

    ADID is the author domain
    SDID is the signer domain, if any.

They both have same functional goals and outcome. TPA just provides 
extra and complex semantics and meaning for the content of the 
existing record.

> ATPS also lacks any discovery or exchange method for this.

With the exception of the arbitrarily selected underscore and/or 
sub-domain delimiters, both have the near similar lookup algorithm 
using a base32(sha1()) hashing discovery method:

    ATPS:  base32(sha1(SIGNER-DOMAIN))._atps.AUTHOR-DOMAIN
     TPA: _base32(sha1(SIGNER-DOMAIN))._adsp.AUTHOR-DOMAIN

The TPA Label is just a sub-domain. The label or "subdomain" can only 
be declared once for one lookup meaning.  To have a different meaning, 
you need a different lookup subdomain or label.

> In contrast, TPA-Label makes NO demands on third-Party services.  None.

Come on. Its all the same thing. Please. We have been at this for 
nearly 9 years.

ATPS "labels" a.k.a. subdomains, doesn't require any demands on 
resigners other than to play the same game (follow the protocol) as 
expected of all DKIM verifiers.  We really don't know how the 
"Database" will be created, but at this point, it is the AUTHOR-DOMAIN 
that is the base zone of the lookup algorithm that is currently 
responsible to make this work.   How this all scaled and managed, 
delegated is a complex DNS administration related topic.  But from a 
protocol standpoint, it the same tool and method for a lookup to 
resolve the problem we have today is:

      Should the 3rd party do a LOOKUP or NOT to filter restrictive 
domains?

The problem is that its not doing any kind of check, not even the 
first level DMARC check to filter our the problematic restrictive mail 
domains, including the ones that have changed mid-stream and there 
exist legacy domains in 3rd party membership areas that need to be 
cleaned up -- a migration problem.

TPA is no different than ATPS or any other kind of lookup that needs 
to be done to make this a protocol complete integrated solution.

All TPA has is extra, complex semantics and big enterprise terms like 
"federation" associated with it.   ATPS can have a "federation" too! 
TPA is written way too complex for what it does Doug, otherwise I 
would of added support for it when it first came out.

But at the end of the programming day, its all the same thing which 
resolves a simple question; Is the DKIM signer authorized as a 
function of the signer and author domain?

Further, there are at least two SMTP packages (SendMail, Wildcat! 
SMTP) that I am aware of, that have ATPS included in their API and 
deployment options.  I don't know of any using TPA.

     Note: The fact that traction is not apparent can not be used for
     judgment, because it wasn't championed, pushed and at the time, 
ADSP was
     being pushed out (erroneously IMO).  ATPS (and TPA) required ADSP to
     piggyback of its record to trigger a third party ADSP extension. 
  We are
     now trying to change ATPS and TPA to piggyback off DMARC to continue
     with the resigner authorization model that DMARC lacks.

Look, I really don't care whats used. If TPA is going to be considered 
in the DMARC WG charter, then common sense management and engineering 
tells you, ATPS should also be part of the charter, and it will be 
very strange if it doesn't.  ATPS is the "lite version" of TPA and 
offers the basic same functionality of authorizing a signing domain.

I have nothing against TPA, and I told you that many years ago.  ATPS 
is written to simplify what you had with TPA and to scale the simplest 
ASL idea of having ADSP tag extension:

    asl=comma delimited list of authorized domains

in a ADSP record which is what I was pushing for the smaller scale.

The TPA extra data is not required but I am not saying it not a good 
idea.  I think it was TOO COMPLEX for the basic first level resolution 
question being sought -- is that resigner authorization, yes or no?

Whatever "guts" is added behind the above functional equation, needs 
to be simple in order to get wide and quick support at all discipline 
levels.  ATPS and TPA are going to get much push back because of the 
hashing method.  Creating the database of "labels" is going to be a 
problem too. But again, its really about selling the idea of a 
"lookup" for a resigner authorization.  Once that concept is sold, the 
method and/or database can be done one way or another, and it doesn't 
have to be via DNS.

TIP:

What you should do is offer an equivalent match for ATPS records which 
means the simplest content you can have for a lookup.  ATPS does not 
require any data. What is the minimum for TPA?

-- 
HLS

---

From: Eric Burger <[email-masked]>
Date: Sun, 20 Jul 2014 14:23:36 -0400

I will not comment on the 85 messages in the thread.  However, I would like to point out that STIR is working on a similar problem with similar goals but in a more constrained environment.  I would offer coordination between WG’s, should DMARC be chartered, would be “a good thing.”

---

From: Hector Santos <[email-masked]>
Date: Sun, 20 Jul 2014 16:01:27 -0400

I would like to see a better integrated, cross-area engineering effort.  There is much to do in the integrated area of new domain authorization "permission-based" policy concepts.   We have a tendency of repeating the similar concepts across proposed multiple protocols.  In an evolved, modern SMTP receiver, it could perform 3-6 or more DNS redundant lookups for each transaction, and they are not flexible enough to be lumped together.

> On Jul 20, 2014, at 2:23 PM, Eric Burger <[email-masked]> wrote:
> 
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc