Subject: [dmarc-ietf] Organizational Alignment Options

From: Scott Kitterman <[email-masked]>
Date: Tue, 02 Nov 2021 10:54:51 -0400

I've been thinking about options for how to determine if message identifiers 
are aligned.  Based on recent feedback, I've discarded mfrom/d= domain equals 
or is a subdomain of from domain as a feasible idea.  Here's what I'm left 
with:

1.  No change.  For relaxed alignment, as long as there is a common org 
domain, it is aligned.  The depends on the PSL being complete and correct and 
it's known to be neither, but it's not clear how much that matters in 
practice.

2.  Still use common org domain based on PSL, but exclude the private names 
section of the PSL.  This would address one known source of error and should 
be largely backward compatible.  It would require updates to only query part 
of the PSL, since (at least the libraries I've checked) currently making this 
distinction is not generally supported.

3.  Common parent domain with DMARC policy.  For cases like those recently 
discussed where from is a subdomain of the d= domain, the d= domain still has 
a DMARC policy, right?  Assuming that's correct (and it is an assumption that 
should be validated, not one we should just make) then, except where PSDs are 
publishing a DMARC record, then this will get the same result.  For all of the 
current PSD records, gov, gov.uk, police.uk, and mil, these are private use 
PSDs where cross-domain forgery among registrants isn't a concern.  Similarly, 
controlled public use PSDs such as bank and insurance shouldn't have this 
problem either.

4.  Common parent domain not marked PSD.  We could add a new tag to the DMARC 
records for PSDs to indicate it's a PSD, so it's record shouldn't be used for 
alignment.  Getting this added to the literal handful of PSD records that 
exist and specifying it should be used going forward is doable.  To implement 
this approach should produce identical (modulo PSL errors and omissions) 
results to the RFC 7489 approach.  It seems like we've decided to trust that 
ICANN and ccTLD operators will effectively manage publication of PSL records 
for policy discovery, so this leverages that trust to simplify alignment while 
maintaining backward compatibility.

I like the even numbered ones best.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 2 Nov 2021 22:09:04 -0400

>maintaining backward compatibility.

This is a much better worked out version of my DNS tree climbing proposal.  I like it too.

R's,
John

PS: Just out of nosiness, what PSD records exist now?

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 03 Nov 2021 03:04:38 +0000

>PS: Just out of nosiness, what PSD records exist now?

Thanks.  As far as I know, .gov, .mil, .gov.uk, and .police.uk.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 3 Nov 2021 10:58:34 +0100

> Thanks.  As far as I know, .gov, .mil, .gov.uk, and .police.uk.

Hm... but PSDs don't seem to gain any extras by letting receivers know they're 
a PSD, do they?

For a similar extension, subdomains could indicate their Organizational Domain. 
  That's in case a subdomain wants to override its OD policy, for example to 
add themselves to the feedback reporting addresses.  A subdomain can still be 
interested in letting receivers know what is the actual OD, for example if they 
want the receiver to find their BIMI certificate.  This sounds similar to SPF's 
include or redirect keywords.  The receiver would have to load yet another TXT 
record and somehow produce a merged policy.

OTOH, a subdomain that wants to distinguish itself from its OD wouldn't publish 
any reference to the latter.  They can already do this.

jm2c
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Wed, 3 Nov 2021 06:53:07 -0400

The tree walk should address whether we do anything for domain-part names
that are resource record names rather than DNS domains.   Such names cannot
be given a _dmarc. subdomain, so they cannot be given an exact-match DMARC
policy.

Always doing a one-level walk from the bottom would ensure that they can
have a policy at the closest possible layer.

