Re: [dmarc-ietf] WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

[Scott Kitterman <[e-mail]>]

On Saturday, March 30, 2024 4:05:17 PM EDT Seth Blank wrote:
> Section 4.6: DNS Tree Walk:
> 
> The text is correct, but N is wrong. I've shared my notes with this list
> but we never reached consensus:
> https://mailarchive.ietf.org/arch/msg/dmarc/GoExCeJYWhxnvH8lwjbr7nAcFh4/
> 
> tl;dr: N of 5 works for *org domain discovery* but falls short
> *policy/reporting* discovery. The algorithm can stay the same, but N needs
> to be increased and the text to match.
> 
> I *strongly* believe that N needs to be 8 to meet operational use cases
> we see today, and may still fall short in the future as this use case is
> unlocked by the tree walk.

We started to discuss this in a different thread last week, before I got 
distracted.  I'd like to pick this up taking a look at Seth's proposal and 
rationale directly, rather than as a side point from another discussion.

I think that Seth's basic rationale is correct.  N=5 works for org domain 
discovery.  I am willing to accept that there is a need for different reporting 
addresses within an org and that this might require a different value of N.

The problem I have is that this is outside the scope of the agreed design 
space.  If there's consensus to expand the scope of what DMARCbis is taking 
on, I don't think the difference between 5 and 8 for N is operationally 
significant.

In RFC 7489 DMARC, policy and reporting addresses can be discovered exactly 
two places:  the RFC5322.From domain and the org domain.  The DMARC records 
for any labels between those two domains are not assessed.  As a result, any 
subdomain that needs a different reporting address than that specified in the 
org domain, needs to publish it's own DMARC record.

As a side effect of the switch to the tree walk approach in DMARCbis, this is 
no longer true.  For any subdomain without a DMARC record, the domains above 
it in the tree are also checked, so you can specify a different policy/
reporting address for groups of subdomains below the org domain (as long as 
you don't get past the max N value in length).  

This was never a design objective, just a side effect. As a result, I am 
skeptical of the claim that the thing we accidentally did, that DMARC (as 
defined by RFC 7489) does not do, is somehow critical.  It's not at all clear 
to my why any organization with these long domain names can't continue to do 
whatever they are doing now.

If we are going to change our design scope after WGLC, I think there should be 
a high bar for it.  I think it would be an admission that there is not WG 
consensus to proceed and we may need another WGLC after this is sorted (but 
I'm happy to leave that to management to figure out).

I can articulate that N=5 is based on the longest email relevant entry in the 
current PSL.  Why N=8 and not N=7 or N=9?  I think we need to have an 
articulable rationale for what ever number we end up with (even though that 
rationale probably doesn't go into DMARCbis).

I suspect that once we work through it, most of the work here is about the 
"text to match" that Seth mentioned, I don't think the exact number is that 
important.

Scott K

P.S.  Sorry for the delay, this email was more than I felt I could reasonably 
pull off writing from my phone.

P.P.S I think I'm caught up on last call email now.