Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-06.txt

From: [email-masked]
Date: Mon, 21 Mar 2022 13:50:42 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF.

        Title           : Domain-based Message Authentication, Reporting, and Conformance (DMARC)
        Authors         : Todd M. Herr
                          John Levine
	Filename        : draft-ietf-dmarc-dmarcbis-06.txt
	Pages           : 62
	Date            : 2022-03-21

Abstract:
   This document describes the Domain-based Message Authentication,
   Reporting, and Conformance (DMARC) protocol.

   DMARC permits the owner of an email author's domain name to enable
   verification of the domain's use, to indicate the Domain Owner's or
   Public Suffix Operator's message handling preference regarding failed
   verification, and to request reports about use of the domain name.
   Mail receiving organizations can use this information when evaluating
   handling choices for incoming mail.

   This document obsoletes RFC 7489.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-06.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-dmarcbis-06

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: Douglas Foster <[email-masked]>
Date: Mon, 21 Mar 2022 23:03:59 -0400

We have significant functional differences between the two tree walks,
which are lost or ignored in the current prose.   This lack of precision
has also allowed us to overlook error handling, which is different between
the two types of tree walk.

I have provided a rough cut of the primary tree walk, using an outline
approach rather than prose.   For the secondary tree walk, I only have
summary comments about how it differs from the primary tree walk.  I could
beef up both sections after feedback

Doug

There are potentially two types of tree walks, both of which can be avoided
under specific circumstances.

- The primary tree walk is used to find the RFC5322.From address
organizational domain and associated default policy, and is performed
once.

- The secondary tree walk is used to test each verified domain for
alignment with the RFC5322.From domain.

1)      RFC5322.From tree walk to Organizational Domain

Exact-match check

-------------------------