On Tue, Nov 2, 2021, 10:09 PM John Levine <[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 03 Nov 2021 14:15:31 +0000

>Hm... but PSDs don't seem to gain any extras by letting receivers know they're 
snip

Recall from the policy discovery discussion that PSDs are regulated by ICANN or their ccTLD operators.  They aren't free to publish whatever and whenever they want.  Trusting them to manage which PSDs should publish records also implies that the records are appropriate.  As an example, RFC 9091 suggests aggregate reports are okay at the PSD level, but failure reports are not.  This would be another thing we'd have to document in security considerations to help them get it right.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 03 Nov 2021 14:18:51 +0000

Would you please provide a specific example where this would be needed?  I'm not sure I understand what you mean by resource record names that is not a DNS domain.

Scott K

---

From: Douglas Foster <[email-masked]>
Date: Wed, 3 Nov 2021 10:49:03 -0400

Type=A, name=host1, domain=a.b.c.d e.f.example.com

Assuming that we will be walking the top n levels, it is only an issue on
long domain names.

On Wed, Nov 3, 2021, 10:19 AM Scott Kitterman <[email-masked]> wrote:

> Would you please provide a specific example where this would be needed?
> I'm not sure I understand what you mean by resource record names that is
> not a DNS domain.
>
> Scott K
>
> On November 3, 2021 10:53:07 AM UTC, Douglas Foster <
> [email-masked]> wrote:
> >> >records for PSDs to indicate it's a PSD, so it's record shouldn't be
> used
> >> for
> >> >for policy discovery, so this leverages that trust to simplify
> alignment
> >> while

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 03 Nov 2021 15:07:42 +0000

That's the same thing as host1.a.b.c.d.e.f.example.com, right?

I don't think there's any special case needed to find a common parent.

Scott K

---

From: Douglas Foster <[email-masked]>
Date: Wed, 3 Nov 2021 11:42:44 -0400

Correct, but you cannot query _dmarc.host1.domain because host1 is not a
DNS domain, even though it can be a mail sender and receiver

I wish DMARCv1 had not created this anomaly by using subdomains, but it is
too late to fix.

Do we leave these as anomalies, or give them the best available DMARC
participation by ensuring that their parent policy is checked?

On Wed, Nov 3, 2021, 11:08 AM Scott Kitterman <[email-masked]> wrote:

> On November 3, 2021 2:49:03 PM UTC, Douglas Foster <
> >> >> >4.  Common parent domain not marked PSD.  We could add a new tag to
> the
> >> >> DMARC
> >> >> >results to the RFC 7489 approach.  It seems like we've decided to
> trust
> >> >> that

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 03 Nov 2021 11:48:53 -0400

Sure you can.  In your example host1 has an a record.

Scott K

On Wednesday, November 3, 2021 11:42:44 AM EDT Douglas Foster wrote:
> > >On Wed, Nov 3, 2021, 10:19 AM Scott Kitterman <[email-masked]>
> > 
> > wrote:
> > >> >The tree walk should address whether we do anything for domain-part
> > 
> > names
> > 
> > >> >that are resource record names rather than DNS domains.   Such names
> > >> 
> > >> cannot
> > >> 
> > >> >be given a _dmarc. subdomain, so they cannot be given an exact-match
> > 
> > DMARC
> > 
> > >> >policy.
> > >> >
> > >> >Always doing a one-level walk from the bottom would ensure that they
> > 
> > can
> > 
> > >> >> >alignment.  Getting this added to the literal handful of PSD
> > >> >> >records
> > >> 
> > >> that
> > >> 
> > >> >> >exist and specifying it should be used going forward is doable.  To
> > >> >> 
> > >> >> implement
> > >> >> 
> > >> >> >this approach should produce identical (modulo PSL errors and
> > >> 
> > >> omissions)
> > >> 
> > >> >> >ICANN and ccTLD operators will effectively manage publication of
> > >> >> >PSL
> > >> >> 
> > >> >> records
> > >> >>

---

From: tjw ietf <[email-masked]>
Date: Wed, 3 Nov 2021 11:54:24 -0400

Been thinking on this - #4 is great option. 

Sent from my iPhone

> On Nov 3, 2021, at 11:49, Scott Kitterman <[email-masked]> wrote:
>

---

From: "John Levine" <[email-masked]>
Date: 3 Nov 2021 13:22:59 -0400

It appears that Douglas Foster  <[email-masked]> said:
>-=-=-=-=-=-

Sorry, but I also have no idea what you're talking about. Any mail
domain is a DNS domain because you have to use the DNS to publish an
MX or A or AAAA record.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Wed, 3 Nov 2021 22:52:40 -0400

This was more of an issue before your tree-walk took hold.  Now it is an
edge case.   But I think it deserves explicit consideration.   I am sorry
that it seems so obscure

My terminology:

An email domain-part that is a "DNS Domain" is associated resource records
having an empty host portion, so that the domain-part name matches the name
of the containing DNS directory structure.  Gmail.com is an example of an
email domain-part that is also a DNS domain.

An email domain-part that is a "host record" is associated with resource
records that have a non-empty host portion, so that the name does not match
the containing DNS directory structure.

Either type of record can publish MX, A, SPF TXT, and DKIM TXT records, but
only the empty host-portion names can have a corresponding entry in a
"_dmarc." subdomain

(I am open to improved vocabulary suggestions.   This is my best attempt.)

Explaining the concern:
With DMARCv1, email addresses which use "host record" domain-parts have
only one possible policy match, the SP policy of the organizational
policy.   It seemed to me that every valid domain-part should have two
protection options, and the only way to achieve this would be to do a
one-level tree walk to find the parent,.

With normal DNS queries, we cannot determine whether the host portion of a
resource record is empty or not, so there does not seem to be a way to
specify conditional logic.  A one-level tree walk ensures that every name
has at least one low-level policy option as well as an organizational
policy option.

How the constrained tree walk minimizes the problem:

The proposed tree walk model says to initially look for a DMARC policy that
exactly matches the email address domain-part.   If this fails and the
address has many segments, jump to level five and move up until a policy is
found or a termination signal is found (PSL list match or "I'm a PSL" in
DNS or something else.)   This covers names with up to 6 segments.

But what about names with more than 6 segments that are also "host record"
names?   Such addresses are unusual, but they are not invalid, so they
deserve a fair playing field, and I think that should include a granular
DMARC policy.   Thus, my preference for a one-level tree walking before
jumping across any levels.

I hope this at least clarifies the concern.

Doug Foster

---

From: Douglas Foster <[email-masked]>
Date: Wed, 3 Nov 2021 23:09:37 -0400

Ale asks:

Hm... but PSDs don't seem to gain any extras by letting receivers know
they're
a PSD, do they?

I think they do.   They get the benefits of name protection which DMARC
previously afforded only to organizational domains and subdomains, which I
would expect them to consider very valuable.   While the publicsuffix.org
provides some protection, I would think they should prefer transferring
control of their status from the volunteers to themselves.

"I am a PSD means" four things:

1. "If you see a message with an SMTP address that uses my PSD name, it is
fraudulent and should be blocked."

2. "If you see a message with a FROM header that uses my PSD name, it is
fraudulent and should be blocked."

3. "If you see a DKIM signature that uses my PSD name, it will not verify
because the public key will be missing, but it is not merely unverified
material to ignore, it is positive evidence of a fraud attempt."

4. "If you are doing DMARC alignment testing, don't match on my PSD name,
 You are not looking at an organization record."

As an evaluator, all of this would be pretty valuable information to me.

The first three flags are useful in other contexts, which is why I proposed
four independent flags.   Nobody seemed to grasp that idea, so Scott has
simplified my idea down to a single flag serving a single purpose.

A related question is whether there is any incentive for malicious use of
the "I'm a PSD" flag by entities that are not actually PSDs.   Since the
only effect of this flag is to cause mail to be blocked, I do not see any
such incentive, so I do not see any risk.

This assumption holds as long as the flag is only used for email filtering
purposes.    If the HTML Cookie people want to use DNS to replace their
PSL, they need to use their own flags and evaluate their own vulnerability
to malicious use.  I worry that having a character flag ("I am a PSD")
instead of a feature flag ("I never send mail") will increase the risk of
unplanned uses which will then create unexpected opportunities for
malicious use.

Based on something that was said a long time ago, I thought the real
obstacle would be that PSDs will not cooperate.   Scott believes that the
cooperation problem is solvable, so it seems like a viable option.

Doug Foster

On Wed, Nov 3, 2021 at 5:59 AM Alessandro Vesely <[email-masked]> wrote:

> the DMARC
> used for
> trust that
> alignment while

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 04 Nov 2021 04:43:52 +0000

Why.  

Walk one, jump to five, and then walk up adds complexity and matches no current behavior.

Complexity for complexities sake is a bad idea.  Has anyone posted to this list that they are having an actual problem that this would solve?

Also, it usually results in  clearer communication when you use the terminology that other people use instead of making up your own.  You're making distinctions that don't exist.  In example.com, example is the "host part" and it's hosts all the way down.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 4 Nov 2021 09:33:35 +0100

On Thu 04/Nov/2021 04:09:37 +0100 Douglas Foster wrote:
> <http://publicsuffix.org> provides some protection, I would think they should 
> prefer transferring control of their status from the volunteers to themselves.
> 
> 1. "If you see a message with an SMTP address that uses my PSD name, it is  fraudulent and should be blocked."
> 
> 2. "If you see a message with a FROM header that uses my PSD name, it is fraudulent and should be blocked."
> 
> 3. "If you see a DKIM signature that uses my PSD name, it will not verify  because the public key will be missing, but it is not merely unverified  material to ignore, it is positive evidence of a fraud attempt."
> 
> 4. "If you are doing DMARC alignment testing, don't match on my PSD name,   You  are not looking at an organization record."

I agree those four make for a commendable behavior, but they are not really 
incentives.  IOW, lazy PSD might take years to comply.

> A related question is whether there is any incentive for malicious use of the 
> "I'm a PSD" flag by entities that are not actually PSDs.   Since the only 
> effect of this flag is to cause mail to be blocked, I do not see any such 
> incentive, so I do not see any risk.

I do, because John reported a link to the PSL wiki where they complain of ISPs 
striving to get on the PSL.

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Thu, 4 Nov 2021 06:54:24 -0400

It would be helpful to understand why people want to climb into the
publicsuffix.org list.    My guess:   An ISP, such as "ISP.TLD" allows
customers to create websites under their parent.   They need to be able to
indicate that website JohnSmith.ISP.TLD is independent of website
IvanWatson.ISP.TLD, and therefore cross-site scripting defenses should
treat them as two organizations rather than one.    This scenario needs a
flag that says "No alignment for XSS purposes", and the set of names that
need that flag may be very different from the set of names that need a
DMARC non-alignment flag.    So a set of feature-specific DNS flags will
indeed be a better long-term design than a simple "I'm a PSL" flag.

I can't answer whether PSLs will cooperate by publishing DNS entries.   My
original suggestion was to specify the flag syntax in the RFC, so that
deployment negotiations can begin, while recommending that implementers use
both.   For the same reason that I did not see a threat risk, I would place
greater trust in the DNS entry when it is present, so I would check DNS
first.  But I would also check the publicsuffix.org list to handle the
problem of DNS non-participation.

Can someone explain the private/public distinction in the PSL list?   What
does the distinction mean as it relates to the four email-related
attributes that I have listed?

Doug

On Thu, Nov 4, 2021 at 4:34 AM Alessandro Vesely <[email-masked]> wrote:

> > 3. "If you see a DKIM signature that uses my PSD name, it will not
> verify  because the public key will be missing, but it is not merely
> unverified  material to ignore, it is positive evidence of a fraud attempt."
> >
> > 4. "If you are doing DMARC alignment testing, don't match on my PSD
> name,   You  are not looking at an organization record."
>
>

---

From: Tobias Herkula <[email-masked]>
Date: Thu, 4 Nov 2021 13:19:48 +0000

As an entity you want to be on the PSL to declare an organizational boundary, and usage is now for Cookies, Certificates, Domain Reputation and most likely a longer list of more obscure individual use cases. So most of the time a DNS-RR on a DNS label that states “I’m a PSL” is the use-case that would be needed. The Problem that comes with a simple DNS-RR is, that it’s not possible anymore to discern between a PRIVATE decision to be a PSL and a PUBLIC (ICANN/IANA contract obligation) decision to be a PSL. And that would make it much harder to tackle malicious intent. For example:

_psl.com. IN TXT “true” == This is fine, and therefore for any first DNS label below “.com.” it would be clear to others that there is an organizational boundary between “example.com” and “domain.com”.

But what happens if we suddenly encounter:

_psl.example.com. IN TXT “true” == This is not fine as there is no way to know if “example.com” belongs to the same legal entity as “.com”.

The publicsuffic.org list provides a way to transport Registry policies about what DNS labels can be registered in flat format, if that needs to move to the DNS we would need a BI-directional solution similar to DNSSEC to make it “impossible” to fake such records.

Why?

Especially for Email, and that is what DMARC cares for, a Malicious Actor could use a single domain and generate a PSL DNS-RR and then he can use every subdomain of this domain to spam around with a different SPF/DKIM/DMARC setting, and only manual intervention can group all these mails together by the real org-domain (responsible entity).

Could someone explain why wee need a complex policy discovery algorithm? As from my perspective there are 2 places I would look for a DMARC policy right now, thats the 5322.From Domain at-hand and the org-domain of the 5322.From domain and for this, with the help of the PSL, that would be 2 DNS requests, do I miss a very important use case for DMARC that is not solved by these 2 querys?

Von: dmarc <[email-masked]> Im Auftrag von Douglas Foster
Gesendet: Donnerstag, 4. November 2021 11:54
An: Alessandro Vesely <[email-masked]>
Cc: IETF DMARC WG <[email-masked]>
Betreff: Re: [dmarc-ietf] Organizational Alignment Options

It would be helpful to understand why people want to climb into the publicsuffix.org<http://publicsuffix.org> list.    My guess:   An ISP, such as "ISP.TLD" allows customers to create websites under their parent.   They need to be able to indicate that website JohnSmith.ISP.TLD is independent of website IvanWatson.ISP.TLD, and therefore cross-site scripting defenses should treat them as two organizations rather than one.    This scenario needs a flag that says "No alignment for XSS purposes", and the set of names that need that flag may be very different from the set of names that need a DMARC non-alignment flag.    So a set of feature-specific DNS flags will indeed be a better long-term design than a simple "I'm a PSL" flag.

I can't answer whether PSLs will cooperate by publishing DNS entries.   My original suggestion was to specify the flag syntax in the RFC, so that deployment negotiations can begin, while recommending that implementers use both.   For the same reason that I did not see a threat risk, I would place greater trust in the DNS entry when it is present, so I would check DNS first.  But I would also check the publicsuffix.org<http://publicsuffix.org> list to handle the problem of DNS non-participation.

Can someone explain the private/public distinction in the PSL list?   What does the distinction mean as it relates to the four email-related attributes that I have listed?

Doug

On Thu, Nov 4, 2021 at 4:34 AM Alessandro Vesely <[email-masked]<mailto:[email-masked]>> wrote:
On Thu 04/Nov/2021 04:09:37 +0100 Douglas Foster wrote:
> would expect them to consider very valuable.   While the publicsuffix.org<http://publicsuffix.org>

Best
Ale
--

_______________________________________________
dmarc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmarc

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 4 Nov 2021 09:37:41 -0400

> problem of DNS non-participation.
As a DNS Person, I always prefer a DNS answer, especially if that answer is
signed with DNSSEC.

But DNSSEC deployment is still not as straightforward and non-dns folks
still argue about deploying it.

---

From: "John Levine" <[email-masked]>
Date: 4 Nov 2021 10:17:23 -0400

It appears that Tobias Herkula  <[email-masked]> said:
>-=-=-=-=-=-
>As an entity you want to be on the PSL to declare an organizational boundary, and usage is now for Cookies, Certificates, Domain Reputation and most likely a longer list of
>more obscure individual use cases. So most of the time a DNS-RR on a DNS label that states “I’m a PSL” is the use-case that would be needed. The Problem that comes
>with a simple DNS-RR is, that it’s not possible anymore to discern between a PRIVATE decision to be a PSL and a PUBLIC (ICANN/IANA contract obligation) decision to be a
>PSL. And that would make it much harder to tackle malicious intent. For example: ...

In the DBOUND working group we had a couple of worked out proposals for publishing boundary info in the DNS,
including one of mine, which lets you find the boundary above any domain name with one or two lookups,
using wildcards so you don't have to put a tag on every name.

Code here, with a link to the spec:

https://github.com/jrlevine/bound

R's,
John

PS: I still think Scott's treewalk is a better option for DMARC.

---

From: Douglas Foster <[email-masked]>
Date: Thu, 4 Nov 2021 21:11:02 -0400

I need some clarification.

Threat risk
---------------
You confirmed that the PSL has many potential uses, which confirmed my
suspicions.  But your conclusions are different.  I have been working from
the assumption that "PSL=TRUE" is equivalent to  "DENY=(feature1, feature2,
feature3, etc).   I don't see any benefit to an attacker from disabling an
Internet feature on his own domain name.

