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

[Scott Kitterman <[e-mail]>]

I think you are making far too much of this.  I've been implementing this as 
we go and it's pretty trivial.

Scott K

On Tuesday, March 22, 2022 10:27:37 PM EDT Douglas Foster wrote:
> 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 <
> 
> [e-mail]> wrote:
> > 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 <[e-mail]>
> > 
> > wrote:
> >> I gather then that your claim is that RFC 7489 isn't implementable.  Is
> >> that right?
> >> 
> >> Scott K
> >> 
> >> On March 22, 2022 11:11:40 AM UTC, Douglas Foster <
> >> 
> >> [e-mail]> wrote:
> >> >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 <[e-mail]>
> >> >
> >> >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.
> >> >> 
> >> >> I find it very difficult to relate what is in your email to the text
> >> >> in
> >> >> the draft.
> >> >> 
> >> >> Scott K
> >> >> 
> >> >> On March 22, 2022 3:03:59 AM UTC, Douglas Foster <
> >> >> 
> >> >> [e-mail]> wrote:
> >> >> >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.
> >> >> 
> >> >> _______________________________________________
> >> >> dmarc mailing list
> >> >> [e-mail]
> >> >> https://www.ietf.org/mailman/listinfo/dmarc
> >> 
> >> _______________________________________________
> >> dmarc mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dmarc