- (optionally) verify that the lowest segment is a valid label (doesn't
start with an underscore, 64 or fewer characters long.  If format rules are
violated, return an error.

- check for TXT records at _dmarc.<domain name>

- if no DMARCv1 records are found, report no-data-found and exit.   Proceed
to the organization domain and default policy search.

- if two records are found, or if a single record does not parse correctly,
return an error.

- if one usable record is found, check for a <role> indicator, and proceed
as follows:

      If a <not-for-mail> indicator is detected, return a DMARC Fail result.

      If both alignment policies are strict, the organization domain and
policy are not needed, so the primary tree walk is omitted.  Otherwise, the
tree walk is invoked to determine the organizational domain and default
policy

If the tree walk is to be used, check to see if the From domain is more
than <Max=5> segments. If so, shorten the domain to <Max=5> segments.
Otherwise, remove one segment and check the resulting domain name for a
DMARC policy.   Then evaluate the shortened domain name:

- (optionally) verify that the first segment of the domain name is a
valid label (doesn't start with an underscore, 64 or fewer characters
long.  If format rules are violated, return an error.

- check for TXT records at _dmarc.<domain name>

- if no DMARCv1 records are found, report no-data-found and exit the step
so the search can continue.

- if two records are found, or if a single record does not parse correctly,
return an error.

- if one usable record is found, check for a <role> indicator, and proceed
as follows:

       If a <non-boundary role> indicator is present, return no-data-found
and exit the step so the search can continue.

       If a <psd role> indicator is present, return the cached domain and
policy, ending the search.

       If a <top-of-organization role> indicator is present, return the
current domain and policy, ending the search.

       If no indicator is found, cache the domain name and policy as a
possible organizational domain.  Exit the step so the search can continue.

If a step exits with a confirmed organizational domain and default policy,
the search is complete.

If a step exits with no-data-found, and the domain name has at least 2
segments, then remove the first segment and repeat the domain evaluation.

If a step exits with no-data-found, and the domain name is only 1 segment,
then the search terminates.

    If a cached organization domain and default policy are available, these
are the organizational domain and default policy.

    If the cache is empty, no organizational domain is found.

          If an exact-match policy was previously detected, so that the
tree walk was only needed for relaxed alignment, then the match rule
reverts to strict.

          If an exact-match policy was not detected, the domain does not
participate in DMARC.

2)      Secondary Tree walk to test for alignment

This has some notable differences from the Primary Tree Walk.

-          The search only returns an “Aligned” or “Unaligned”.   The
values of the organization domain name and default policy will be known if
the names are aligned, and unimportant if the names are not aligned.

-          Only one alignment result is needed, so domain evaluation ceases
as soon as an aligned result is obtained.

-          If a DMARC policy error is detected during evaluation, the
domain being evaluated is discarded as not aligned, but the evaluation
proceeds.

-          The common substring should be determined.    If the common
substring is shorter than the organizational domain, the domains are not
aligned, and the tree walk is not necessary.  Otherwise, the tree walk is
performed, but it terminates when the common substring is reached, rather
than when the domain string is exhausted.

-          If an organization boundary is detected during the tree walk,
the domain being evaluated is discarded as not aligned.

-          If no organization boundaries are identified during the tree
walk, the names are aligned.

If the domain is discarded as not aligned, the alignment search proceeds to
the next DKIM-verified or SPF-verified domain name.

If the set of verified domain names contains any duplicates, only one
evaluation needs to be performed and the duplicates can be ignored.

There are significant benefits expected from prioritizing the order in
which verified domain names are tested.  Recommended sequence:

-          Exact-match domains

-          Parent domains.   Only the longest match needs to be evaluated.

-          Child domains.   Only the shortest match needs to be evaluated.

-          Sibling domains.   Process in order from longest common
substring to shortest common substring.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 22 Mar 2022 04:16:08 +0000

Doug,

I think you are mistaken.  The Organizational Domain is what is used to test alignment.  If you have suggested changes from what's in DMARCbis06, I think it would be easier if you made specific recommended changes.

Also, the level of detail in the current draft is very similar to what is in RFC 7489.  If you think we need a more detailed exposition than there is in the existing DMARC spec, please explain what current issues you are seeing that you are trying to solve.

I find it very difficult to relate what is in your email to the text in the draft.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 22 Mar 2022 10:54:33 +0100

I think we need something like the following.

> https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/

OLD
5.5.4.  Publish a DMARC Policy for the Author Domain

    Once SPF, DKIM, and the aggregate reports mailbox are all in place,
    it's time to publish a DMARC record.  For best results, Domain Owners
    SHOULD start with "p=none", with the rua tag containg a URI that
    references the mailbox created in the previous step.

NEW (add or replace)
5.5.4.  Publish a DMARC record for the Author Domain

    A DMARC record MUST be defined at the Organizational Domain, that is the
    shortest domain that belongs to the organization, see Section 3.2.7.  This
    domain determines the alignment of the identifiers.  The domain part of the
    aggregate reports mailbox also needs to be aligned, otherwise an additional
    DMARC record for external destination verification has to be defined.  If
    any subdomain of the organization is used as an Author Domain, a DMARC
    record for that subdomain MAY be defined.  For example, the subdomain may
    want a different policy or different reporting mailboxes.

    If a subdomain is independent from the organization, that is if the
    organization delegated control of the subdomain to another organization,
    then the former organization is a PSO.  In that case, it is necessary to use
    the psd flag to break alignment, so that an organization cannot impersonate
    another one.

Is that obscure enough?

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Tue, 22 Mar 2022 07:11:40 -0400

We need an algorithm with enough detail to ensure that it can be
implemented consistently, something closer to the RFC for SPF rather than
RFC 7489.

For example, it is only when you get into the weeds do you discover that
error handling for the primary walk needs to be different than error
handling for the secondary walk, and that this has security implications.
 A policy error on the secondary walk MUST be ignored, rather than
triggering PERMERROR.  Otherwise an attacker could create a domain with an
invalid DMARC policy, then sign an impersonating message with that domain,
causing the evaluator to conclude PERMERROR instead of REJECT, defeating
the domain owner policy.

We need to have though through the implementation issues with as much care
as will be needed by developers.    This is no small feat.  I have already
thought of a few refinements since last night.  We probably cannot succeed
without a  reference configuration.

I don't have any problem with the tree walks as a replacement for the PSL.
 But I don't think we are close to a usable document because it is simply
too vague.

Doug

On Tue, Mar 22, 2022 at 12:16 AM Scott Kitterman <[email-masked]>
wrote:

> Doug,
>
> I think you are mistaken.  The Organizational Domain is what is used to
> test alignment.  If you have suggested changes from what's in DMARCbis06, I
> think it would be easier if you made specific recommended changes.
>
> Also, the level of detail in the current draft is very similar to what is
> in RFC 7489.  If you think we need a more detailed exposition than there is
> in the existing DMARC spec, please explain what current issues you are
> seeing that you are trying to solve.
>
> On March 22, 2022 3:03:59 AM UTC, Douglas Foster <
> [email-masked]> wrote:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 22 Mar 2022 11:47:13 +0000

I gather then that your claim is that RFC 7489 isn't implementable.  Is that right?

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 22 Mar 2022 11:16:13 -0400

On Tuesday, March 22, 2022 5:54:33 AM EDT Alessandro Vesely wrote:
> then the former organization is a PSO.  In that case, it is necessary to
> use the psd flag to break alignment, so that an organization cannot
> impersonate another one.
> 
> 
> Is that obscure enough?

I think we need something here.  I agree with your core point that 
Organizational Domain has to have a DMARC record and we should say that.  I 
would spend the words on more PSO description here.  Almost no one is a PSO 
and we shouldn't over emphasize it.

I need to take another turn on the words I've been working on based on other 
comments.  I'll include something along these lines in that update and then 
you can see what you think.

Scott K

---

From: Douglas Foster <[email-masked]>
Date: Tue, 22 Mar 2022 21:40:36 -0400

No, I think the RFC 7489 algorithm is much simpler than this one.
John was adamant that we only needed one indicator.  Then he conceded that
we need two.  Now he thinks we need three.  Ale and I said early on that we
thought we needed four.

On Tue, Mar 22, 2022 at 7:47 AM Scott Kitterman <[email-masked]>
wrote:

> On March 22, 2022 11:11:40 AM UTC, Douglas Foster <
> >> >If the domain is discarded as not aligned, the alignment search
> proceeds
> >> to

---

From: Douglas Foster <[email-masked]>
Date: Tue, 22 Mar 2022 21:55:56 -0400

Suppose a FROM address domain has the lower-bound of 5 segments, and that a
verified DKIM signature exists using a child domain somewhere below that,
perhaps with 7 segments.

Are the names automatically considered to be aligned, without a tree walk,
because a private registry boundary will not occur below level 5?  Or
should a scope-limited tree walk be performed between the child domain and
the FROM domain to be sure that no boundary exists?

Doug

---

From: Douglas Foster <[email-masked]>
Date: Tue, 22 Mar 2022 22:08:35 -0400

John and Ale have talked about what role, if any, should be given to
analyzing the common substring between an RFC5322.From domain and a
verified SPF or DKIM domain.   During my ruminations last night, I gained
some clarity around that question and wanted to highlight those
conclusions.  They simplify the alignment search significantly:

- If the common substring is shorter than the Organizational Domain, then
the names are not aligned and the candidate domain can be ignored.

- Otherwise, if any candidate domain is a parent of (or equal to) the FROM
domain, then and we have alignment and DMARC PASS.  The secondary tree walk
is not needed and no further evaluation is required.

- If several candidate names are child domains of the FROM address, then
only the shortest string needs to be evaluated with a secondary tree walk.
If it is aligned, further evaluation is not required.  If it is not aligned
because of an organizational boundary, all other child domains are also
excluded.

I did not identify any optimizations for sibling domains, other than to
look for parent and child matches first.

Doug

---

From: Douglas Foster <[email-masked]>
Date: Tue, 22 Mar 2022 22:27:37 -0400

The response below went out prematurely and incomplete, but I hope you can
see where we I was going.   We have an ever-changing algorithm as we try to
do a desk analysis of the problem.

One of my purposes for the outline was to see how many indicators we will
need, by identifying what actions we would like to trigger based on those
indicators, as well as clearly defining how we cope with the expected
absence of indicators within each situation.

Trying to implement a specification is the best way to learn whether a
specification provides a developer with sufficient guidance to produce the
intended result.   In our case, we need a specification which provides
sufficient information to many developers.   That is a tall order.

Doug

On Tue, Mar 22, 2022 at 9:40 PM Douglas Foster <
[email-masked]> wrote:

>> >> >start with an underscore, 64 or fewer characters long.  If format
>> rules
>> >> are
>> >> >policy are not needed, so the primary tree walk is omitted.
>> Otherwise,
>> >> the

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 23 Mar 2022 11:59:08 +0100

Hm...

On Wed 23/Mar/2022 03:08:35 +0100 Douglas Foster wrote:
> During my ruminations last night, I gained some clarity around that 
> question and wanted to highlight those conclusions.  They simplify the 
> alignment search significantly:
> 
> - If the common substring is shorter than the Organizational Domain, then the 
> names are not aligned and the candidate domain can be ignored.
> 
> domain, then and we have alignment and DMARC PASS.  The secondary tree walk is 
> not needed and no further evaluation is required.
> 
> - If several candidate names are child domains of the FROM address, then only 
> the shortest string needs to be evaluated with a secondary tree walk.  If it is 
> aligned, further evaluation is not required.  If it is not aligned because of 
> an organizational boundary, all other child domains are also excluded.

That and the deeper-than-5 optimization Doug posted on a separate message.

I know the document is already longish.  However, collecting these observations 
in an appendix may be helpful for developers, and maybe also for general 
understanding of the intricacies involved in the tree walk, including proper 
usage of the psd= flag.

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Wed, 23 Mar 2022 18:07:07 -0400

One other optimization that I omitted from that note:

The common substring cannot be longer than the From domain, and we discard
any where the common substring is shorter than the organizational domain.
 Therefore, the common substring is always an aligned domain!   (The
primary tree walk has already scanned the path between the From domain and
Organizational domain.)

We don't need a tree walk for parent domains, because the common substring
will be the entire candidate domain, and therefore aligned.

Because the common substring is aligned, when performing a tree walk for
child and sibling domains, we only need to walk up from the candidate
domain to the common substring.  This involves less processing than if we
had to walk all the way up to the organizational domain.

Doug

On Wed, Mar 23, 2022 at 6:59 AM Alessandro Vesely <[email-masked]> wrote:

> only