- For email, PSL=TRUE means we are denying that this name can be used for
DMARC alignment (or any other email purpose.)  This increases the
likelihood that email will be rejected.

- For XSS, PSL=TRUE means we are denying that this name can be used for
website alignment.   This increases the likelihood that web requests will
be blocked as dangerous.

- For certificates, PSL=TRUE means we are denying that this name can be
used to issue certificates.   This increases the likelihood that fraudulent
certificates will be blocked, rather than warning the user and allowing him
to proceed.

The organization always begins at the first segment down the tree which is
not a PSL.   So it is not a meaningful statement to ask whether two PSLs
belong to the same organization.

Complexity
---------------
You said that a single PSL=TRUE is all that we need.    I infer that all of
these features are likely to have different scope, which is why some people
want onto the publicsuffix.org list even though we don't want them listed
for DMARC purposes.    To implement multiple scopes, you need a scope
selector that can produce multiple results.   So I need help understanding
why PSL=TRUE would be preferable to DENY=<featurelist>.

Multiple Policies
----------------------
I support multiple DMARC policies because I believe it will increase the
likelihood that some portion of the organization will feel free to publish
p=reject and/or sp=reject, even if the organization-level policy is trapped
at p=none, sp=none.   The value of multiple policy layers increases with
the complexity of the organization.   As discussed in this forum, the
decision-making and control structure of universities can be complex, so
multiple policies allows an implementation which reflects that complexity.

