Re: [dmarc-ietf] Treewalk not causing changes

[Barry Leiba]

I think the issue here is that people who work directly with DNS
operations have a specific meaning of "zone cut" that differs from
what others think of as zone cuts.  Let's try to avoid using that
term, and instead be clear about what we mean.  Ale, if you disagree
with John, be clear about what you disagree with, without using the
term "zone cut".

Barry

On Wed, Mar 1, 2023 at 9:35 AM John Levine  wrote:
>
> It appears that Alessandro Vesely   said:
> >
> >What are subdomains being used for?
> >
> >Is that more often done for email reasons (MX) or for something else?
> >
> >What changes when there is a zone cut (delegation) rather than having
> >sub-subdomains all in the same zone?
>
> In case it's not clear, the answer is NOTHING AT ALL CHANGES.
>
> DMARC does not look at zone cuts. It has never looked at zone cuts. If
> I have anything to say about it, it will never look at zone cuts.
>
> Some people believe that a zone cut indicates a change of control.
> They are wrong. Sometimes different people are in charge when there is
> a zone cut, sometimes not, sometimes DNS records managed by different
> people are in a single zone, managed in some way you can't tell by
> doing DNS queries.
>
> R's,
> John
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk not causing changes

[John Levine]

It appears that Alessandro Vesely   said:
>
>What are subdomains being used for?
>
>Is that more often done for email reasons (MX) or for something else?
>
>What changes when there is a zone cut (delegation) rather than having 
>sub-subdomains all in the same zone? 

In case it's not clear, the answer is NOTHING AT ALL CHANGES.

DMARC does not look at zone cuts. It has never looked at zone cuts. If
I have anything to say about it, it will never look at zone cuts.

Some people believe that a zone cut indicates a change of control.
They are wrong. Sometimes different people are in charge when there is
a zone cut, sometimes not, sometimes DNS records managed by different
people are in a single zone, managed in some way you can't tell by
doing DNS queries.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Scott Kitterman]

On March 1, 2023 3:08:16 PM UTC, Jesse Thompson  wrote:
>On 3/1/2023 6:12 AM, Douglas Foster wrote:
>
>> A sub-issue to consider:   Should we do a Tree Walk on the authenticating 
>> domain?
>> For example, assume that "virgina.gov " and 
>> "dmas.virginia.gov " both have DMARC policies with 
>> relaxed alignment.   Should "dmas.virginia.gov " 
>> be prohibited from authenticating "virginia.gov "?
>> My gut says yes, but it adds some overhead to enforce that rule.
>
>My gut says that might break ESPs who are using subdomains for SPF relaxed 
>alignment. Unless you are saying that it's safe for treewalk changes to break 
>MAILFROM=bounces.dmas.virginia.gov rfc5322.From=virginia.gov, then maybe there 
>is some data to suggest that it is rare.
>
>Dare I suggest that virginia.gov be able to define the subdomains to which SPF 
>relaxed alignment should apply? As a domain owner, I might be inclined to 
>reserve something like bounces.virginia.gov for all MAIL FROM sub-sub-domains 
>that are used for delegating ESP traffic and manage it similar to DKIM 
>selectors. aspf=s for any subdomains that aren't otherwise defined.
>
>In my experience talking to state governments (as well as reflecting back on 
>my own time in state government), domain owners are seeing a lot of ESP usage 
>sprawl among their sub-domains/agencies/departments and they are frustrated 
>that they can't manage or govern it effectively. In this late stage of the 
>game, they won't be able to publish aspf=s to keep agencies from delegating 
>ESP usage of virginia.gov when the domain owner would otherwise not want them 
>to.
>

If an org domain doesn't want to have subdomain used then they need to use 
strict alignment.  There's no need to turn relaxed alignment into some sort of 
almost strict, but more complicated.  We've gotten this far without redesigning 
alignment, let's not start now.  As far as I remember, it's still the same as 
RFC 7489 and that's a good thing.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Jesse Thompson]

On 3/1/2023 6:12 AM, Douglas Foster wrote:

> A sub-issue to consider:   Should we do a Tree Walk on the authenticating 
> domain?
> For example, assume that "virgina.gov " and 
> "dmas.virginia.gov " both have DMARC policies with 
> relaxed alignment.   Should "dmas.virginia.gov " be 
> prohibited from authenticating "virginia.gov "?
> My gut says yes, but it adds some overhead to enforce that rule.

My gut says that might break ESPs who are using subdomains for SPF relaxed 
alignment. Unless you are saying that it's safe for treewalk changes to break 
MAILFROM=bounces.dmas.virginia.gov rfc5322.From=virginia.gov, then maybe there 
is some data to suggest that it is rare.

Dare I suggest that virginia.gov be able to define the subdomains to which SPF 
relaxed alignment should apply? As a domain owner, I might be inclined to 
reserve something like bounces.virginia.gov for all MAIL FROM sub-sub-domains 
that are used for delegating ESP traffic and manage it similar to DKIM 
selectors. aspf=s for any subdomains that aren't otherwise defined.

