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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