The tree walk stops when a policy is found.   Given the apparently flat
nature of most email addresses, and the other complexities of email
filtering, I don't see that DNS lookups are a significant design
consideration.

Doug Foster

On Thu, Nov 4, 2021 at 9:19 AM Tobias Herkula <[email-masked]>
wrote:

> As an entity you want to be on the PSL to declare an organizational
> boundary, and usage is now for Cookies, Certificates, Domain Reputation and
> most likely a longer list of more obscure individual use cases. So most of
> the time a DNS-RR on a DNS label that states “I’m a PSL” is the use-case
> that would be needed. The Problem that comes with a simple DNS-RR is, that
> it’s not possible anymore to discern between a PRIVATE decision to be a PSL
> and a PUBLIC (ICANN/IANA contract obligation) decision to be a PSL. And
> that would make it much harder to tackle malicious intent. For example:
>
>
>
> _psl.com. IN TXT “true” == This is fine, and therefore for any first DNS
> label below “.com.” it would be clear to others that there is an
> organizational boundary between “example.com” and “domain.com”.
>
>
>
> _psl.example.com. IN TXT “true” == This is not fine as there is no way to
> know if “example.com” belongs to the same legal entity as “.com”.
>
>
>
> The publicsuffic.org list provides a way to transport Registry policies
> about what DNS labels can be registered in flat format, if that needs to
> move to the DNS we would need a BI-directional solution similar to DNSSEC
> to make it “impossible” to fake such records.
>
>
>
> Why?
>
>
>
> Especially for Email, and that is what DMARC cares for, a Malicious Actor
> could use a single domain and generate a PSL DNS-RR and then he can use
> every subdomain of this domain to spam around with a different
> SPF/DKIM/DMARC setting, and only manual intervention can group all these
> mails together by the real org-domain (responsible entity).
>
>
>
> Could someone explain why wee need a complex policy discovery algorithm?
> As from my perspective there are 2 places I would look for a DMARC policy
> right now, thats the 5322.From Domain at-hand and the org-domain of the
> 5322.From domain and for this, with the help of the PSL, that would be 2
> DNS requests, do I miss a very important use case for DMARC that is not
> solved by these 2 querys?
>
>
>
> *Von:* dmarc <[email-masked]> *Im Auftrag von *Douglas Foster
> *Gesendet:* Donnerstag, 4. November 2021 11:54
> *An:* Alessandro Vesely <[email-masked]>
> *Cc:* IETF DMARC WG <[email-masked]>
> *Betreff:* Re: [dmarc-ietf] Organizational Alignment Options
>
>
>

---

From: Tobias Herkula <[email-masked]>
Date: Fri, 5 Nov 2021 14:59:16 +0000

Threat risk: I totally agree the ORG begins with the first label that is not considered to be a PSD, but at least I want to know if that decision is based on contractual obligations from ICANN/IANA or only a business decision by an entity with a very different legal status, compared to the other. And here a DNS based solution would need to be able to transport that information. So, a rectification that DMARC shall only consider the PUBLIC part of the PSL would be enough and easier for most entities.

Complexity: I believe they all are in the same SCOPE as the requirement in all cases is to derive the ORG Domain from any given Domain, because that is essentially the boundary between them, if a PSD for it’s own want to enforce a policy to all it’s ORGs then I would put that under OUT-OF-SCOPE of the DMARC standard, as there are other way’s to enforce the existence of DNS records for a Domain, especially in such a case, because it shall be part of the ORG domain ownership contract, it’s a business decision for a PSD to have this, so let them solve that on the business level. We should not try to solve issues that are not really existing in the first place, or at least not by methods that are introducing new problems.

Multiple Policies: I also support “multiple” policies, perhaps I’m stricter in thinking 2 are enough. Because if the ORG is big, a part of that ORG can publish the policy on the 5322.From Domain, and if there is no policy on that level a receiver will check the ORGs policy. No “real” Tree-Walk needed, as the PSL allows a fast method to determine the ORG-Doman and we end up in 2 requests.