In my experience talking to state governments (as well as reflecting back on my 
own time in state government), domain owners are seeing a lot of ESP usage 
sprawl among their sub-domains/agencies/departments and they are frustrated 
that they can't manage or govern it effectively. In this late stage of the 
game, they won't be able to publish aspf=s to keep agencies from delegating ESP 
usage of virginia.gov when the domain owner would otherwise not want them to.

Jesse
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Douglas Foster]

Mark and Laura's perspective solves my objections.

We propose a deliberate change to use the bottom-most policy because we
believe it better meets the needs of large organizations, of which regional
governments are a good example.

A supporting benefit is that we eliminate the possibility of false NO
POLICY or false PASS that can occur when the PSL (or any other jumping
algorithm) jumps to the wrong organizational domain.

We can partially test for negative impacts of this change by looking for
messages where:
- The organizational domain is different from the policy domain, and
- Alignment is only possible using a parent of the policy domain.
Do you think we can get that assessment from one of the big players?

A sub-issue to consider:   Should we do a Tree Walk on the authenticating
domain?
For example, assume that "virgina.gov" and "dmas.virginia.gov" both have
DMARC policies with relaxed alignment.   Should "dmas.virginia.gov" be
prohibited from authenticating "virginia.gov"?
My gut says yes, but it adds some overhead to enforce that rule.

Doug


On Tue, Feb 28, 2023 at 8:47 AM Mark Alley  wrote:

> I agree with Laura's stance. Many organizations (that are not PSDs, and
> not on a PSL) will publish explicit subdomain-specific DMARC policies to
> prevent inheritance from a higher level, or the organizational domain
> (which may not be ready for a stricter policy), during implementation. This
> is a very common configuration.
> On 2/28/2023 6:07 AM, Laura Atkins wrote:
>
> As someone who has worked with companies, educational institutions, and
> governments to set DMARC policy it makes no sense to me that we’d argue the
> top-most-non-PSD policy is the one that should apply. Given how DNS works
> technically and how policies are set in practice, I support stopping at the
> bottom-most policy.
>
> laura
>
>
> On 28 Feb 2023, at 11:52, Douglas Foster
> 
>  wrote:
>
> Murray, I think we need to acknowledge that we are already in a long
> tail.A small percentage of domain owners publish DMARC policies, a
> still smaller percentage publish "reject", and evaluators have a hard time
> deciding whether to use DMARC because the results are unreliable.  The PSD
> discussion merely highlights the fact that DMARC results can be unreliable
> in both directions - PASS and FAIL.
>
> We were much closer to a plausible algorithm when the Tree Walk stopped at
> the top-most non-PSD policy.   We know that most PSOs and private
> registries do not publish DMARC policies, and we hope that those who do
> will add the PSD=Y flag.   Given both of these conditions, if a DNS path
> contains multiple DMARC policies, the top-most policy will be the
> organizational policy because we don't expect any non-PSD policies above
> the organizational domain.
>
> To get a Tree Walk algorithm that stops at the bottom-most policy, John
> added the assumption that domains will never publish sub-domain policies,
> so that a higher-level policy will either not exist at all, or will only
> exist as a registry policy, either of which can be ignored.This
> assumption was made without data and is simply implausible.
>
> If have trouble assuming that registries, especially private registries,
> will only publish PSD=Y policies, now and forever.   My goal in replacing
> the PSL is to give domain owners the responsibility and the control to
> define their own organizational domain boundary.  The current Tree Walk
> does not do that, so it cannot succeed.  The org=-n term places
> responsibility where it belongs.
>
> Doug Foster
>
>
>
> On Mon, Feb 27, 2023 at 10:04 AM Murray S. Kucherawy 
> wrote:
>
>> On Mon, Feb 27, 2023 at 4:29 AM Douglas Foster <
>> dougfoster.emailstanda...@gmail.com> wrote:
>>
>>> The current text has an incentive problem.   For an evaluator, the PSL
>>> works fine.   Unless an evaluator is Google-class, receiving mail from
>>> everywhere in the world, most of the PSL entries will never be examined and
>>> most of the PSL errors will never be exposed.   When an error is detected
>>> by an evaluator, it is a trivial effort to add or remove a record from the
>>> local copy of PSL.  For evaluators, the PSL works fine.
>>>
>>
>> The notion that different operators are using slightly different versions
>> of the PSL is one of the reasons we want to stop depending on the PSL.  I
>> don't think we should offer this as an option.
>>
>>
>>> Domain owners / message senders are the ones who should be powerfully
>>> motivated to replace the PSL.   If so, they should be willing to add a tag
>>> that invokes MUST USE TREE WALK because it eliminates ambiguity and
>>> protects them from the PSL.   With that elimination of ambiguity
>>> and corresponding MUSRT, evaluators have a reason to change.   Without
>>> that, evaluators have every reason to ignore this new, unproven, and
>>> imperfect algorithm;
>>>
>>
>> I'm worried about leaving operators with a choice here, for a number of
>> reasons:
>>
>> 1) "pct" also presented a choice, 

Re: [dmarc-ietf] Treewalk causing changes

[Alessandro Vesely]

