Re: [dmarc-ietf] Are Evaluators motivated to switch to Tree Walk?

[Scott Kitterman <[e-mail]>]

On Saturday, June 18, 2022 8:42:23 AM EDT Douglas Foster wrote:
> Let's talk through the selling process for the Tree Walk algorithm.
...
> In sum, why should an Evaluator make the switch?

I think there are some good points in here.  Fundamentally, I agree that there 
needs to be a value proposition associated with investing the resources 
required to update a DMARC implementation from RFC 7489 to DMARCbis.

I don't think it makes sense to pick apart the document and focus on one 
element of the changes in order to determine if that will be supported be 
implementers or not.  In my experience, engineering organizations don't look 
at a specification and assess which pieces of it they want and which ones they 
don't.  They tend to look at it as a whole, unless there are specific concerns 
that need to be addressed.

The code to switch from PSL based organizational domain to tree walk based is 
trivial.  I think any marginal cost associated with implementing it or not 
will be in the noise compared to the overall cost of designing, coding, 
testing, and deploying an update from RFC 7489 to DMARCbis.

In the end, as is common in IETF work, it's difficult to forecast how quickly 
this will occur.  My view is that in the scheme of the overall move to 
DMARCbis, the tree walk won't be a big driver, but it does have advantages:

1.  Does not use the PSL for something it was not intended for.  As has been 
mentioned many times, the PSL is designed for browser use cases, not email.  
In their words:

It allows browsers to, for example:

    Avoid privacy-damaging "supercookies" being set for high-level domain name 
suffixes
    Highlight the most important part of a domain name in the user interface
    Accurately sort history entries by site

This is a big deal in my view.  Under RFC 7489 you can either protect your 
subdomains against supercookies or have a DMARC policy for them.  Not both.

2.  It extends DMARC to cover more entities (PSDs) without the need for a 
centralized registry (which was the best we came up with for RFC 9091).

The registry is one of the reasons RFC 9091 is experimental.  We don't want to 
add a single point of failure to the mail system and this was never a great 
idea.  It was simply the best we could come up with at the time.

3.  Under RFC 7489, if a PSD allows cross user forgery so there is a sibling 
attack risk that organizational domain owners can't mitigate.  With DMARCbis, 
organizational domain owners can address this by publishing psd=n.

To the extent cousin domain attacks are a problem, I think the DMARCbis 
approach is much better.  Under RFC 7489 no domain is more than one PSL update 
away from being at risk.

If we do our overall job well, then updating to DMARCbis should be an obvious 
choice.  My prediction though is that the drivers will ultimately be driven by 
business needs.  Once there's a large email service solicitation that lists 
DMARC using DMARCbis as the reference for the requirement, I expect this will 
get more important to service providers.

Scott K