It's hard for me right now to come up with a sensible reason why I would want to have policies on every level in the DNS, especially below an ORG-domain, as nobody outside of that ORG-domain knows what structure is behind these sub-labels.

5322.From: [email-masked]<mailto:[email-masked]> -> first look for _dmarc.a.b.c.d.example, if NXDOMAIN lookup _dmarc.d.example, if NXDOMAIN -> no policy

I don’t understand why I should also look for _dmarc.b.c.d.example and _dmarc.c.d.example, especially in the context of a very large ORG the responsible entity at a.b.c.d.example is fine with his “local” policy and most likely he has no control over b.c.d.example or higher up the tree, and for the case that he have to send via [email-masked]<mailto:[email-masked]> then the ORG decided already that they want to have control over every mail stream anyway and therefore have a central entity to control this behavior as well.

Von: dmarc <[email-masked]> Im Auftrag von Douglas Foster
Gesendet: Freitag, 5. November 2021 02:11
An: IETF DMARC WG <[email-masked]>
Betreff: Re: [dmarc-ietf] Organizational Alignment Options

Threat risk
---------------
You confirmed that the PSL has many potential uses, which confirmed my suspicions.  But your conclusions are different.  I have been working from the assumption that "PSL=TRUE" is equivalent to  "DENY=(feature1, feature2, feature3, etc).   I don't see any benefit to an attacker from disabling an Internet feature on his own domain name.

- For email, PSL=TRUE means we are denying that this name can be used for DMARC alignment (or any other email purpose.)  This increases the likelihood that email will be rejected.