On Wed 01/Mar/2023 02:33:14 +0100 Murray S. Kucherawy wrote:

On Tue, Feb 28, 2023 at 5:13 PM Mark Alley 
 wrote:

It does vary widely, agreed; I believe knowing how the behavior changes 
can affect existing implementation and common usage scenarios may be useful 
for at least consideration of its effects on domain owners.


What do you propose?  It seems to me that such a study, to be useful, would 
either need a great deal of inference, or a great deal of time and effort. 
Or both.



Just mumbling...  We introduce to breaking factors, pct= to t= and inheritance 
rule change.  The former is a no-brainer to implementer; it's straightforward 
to support both, since the intention of the publisher is clear.  The latter 
seems to be hardly tractable in a case-by-case fashion, as domain owner's 
expectations are going to adapt as the new spec spreads.  It is important to 
get it right, also in view of future extensions.



Best
Ale
--









___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Alessandro Vesely]

On Wed 01/Mar/2023 11:12:06 +0100 Laura Atkins wrote:

On 1 Mar 2023, at 09:07, Alessandro Vesely  wrote:



However, in that case both zones are under the same master server:

cuny.edu.   2801IN  SOA acme.ucc.cuny.edu. 
hostmaster.acme.ucc.cuny.edu. 2019022032 3600 1800 2419200 3600
bmcc.cuny.edu.  300 IN  SOA acme.ucc.cuny.edu. 
hostmaster.acme.ucc.cuny.edu. 200804826 300 3600 2419200 3600
ret.bmcc.cuny.edu. (no SOA)

(Those funny serials cannot begin with the year.  We had no DMARC in 2008.)


I don’t see how that changes anything. You walk up the DNS hierarchy and stop 
when you find a DMARC policy statement. You don’t bypass that statement and 
keep walking, IMO.



You may want to keep walking if you need to establish which is the org domain, 
for alignment purposes.  Part of the walk can be optimized out when (one of) 
the verified identifiers lies within the subtree explored thus far. I'm not 
sure how I'm going to implement that.



Best
Ale
--





___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Laura Atkins]

> On 1 Mar 2023, at 09:07, Alessandro Vesely  wrote:
> 
> Thanks to you and Mark!
> 
> 
> On Tue 28/Feb/2023 19:00:22 +0100 Laura Atkins wrote:
>>> On 28 Feb 2023, at 17:51, Alessandro Vesely  wrote:
>>> What changes when there is a zone cut (delegation) rather than having 
>>> sub-subdomains all in the same zone?  Controlling inheritance obviously has 
>>> different tastes depending on the case.  Which case is more common?
>> 
>> If it’s a zone cut, then that supports the “bottom-most” policy even more 
>> than  if it’s in the same zone, IMO.
> 
> 
> For clarity, let me point out that bottom-most refers to the convention that 
> abstract trees have their roots at the top.  IOW, since ret.bmcc is in the 
> same zone as bmcc it seems better for the former to inherit from the latter 
> than from its org domain.

Thank you for the clarification. I was adopting the terminology from the post I 
was responding to rather than confusing the conversation by changing it. 

> However, in that case both zones are under the same master server:
> 
> cuny.edu. 2801IN  SOA acme.ucc.cuny.edu. 
> hostmaster.acme.ucc.cuny.edu. 2019022032 3600 1800 2419200 3600
> bmcc.cuny.edu.300 IN  SOA acme.ucc.cuny.edu. 
> hostmaster.acme.ucc.cuny.edu. 200804826 300 3600 2419200 3600
> ret.bmcc.cuny.edu. (no SOA)
> 
> (Those funny serials cannot begin with the year.  We had no DMARC in 2008.)

I don’t see how that changes anything. You walk up the DNS hierarchy and stop 
when you find a DMARC policy statement. You don’t bypass that statement and 
keep walking, IMO.

laura 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Alessandro Vesely]

Thanks to you and Mark!


On Tue 28/Feb/2023 19:00:22 +0100 Laura Atkins wrote:

On 28 Feb 2023, at 17:51, Alessandro Vesely  wrote:


What changes when there is a zone cut (delegation) rather than having 
sub-subdomains all in the same zone?  Controlling inheritance obviously has 
different tastes depending on the case.  Which case is more common?


If it’s a zone cut, then that supports the “bottom-most” policy even more than  
if it’s in the same zone, IMO.



For clarity, let me point out that bottom-most refers to the convention that 
abstract trees have their roots at the top.  IOW, since ret.bmcc is in the same 
zone as bmcc it seems better for the former to inherit from the latter than 
from its org domain.

However, in that case both zones are under the same master server:

cuny.edu.   2801IN  SOA acme.ucc.cuny.edu. 
hostmaster.acme.ucc.cuny.edu. 2019022032 3600 1800 2419200 3600
bmcc.cuny.edu.  300 IN  SOA acme.ucc.cuny.edu. 
hostmaster.acme.ucc.cuny.edu. 200804826 300 3600 2419200 3600
ret.bmcc.cuny.edu. (no SOA)

(Those funny serials cannot begin with the year.  We had no DMARC in 2008.)


Best
Ale
--










___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc