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

[Douglas Foster <[e-mail]>]

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
>