- For XSS, PSL=TRUE means we are denying that this name can be used for website alignment.   This increases the likelihood that web requests will be blocked as dangerous.

- For certificates, PSL=TRUE means we are denying that this name can be used to issue certificates.   This increases the likelihood that fraudulent certificates will be blocked, rather than warning the user and allowing him to proceed.

The organization always begins at the first segment down the tree which is not a PSL.   So it is not a meaningful statement to ask whether two PSLs belong to the same organization.

Complexity
---------------
You said that a single PSL=TRUE is all that we need.    I infer that all of these features are likely to have different scope, which is why some people want onto the publicsuffix.org<http://publicsuffix.org> list even though we don't want them listed for DMARC purposes.    To implement multiple scopes, you need a scope selector that can produce multiple results.   So I need help understanding why PSL=TRUE would be preferable to DENY=<featurelist>.

Multiple Policies
----------------------
I support multiple DMARC policies because I believe it will increase the likelihood that some portion of the organization will feel free to publish p=reject and/or sp=reject, even if the organization-level policy is trapped at p=none, sp=none.   The value of multiple policy layers increases with the complexity of the organization.   As discussed in this forum, the decision-making and control structure of universities can be complex, so multiple policies allows an implementation which reflects that complexity.

The tree walk stops when a policy is found.   Given the apparently flat nature of most email addresses, and the other complexities of email filtering, I don't see that DNS lookups are a significant design consideration.

Doug Foster

On Thu, Nov 4, 2021 at 9:19 AM Tobias Herkula <[email-masked]<mailto:[email-masked]>> wrote:
As an entity you want to be on the PSL to declare an organizational boundary, and usage is now for Cookies, Certificates, Domain Reputation and most likely a longer list of more obscure individual use cases. So most of the time a DNS-RR on a DNS label that states “I’m a PSL” is the use-case that would be needed. The Problem that comes with a simple DNS-RR is, that it’s not possible anymore to discern between a PRIVATE decision to be a PSL and a PUBLIC (ICANN/IANA contract obligation) decision to be a PSL. And that would make it much harder to tackle malicious intent. For example:

_psl.com<http://psl.com>. IN TXT “true” == This is fine, and therefore for any first DNS label below “.com.” it would be clear to others that there is an organizational boundary between “example.com<http://example.com>” and “domain.com<http://domain.com>”.

_psl.example.com<http://psl.example.com>. IN TXT “true” == This is not fine as there is no way to know if “example.com<http://example.com>” belongs to the same legal entity as “.com”.

The publicsuffic.org<http://publicsuffic.org> list provides a way to transport Registry policies about what DNS labels can be registered in flat format, if that needs to move to the DNS we would need a BI-directional solution similar to DNSSEC to make it “impossible” to fake such records.

Why?

Von: dmarc <[email-masked]<mailto:[email-masked]>> Im Auftrag von Douglas Foster
Gesendet: Donnerstag, 4. November 2021 11:54
An: Alessandro Vesely <[email-masked]<mailto:[email-masked]>>
Cc: IETF DMARC WG <[email-masked]<mailto:[email-masked]>>
Betreff: Re: [dmarc-ietf] Organizational Alignment Options

Doug

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 5 Nov 2021 13:57:52 -0400

It appears that Tobias Herkula  <[email-masked]> said:
>-=-=-=-=-=-
>Threat risk: I totally agree the ORG begins with the first label that is not considered to be a PSD, but at least I want to know if that
>decision is based on contractual obligations from ICANN/IANA or only a business decision by an entity with a very different legal status,
>compared to the other. And here a DNS based solution would need to be able to transport that information. So, a rectification that DMARC
>shall only consider the PUBLIC part of the PSL would be enough and easier for most entities.

If you think the public part of the PSL is "contractual obligations
from ICANN/IANA" I have bad news for you. That is not even sort of
what it is. It's a combination of info from the domain operators and
guesses by the PSL maintainers, with a lot of references to Wikipedia.
I know of a lot of entries that are missing, like city 3LDs in Canada.
Even for TLDs that have ICANN contracts, there are a lot of entries
unrelated to anything in the contract such as the 90 2LDs in .aero
that the PSL includes.

It also has a lot of stale data. I like this comment:

// TODO: Check for updates (expected to be phased out around Q1/2009)

The PSL has no way to describe vanity TLDs where every name
belongs to the same entity. They are listed as regular TLDs like .com
but that isn't correct.

The tree walk allows the domain holder to publish its own policy about what its
org domain, if any, is.  That matches the rest of DMARC.

R's,
John

---

From: Tobias Herkula <[email-masked]>
Date: Fri, 5 Nov 2021 18:03:49 +0000

