Re: [dmarc-ietf] Next draft concerns

[Douglas Foster <[e-mail]>]

Why am I unwilling to move on?

Because I want this document to succeed and actually reduce email-borne
attacks.

Because stifling of discussion does not lead to consensus.   It does,
however, drag out the process.   For those who do not want this process to
succeed, accumulated delay may be almost as good as a win.

Because I got on this "kick" after Michael Hammer asserted personal
knowledge of a successful attack based on sibling authentication.  I did
not discard his input simply because he was not at liberty to name names.

Because I reviewed the PSL, as you could have done, and gave you a list of
domains that were vulnerable to sibling authentication attacks based on
their current configuration.   I think you intended to beg each of them to
implement a PSD policy.   How is that effort going?

Because I manage an actual mail stream, and a destructive malware attack
won't mean a client organization is damaged or destroyed, it will mean my
organization is damaged or destroyed.    I have not forgotten that when
the group was asked for mailstream data, I think about usage of DKIM
sibling authentication, you said you had no access to a mailstream source.

Because I don't know your agenda.   I am here to voice the evaluator
perspective.   What interest group do you represent?

Because a good security policy does not defend against what has happened,
it defends against what could happen.

Because  a new idea like Tree Walk does not get adopted unless people
believe the pain of transition is less than the benefit, so it needs to be
"sold".    Currently, the tree walk risk seems greater than the PSL risk,
and you don't know how to sell past that objection.   Muzzling me will not
cause millions of system administrators to do something stupid simply
because you put it into print.

Because I have learned that repeating the same points is necessary to be
heard in this group.

That's why.



On Sun, Jun 12, 2022 at 4:38 PM Scott Kitterman <[e-mail]>
wrote:

> Doug,
>
> I believe I have asked you before to provide specific examples of current
> domains with records that will cause a problem if assessed via the DMARCbis
> approach.  If there's a real problem that needs solving, then surely there
> are examples of it.  If they're none, then how about moving on.
>
> I think you're misreading the thread.
>
> Let's have an example of a real domain, with a  real DMARC record, that
> would be negatively impacted by being assessed using the DMARCbis design. I
> haven't found any I think are problematic, but if you have, I'm all ears?
>
> Scott K
>
> On June 12, 2022 8:08:13 PM UTC, Douglas Foster <
> [e-mail]> wrote:
> >Les' question has returned us to the problem of justifying the tree walk.
> > We need to document the problems with PSL, but we also need to
> demonstrate
> >that the tree walk solves those problems without creating others.
> >
> >In most cases, the tree walk and PSL will produce the same results,
> because
> >they will both find the top-most DMARC policy in a structure with neither
> a
> >private registrar nor a PSD policy.   So the justification is really
> >limited to those exceptions.
> >
> >We assume that most PSL errors will cause organization fragmentation,
> >because of identifying a private registry for XSS purposes which is not a
> >private registry for email purposes.    We also know that the current DNS
> >has no information about private registries, so if we apply the tree walk
> >to the current DNS, we may sometimes error by landing too high and causing
> >inappropriate organization consolidations.
> >
> >In the case that the tree walk stops lower than the PSL target, the most
> >secure solution is to believe the DNS policy.   This can only occur if the
> >policy has a DMARCbis token which explicitly says that a policy has the
> >Organizational Domain role.
> >
> >In the case that the tree walk stops higher than the PSL target, which do
> >we believe?    To tilt the decision in favor of the tree walk, we need a
> >token which indicates that the tree walk did not pass over an undocumented
> >private registry.   This will also require a new token on the
> >organizational domain, which is not yet defined.   I see these possible
> >informational signals:
> >- No private registries or organizational boundaries underneath this
> >organizational domain.
> >- All sub-organizations underneath this organizational domain are also
> >documented with organizational domain DMARC policies.
> >- A private registry exists underneath this organizational domain and is
> >documented with a PSD policy.
> >
> >This means that for either exception, a new DMARCbis token is required on
> >the organizational domain.   Consequently, a domain which has not
> published
> >an applicable DMARCbis token should be evaluated using the PSL, and a
> >domain which has published a sufficient set of DMARCbis tokens should be
> >evaluated using the Tree Walk.   This approach also satisfies our other
> >requirement, which is that the tree walk requires an organizational domain
> >policy.
> >
> >I know this is discouraging, because John's original hope was to avoid
> >placing a change requirement on domain owners, but I do not see that it
> can
> >be helped.
> >
> >Doug Foster
> >
> >
> >On Thu, Jun 9, 2022 at 3:18 PM Les Barstow <lbarstow=
> >[e-mail]> wrote:
> >
> >> Thank you for the history fill-in, John. That does at least explain why
> >> we’re here and not somewhere else.
> >>
> >>
> >>
> >> I will respectfully disagree that the “psd” tree walk standard is
> >> well-defined based on the remainder of my response – that the use of the
> >> “psd” TLA for the tag is unfortunate/misleading and that more
> specificity
> >> is desirable. But having the alternatives eliminated at least gets me to
> >> “it should be in this spec”.
> >>
> >>
> >>
> >> On Thursday, June 9, 2022, John Levine wrote:
> >>
> >>
> >>
> >> It appears that Les Barstow  <[e-mail]> said:
> >>
> >> >-=-=-=-=-=-
> >>
> >> >[Strong opinion follows]
> >>
> >> >
> >>
> >> >IMO [from April], determination of a DMARC authority boundary
> (registrar, PSD+1, private registry (+1), or internal subdomain
> >>
> >> >boundary) should really be done outside of the DMARC standard
> altogether – a separate DNS lookup not dependent or centered
> >>
> >> >around DMARC, and one flexible enough to respond with indications of
> various levels of authority. It is useful for
> >>
> >> >decentralizing other queries beyond just DMARC (e.g. determining an
> appropriate WHOIS TLD for lookup). Unfortunately, here we
> >>
> >> >are at draft 8 of the new DMARC standard and we have nothing to use as
> a sidecar mechanism.
> >>
> >>
> >>
> >> The DBOUND working group already tried and failed to come up with a
> >>
> >> general way to publish DNS boundaries, so we're not going back there.
> >>
> >>
> >>
> >> >Is there a driving need to have this in the standard NOW?
> >>
> >>
> >>
> >> Yes, of course. The point of writing a standard is to tell people what
> >>
> >> to do to interoperate. The current underspecified fudge which winks at
> >>
> >> the PSL has well known issues since, among other things, the people
> >>
> >> who run the PSL have made it quite clear that it's not designed to
> >>
> >> make DMARC work. It contains plenty of entries which make sense for
> >>
> >> web cookies but not for DMARC.
> >>
> >>
> >>
> >> The tree walk is well specified and doesn't depend on third parties
> >>
> >> who aren't interested in what we want or need.
> >>
> >>
> >>
> >> R's,
> >>
> >> John
> >>
> >> _______________________________________________
> >> dmarc mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dmarc
> >>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>