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

[Scott Kitterman <[e-mail]>]

What would be the benefit of all this extra complexity?  What does a domain 
with an unhelpful PSD get over publishing psd=n based on the current draft?

I think there's some small chance of the problem I think you are describing 
occurring, but I believe we've addressed it already in a much simpler way.

Scott K

On Thursday, April 21, 2022 10:24:26 PM EDT Douglas Foster wrote:
> Yes, there is a fundamental difference between a vulnerability that is
> created because of a change in rules, as compared to a design that requires
> convincing a third party to act contrary to that parties intended purpose.
> 
> But to the problem that you want to solve:
> 
> Assume that a savvy email manager is trying to decide whether to embrace
> the new design or not.   He is likely to run both algorithms and evaluate
> the results.   If the two algorithms produce the same result, he is happy.
>  If the DNS produces a lower organization domain, he is happy to accept the
> more restrictive alignment scope.
> 
> But if the DNS produces a higher organization domain, he is skeptical.   We
> need to provide assurance that the located organization domain is in the
> same organization as the subdomain FROM address that started the process.
>  This is as simple as a policy token which says "no organizational
> boundaries below".    An integer seems to make the most sense:
> 
> Given an organizational domain of "orgdomain.parentpath"
> - OrgsBelow=0 - means the entire subtree is one organization, no
> organizational boundaries exist below "orgdomain.parentpath"
> - OrgsBelow=1 - this is a registrar domain and the next level down is
> registered clients.  "sub1.orgdomain.parentpath" is a separate organization
> from "orgdomain.parentpath"
> -  OrgsBelow=2 - an organization boundary exists two levels down.
> "sub1.orgdomain.parentpath" is part of "orgdomain.parentpath" but
> "sub2.sub1.orgdomain.parentpath" is a separate organization.
> And so forth.  Based on our analysis, the highest expected value is 3, but
> the design is insensitive to the value published.   A very high value like
> 99 is effectively equivalent to the value 0.
> 
> (Optionally, we could specify that OrgsBelow<0 means that there are no
> subdomains in the organization, so any appearance of a subdomain is
> fraudulent.   This is a stronger repudiation than SP=reject.)
> 
> For the vast majority of domains that are not private registries, using
> OrgsBelow=0 allows them to be completely free of the PSL.
> 
> Organizations that fail to publish this flag will be vulnerable to trust
> issues, since a cautious email manager will worry that they may contain a
> private registry.    If the evaluator responds to this risk by comparing
> the DNS result to the PSL result, and the PSL result is lower, the savvy
> evaluator may choose the lower entry.  If this is not what the domain owner
> wants, he should publish the OrgsBelow indicator.
> 
> Doug Foster
> 
> The malicious client of a private registry can no longer attack
> unilaterally.  If he manipulates his DMARC settings to direct evaluators to
> the registrar's organizational domain, the attack is expected to fail,
> either because (a) the registrar publishes OrgsBelow>0, or (b) the
> evaluator checks the PSL, gets a lower-level result for the organization
> domain, and uses the lower-risk longer domain,
> 
> Doug
> 
> 
> 
> On Wed, Apr 20, 2022 at 8:40 AM Scott Kitterman <[e-mail]>
> 
> wrote:
> > No.  We went through all this before and that's not correct.  Tree walk is
> > no worse than the PSL for private registries.  For public registries it is
> > in many cases much better.  In many cases IANA has contractual control
> > that
> > is much stronger than any management controls in the PSL.
> > 
> > There's nothing the IETF can do to prevent customer hostile registrars
> > from doing hostile things.
> > 
> > I think the fundamental error is to assume the PSL is static.  It's not.
> > 
> > In terms of the concerns you've expressed, is there any issue you see with
> > the tree walk that isn't equally a problem if the putative hostile
> > registrar asks for a change in the PSL?
> > 
> > Scott K
> > 
> > On April 20, 2022 10:56:01 AM UTC, Douglas Foster <
> > 
> > [e-mail]> wrote:
> > >This is a fundamental flaw in the design, not a problem to be fixed on a
> > >case-by-case basis.
> > >
> > >Under the tree walk, any private registry client can impersonate the
> > 
> > parent
> > 
> > >or a sibling, simply by publishing a non-org DMARC policy and then
> > >letting
> > >the tree walk proceed into the parent organization.  Yes, the parent
> > >organization can prevent this using its own DMARC policy, but it is
> > 
> > foolish
> > 
> > >to assume that all of them will.  Wherever the opportunity exists,
> > >malicious domain owners can be expected to use it. and the Michael Hammer
> > >testimony is that they have already done so when the PSL had an
> > >omissioin.
> > >
> > >Private registries are a significant complication to understanding the
> > >effectiveness of DMARC evaluation, and yet the document still does not
> > >discuss their existence or their potential security considerations.
> > >
> > >The case against the PSL has been heavy on generalities but weak on
> > >specifics.   The appropriate solution is to use DNS entries to provide a
> > >check on PSL mistakes and omissions.   When a DNS entry specifies a lower
> > >alignment point (more restrictive relaxed alignment), the evaluator
> > >should
> > >use the DNS value.   If the PSL specifies a lower alignment point, the
> > >DNS
> > >entry may be malicious.   So the evaluatror would be wise to use the more
> > >restrictive st the PSL entry for an initial message, and then make an
> > >investigate to determine if he wants to establish a local policy to trust
> > >the higher alignment point in DNS.  When the DNS is being used to
> > >validate
> > >the PSL rather than replacing it, we have alternate algorithm options
> > 
> > which
> > 
> > >are more efficient than a full tree walk.
> > >
> > >In summary, there is no good reason to discard the PSL completely, and no
> > >compelling reason to believe that DNS by itself can ever provide a
> > >sufficient solution.
> > >
> > >.Doug
> > >
> > >
> > >
> > >
> > >
> > >
> > >On Tue, Apr 19, 2022 at 11:12 PM Scott Kitterman <[e-mail]>
> > >
> > >wrote:
> > >> Thanks.
> > >> 
> > >> I think this is pretty much the same list John published before.  I
> > 
> > think
> > 
> > >> there is a little bit of outreach to do while we're working on
> > >> DMARCbis,
> > >> but
> > >> it's not a major issue.  Some of these are false positives.  As an
> > 
> > example:
> > >> gov.scot
> > >> service.gov.scot
> > >> 
> > >> Are both on the PSL.  It's true that under the new tree walk approach
> > >> other
> > >> parts of the government of Scotland could impersonate service.gov.scot,
> > >> but I
> > >> don't think it's a major risk.
> > >> 
> > >> This is part of the reason I'd like to see the WG get an early
> > 
> > assignment
> > 
> > >> from
> > >> IANA for the psd tag.  Once that's done, we (and I will work on this)
> > 
> > can
> > 
> > >> start contacting both the PSL and above PSL entities with DMARC records
> > >> about
> > >> updating them to use it.  The meantime, any lower level entity for
> > >> these
> > >> PSDs
> > >> that has a problem would be able to publish psd=n and stop it.
> > >> 
> > >> Scott K
> > >> 
> > >> On Tuesday, April 19, 2022 8:18:53 PM EDT Douglas Foster wrote:
> > >> > Scott asked for my list, so it is attached.   I walked up the tree
> > 
> > from
> > 
> > >> the
> > >> 
> > >> > private registries, then did a DNS lookup for a DMARC entry.
> > >> > 
> > >> >  Consequently, the list shows the domains with DMARC policies, at
> > >> 
> > >> whatever
> > >> 
> > >> > level, rather than the PSL entry itself.
> > >> > 
> > >> > Doug
> > >> > 
> > >> > 
> > >> > On Tue, Apr 19, 2022 at 12:00 AM Scott Kitterman <
> > 
> > [e-mail]>
> > 
> > >> > wrote:
> > >> > > On Monday, April 18, 2022 10:14:37 PM EDT Douglas Foster wrote:
> > >> > > > Concern 1
> > >> > > > Of the several thousand private registry domains listed in the
> > 
> > PSL,
> > 
> > >> 45
> > >> 
> > >> > > have
> > >> > > 
> > >> > > > DMARC policies at or above the registry point.   40 of these 45
> > >> 
> > >> specify
> > >> 
> > >> > > > relaxed alignment for both DKIM and SPF.  Upon activation of the
> > 
> > tree
> > 
> > >> > > walk,
> > >> > > 
> > >> > > > these policies will be treated as organizational domains to any
> > >> 
> > >> private
> > >> 
> > >> > > > registry clients that have not published their own psd=y policy.
> > >> > >  
> > >> > >  Because
> > >> > >  
> > >> > > > of relaxed alignment, these private registry clients will be able
> > 
> > to
> > 
> > >> > > > impersonate their siblings and parents and produce a DMARC result
> > 
> > of
> > 
> > >> > > PASS.
> > >> > > 
> > >> > > Please provide your list of ones you think might be problematic.
> > >> > > 
> > >> > > > Concern 2
> > >> > > > Since the longest current PSL entry has 5 segments, the longest
> > >> > > > organizational domain is 6 segments.   The "jump to 5" logic
> > >> > > > needs
> > >> 
> > >> to be
> > >> 
> > >> > > > changed to "jump to 6".
> > >> > > 
> > >> > > What PSL entries that are 5 long are you worried about?  When we
> > >> 
> > >> looked at
> > >> 
> > >> > > this before, 5 seemed sufficient.  Changing the number, now, isn't
> > >> > > a
> > >> 
> > >> big
> > >> 
> > >> > > deal.
> > >> > > 
> > >> > > > Concern 3
> > >> > > > The "psd=u" language is inconsistent.  Which is true?
> > >> > > > "This token indicates that this policy is not an organizational
> > >> 
> > >> domain,,
> > >> 
> > >> > > > the organizational domain is above this point"
> > >> > > > or
> > >> > > > "This token indicates no usable information, proceed with the
> > >> 
> > >> heuristic
> > >> 
> > >> > > to
> > >> > > 
> > >> > > > determine if this policy is the organizational domain"
> > >> > > 
> > >> > > It should be the latter.  If we're inconsistent, please propose
> > >> 
> > >> corrected
> > >> 
> > >> > > text.
> > >> > > 
> > >> > > Scott K
> > >> > > 
> > >> > > > Doug Foster
> > >> > > > 
> > >> > > > On Sun, Apr 17, 2022 at 4:54 PM Scott Kitterman <
> > >> 
> > >> [e-mail]>
> > >> 
> > >> > > > wrote:
> > >> > > > > I've finished going through this and also updated authheaders
> > 
> > [1]
> > 
> > >> to
> > >> 
> > >> > > > > match.  It
> > >> > > > > now has a script called dmarc-policy-find which you can used to
> > >> > > 
> > >> > > determine
> > >> > > 
> > >> > > > > the
> > >> > > > > DMARC policy to be applied for a domain.  You can use RFC 7489,
> > 
> > RFC
> > 
> > >> > > 7489 +
> > >> > > 
> > >> > > > > RFC
> > >> > > > > 9091, and DMARCbis-07.
> > >> > > > > 
> > >> > > > > It does currently cheat and assume psd=y is in the records for
> > >> 
> > >> domains
> > >> 
> > >> > > on
> > >> > > 
> > >> > > > > the
> > >> > > > > PSD DMARC registry list, since no one has actually published
> > 
> > that
> > 
> > >> yet.
> > >> 
> > >> > > > > Scott K
> > >> > > > > 
> > >> > > > > [1] https://github.com/ValiMail/authentication-headers (also on
> > >> 
> > >> pypi)
> > >> 
> > >> > > > > On Wednesday, April 6, 2022 12:27:04 PM EDT Scott Kitterman
> > 
> > wrote:
> > >> > > > > > I believe it does.
> > >> > > > > > 
> > >> > > > > > Thanks,
> > >> > > > > > 
> > >> > > > > > Scott K
> > >> > > > > > 
> > >> > > > > > On April 6, 2022 2:53:59 PM UTC, Todd Herr
> > >> > > > > 
> > >> > > > > <todd.herr=[e-mail]> wrote:
> > >> > > > > > >I believe this rev has the proposed text that was submitted
> > 
> > in
> > 
> > >> > > various
> > >> > > 
> > >> > > > > > >messages in the thread titled "*5.5.4. Publish a DMARC
> > >> > > > > > >Policy
> > >> 
> > >> for
> > >> 
> > >> > > the
> > >> > > 
> > >> > > > > > >Author Domain - dmarcbis-06"*
> > >> > > > > > >
> > >> > > > > > >On Wed, Apr 6, 2022 at 10:51 AM <[e-mail]>
> > >> 
> > >> wrote:
> > >> > > > > > >> 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-07.txt
> > >> > > > > > >>         Pages           : 62
> > >> > > > > > >>         Date            : 2022-04-06
> > >> > > > > > >> 
> > >> > > > > > >> 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-07.html
> > >> 
> > >> > > > > > >> A diff from the previous version is available at:
> > >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-dmarcbis-07
> > >> 
> > >> > > > > > >> Internet-Drafts are also available by rsync at
> > 
> > rsync.ietf.org
> > 
> > >> > > > > > >> :internet-drafts
> > >> > > > > > >> 
> > >> > > > > > >> _______________________________________________
> > >> > > > > > >> dmarc mailing list
> > >> > > > > > >> [e-mail]
> > >> > > > > > >> https://www.ietf.org/mailman/listinfo/dmarc
> > >> > > > > > 
> > >> > > > > > _______________________________________________
> > >> > > > > > dmarc mailing list
> > >> > > > > > [e-mail]
> > >> > > > > > https://www.ietf.org/mailman/listinfo/dmarc
> > >> > > > > 
> > >> > > > > _______________________________________________
> > >> > > > > dmarc mailing list
> > >> > > > > [e-mail]
> > >> > > > > https://www.ietf.org/mailman/listinfo/dmarc
> > >> > > 
> > >> > > _______________________________________________
> > >> > > dmarc mailing list
> > >> > > [e-mail]
> > >> > > https://www.ietf.org/mailman/listinfo/dmarc
> > >> 
> > >> _______________________________________________
> > >> dmarc mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/dmarc
> > 
> > _______________________________________________
> > dmarc mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dmarc