I'm aware of that, to be more explicit about my meaning. At least I currently believe (I don't know) that there is a difference in buying the domain "mydomain.example" under the assumption that .example is a gTLD, sTLD or ccTLD in comparison of buying a domain from ME, like "harharhar.mydomain.example".

-----Ursprüngliche Nachricht-----
Von: John Levine <[email-masked]> 
Gesendet: Freitag, 5. November 2021 18:58
An: [email-masked]
Cc: Tobias Herkula <[email-masked]>
Betreff: Re: [dmarc-ietf] Organizational Alignment Options

It appears that Tobias Herkula  <[email-masked]> said:
>-=-=-=-=-=-
>Threat risk: I totally agree the ORG begins with the first label that 
>is not considered to be a PSD, but at least I want to know if that 
>decision is based on contractual obligations from ICANN/IANA or only a 
>business decision by an entity with a very different legal status, compared to the other. And here a DNS based solution would need to be able to transport that information. So, a rectification that DMARC shall only consider the PUBLIC part of the PSL would be enough and easier for most entities.

If you think the public part of the PSL is "contractual obligations from ICANN/IANA" I have bad news for you. That is not even sort of what it is. It's a combination of info from the domain operators and guesses by the PSL maintainers, with a lot of references to Wikipedia.
I know of a lot of entries that are missing, like city 3LDs in Canada.
Even for TLDs that have ICANN contracts, there are a lot of entries unrelated to anything in the contract such as the 90 2LDs in .aero that the PSL includes.

The PSL has no way to describe vanity TLDs where every name belongs to the same entity. They are listed as regular TLDs like .com but that isn't correct.

The tree walk allows the domain holder to publish its own policy about what its org domain, if any, is.  That matches the rest of DMARC.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 5 Nov 2021 14:22:47 -0400

It appears that Tobias Herkula  <[email-masked]> said:
>I'm aware of that, to be more explicit about my meaning. At least I currently believe (I don't know) that there is a difference in buying
>the domain "mydomain.example" under the assumption that .example is a gTLD, sTLD or ccTLD in comparison of buying a domain from ME, like
>"harharhar.mydomain.example".

If you buy mydomain.broker.aero or mydomain.castle.museum or
mydomain.smith.name or mydomain.cpa.pro, you are buying it directly
from the ICANN contracted registry via a registrar so you are in the
same position as if you buy mydomain.org.  If you buy mydomain.us.com
you are buying it from an ICANN contracted registry, but they don't
happen to have a contract about that 2LD.

The public part of the PSL also has thousands of 2nd and 3rd level ccTLD entries
where you get whatever you get from the ccTLD, none of which have
meaningful ICANN contracts.  And as I said, the PSL is missing
a lot of 2LDs sold direct by the TLD registries.  It is a mess and
it does not claim to be authoritative.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Sat, 6 Nov 2021 09:08:41 -0400

Back to Scott's original comment and Ale's skepticism:

Is it feasible that DNS flags could provide a less-bad replacement for the
PSL, or will it be just a different and maybe even less-reliable mess?
If most are not under contract, how can we hope to get cooperation?
Does the leadership or designated members of this group have a way to
evaluate that question?

On Fri, Nov 5, 2021 at 2:23 PM John Levine <[email-masked]> wrote:

> >I'm aware of that, to be more explicit about my meaning. At least I
> currently believe (I don't know) that there is a difference in buying
> >the domain "mydomain.example" under the assumption that .example is a
> gTLD, sTLD or ccTLD in comparison of buying a domain from ME, like

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 06 Nov 2021 13:42:02 +0000

I don't think that's the question we want to try and answer in this working group.  That's roughly the question dbound tried and failed to answer.

If I could reframe the question, I would make it "Is it feasible that DNS flags could provide a less-bad replacement for the PSL for DMARC".  We have already attempted to solve the larger question and failed. Let's not repeat the experience.

Fundamentally, I think the questions you are asking are outside the IETF's remit.  They aren't technical questions that we are equipped to address.

It won't surprise you to hear that my answer to the question as I've modified it is yes.  I think if we clearly and concisely describe the risks with certain aspects of DMARC record publication by PSDs it will mostly work out through either contractual requirements outside the IETF's scope or market forces.

I'll offer that in the early days of SPF there were several DNS providers that decided to 'help' their customers by automatically publishing an SPF record for them that said their customers only sent mail through their infrastructure.  As far as I'm aware, that practice eventually died out because it raised support costs and had negative reputational effects on the providers.

I think that it'll be similar for PSDs and DMARC.  Where there aren't contractual limits in place, some entities will publish problematic records, but market forces will fix it as needed.

Let's not try to boil the ocean.  Let's focus on what's in our scope.

Scott K