Re: [dmarc-ietf] Sibling Authentication

[Douglas Foster <[e-mail]>]

To one of Murray's questions,  below is a repost of the list that I pulled
out of DNS a long time ago - PSL entries (without internationalization)
that had a DMARC policy   Of the 45 names, a few specify strict, a few
specify relaxed, one is mixed, and most do not specify an alignment
policy.   Back when we thought this process would finish in our current
century, Scott volunteered to hunt down these domain owners prior to
publication.  It could still be done, and the problem could reoccur.  I am
all for finishing, if we can do it well.

To Murray's definition question, the sibling alignment problem occurs when
a PSL or private registry has a DMARC policy with relaxed alignment.
Call it privateregistry.com
It either does not have a PSL=Y term or the evaluator does not know to look
for the PSL=Y term.
Additionally,
client1.privateregisry.com does not have a DMARC policy (or the PSL
incorrectly fails to list the private registry)
and
client2.privateregistry.com signs with his own domain to impersonate FROM=
[e-mail]
The PSL problem and this tree walk problem are essentially the same risk..

Axiom's matter.   We have reached this point by assuming that the entire
relaxed alignment regime had to be preserved, and the only way to solve the
PSL problem was to create lesser problems.    The PSL problem primarily
matter because sibling alignment exists.  If we drop sibling alignment in
favor of vertical alignment, we solve the primary problem and the PSL
matters very little.   So the question becomes whether sibling alignment is
needed.   My data says "No".   Does anyone else have data to contribute?

We are on at least the third design.   None have been supported with data.
I have never considered any of them to be designed in a way that will be
viable, so it seemed necessary to go on record that I will be voting No
when the time comes to vote.   You can plan around me that way.

Doug

The list:

_dmarc.0emm.com,v=DMARC1; p=reject; rua=mailto:[e-mail]
_dmarc.adobeaemcloud.com,v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:
[e-mail]; ruf=mailto:[e-mail]; fo=1
_dmarc.amazonaws.com.cn,v=DMARC1; p=quarantine; pct=100; rua=mailto:
[e-mail]; ruf=mailto:[e-mail]
_dmarc.appspot.com,v=DMARC1; p=reject; rua=mailto:
[e-mail]
_dmarc.bytemark.co.uk,v=DMARC1; p=none; rua=mailto:
[e-mail]
_dmarc.cloudapps.digital,"v=DMARC1; p=reject; fo=1; rua=mailto:
[e-mail],
[e-mail];ruf=mailto:
[e-mail],
[e-mail]"
_dmarc.cloudplatform.fi,v=DMARC1; p=none
_dmarc.ddnss.de,v=DMARC1; p=reject; rua=mailto:[e-mail]; ruf=mailto:
[e-mail]; fo=1; ri=1; adkim=r; aspf=s
_dmarc.dnstrace.pro,v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s;
_dmarc.eu.org,v=DMARC1;p=none;sp=none;pct=10;rua=mailto:[e-mail]
;ruf=mailto:[e-mail]
_dmarc.fastly.net,v=DMARC1; p=quarantine; rua=mailto:
[e-mail]
_dmarc.fedoraproject.org,v=DMARC1; p=none; rua=mailto:
[e-mail]; ruf=mailto:[e-mail];
fo=0
_dmarc.funkfeuer.at,v=DMARC1; p=none
_dmarc.gateway.dev,v=DMARC1; p=reject; rua=mailto:
[e-mail]
_dmarc.gov.scot,v=DMARC1;p=none;sp=none;fo=1;rua=mailto:
[e-mail];ruf=mailto:[e-mail]
_dmarc.gov.uk
,v=DMARC1;p=reject;sp=none;np=reject;adkim=s;aspf=s;fo=1;rua=mailto:
[e-mail]
_dmarc.hosteur.com,v=DMARC1; p=none; rua=mailto:[e-mail]
_dmarc.interhostsolutions.be,v=DMARC1; p=none; rua=mailto:
[e-mail]; ruf=mailto:[e-mail];
fo=1:d:s
_dmarc.jelastic.com,v=DMARC1; p=none; rua=mailto:[e-mail]
_dmarc.lcl.dev,v=DMARC1; p=none; pct=100; rua=mailto:systems?[e-mail];
ruf=mailto:systems?[e-mail]; fo=1; ri=3600;
_dmarc.lclstage.dev,v=DMARC1; p=none; pct=100; rua=mailto:systems?
[e-mail]; ruf=mailto:systems?[e-mail]; fo=1; ri=3600;
_dmarc.linode.com,v=DMARC1; p=reject; sp=quarantine; pct=100; rua=mailto:
[e-mail]
_dmarc.magentosite.cloud,v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:
[e-mail]; ruf=mailto:[e-mail]; fo=1
_dmarc.massivegrid.com,v=DMARC1;p=none;pct=100;ri=86400;rua=mailto:
[e-mail]
_dmarc.my.id,v=DMARC1; p=quarantine; rua=mailto:[e-mail];
_dmarc.ovh.net,v=DMARC1; p=none; rua=mailto:dmarc?[e-mail];
rf=afrf; pct=100;
_dmarc.panel.gg,v=DMARC1; p=none; pct=100; rua=mailto:re????@
dmarc.postmarkapp.com; sp=none; aspf=r;
_dmarc.platform.sh,"v=DMARC1;p=none;sp=none;rua=mailto:
[e-mail],mailto:[e-mail];ruf=mailto:
[e-mail],mailto:[e-mail];fo=1"
_dmarc.prgmr.com,v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:
[e-mail]
_dmarc.pstmn.io,v=DMARC1; p=quarantine; pct=100; rua=mailto:
[e-mail]; ruf=mailto:[e-mail];
_dmarc.pythonanywhere.com,v=DMARC1; p=none; rua=mailto:
[e-mail]
_dmarc.quipelements.com,v=DMARC1;p=reject
_dmarc.render.com,v=DMARC1; p=none; pct=100; rua=mailto:re????@
dmarc.postmarkapp.com; sp=none; aspf=r;
_dmarc.rit.edu,v=DMARC1; p=none; fo=1; rua=mailto:[e-mail]; ruf=mailto:
[e-mail]; adkim=r; aspf=r; pct=100;
_dmarc.run.app,v=DMARC1; p=reject; rua=mailto:[e-mail]
_dmarc.scaleforce.net,v=DMARC1; p=quarantine; rua=mailto:
[e-mail]; ruf=mailto:[e-mail]; sp=quarantine
_dmarc.stdlib.com,v=DMARC1; p=quarantine; pct=100; rua=mailto:jacob?@
stdlib.com
_dmarc.stg.dev,v=DMARC1; p=none; pct=100; rua=mailto:systems?[e-mail];
ruf=mailto:systems?[e-mail]; fo=1; ri=3600;
_dmarc.stgstage.dev,v=DMARC1; p=none; pct=100; rua=mailto:systems?
[e-mail]; ruf=mailto:systems?[e-mail]; fo=1; ri=3600;
_dmarc.transurl.be,v=DMARC1; p=reject;
_dmarc.transurl.eu,v=DMARC1; p=reject;
_dmarc.transurl.nl,v=DMARC1; p=reject;
_dmarc.unispace.io,v=DMARC1; p=none; rua=mailto:[e-mail];
_dmarc.virtualcloud.com.br,v=DMARC1; p=none; rua=mailto:
[e-mail]; ruf=mailto:[e-mail]; rf=afrf;
sp=none; fo=0:1:d:s; pct=100; ri=86400; aspf=s
_dmarc.wafaicloud.com,v=DMARC1;p=none;pct=100;rua=mailto:
[e-mail];ruf=mailto:[e-mail]

