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

[Douglas Foster <[e-mail]>]

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
>