On Thu, Jun 1, 2023 at 10:02 AM Murray S. Kucherawy <[e-mail]>
wrote:

> On Thu, Jun 1, 2023 at 4:03 AM Douglas Foster <
> [e-mail]> wrote:
>
>> I cannot support the current draft because it creates new problems
>> without sufficiently solving the old ones.
>>
>> The PSL is subject to two types of errors:
>> - Landing too high, causing False Pass on non-affiliated domains
>> - Landing too low, causing False Fail or False NoPolicy on domains that
>> are actually affiliated.
>> False Pass presents the greater threat.  While it could occur on any type
>> of non-strict alignment, the primary concern is False Pass on sibling
>> alignment.
>> [...]
>>
>
> Can you please define, or give an example of, "sibling alignment"?  My
> understanding of "sibling" in a tree structure is two or more nodes at the
> same level with a common parent.  In that sense, twitter.com and
> facebook.com are siblings.  In the DMARC environment, how could one align
> with the other?  Or is your claim that they could align if, say, ".com"
> chose to assert policy about them and they omit to assert their own?
>
> The bottom-up-first-stop tree walk attempts to solve the problem of False
>> Pass by using an algorithm that will often land too low, causing False Fail.
>>
>
> Can you give an example of this?
>
>
>> Nonetheless, it fails to solve the whole problem because evaluators are
>> still at risk from private registries that publish a DMARC policy with
>> strict alignment but without a PSD tag. The proposed tree walk has other
>> problems, because it changes an organization's relaxed alignment boundary
>> every time that a policy is added or removed.
>>
>
> And this?
>
>
>> As long as the parent-child and child-parent forms of relaxed alignment
>> are permitted, we need an explicit tagging mechanism which gives the domain
>> owner full control over alignment boundaries and eliminates uncertainty
>> about the domain owner's intent.   Parent-child and child-parent
>> authentication will be important for as long as SPF-alignment is
>> necessary.  For DKIM signatures, I am not convinced that relaxed alignment
>> should be necessary even though it has some current use because it is
>> allowed.
>>
>
> An example here would really help.
>
> -MSK, participating
>