[dmarc-ietf] Version bump: was DMARC2 & SPF Dependency Removal

[Scott Kitterman <[e-mail]>]

On June 8, 2023 12:58:51 PM UTC, Tobias Herkula <tobias.herkula=[e-mail]> wrote:
... 
>
>However, such a fundamental shift in the protocol's architecture warrants a clear signifier. I suggest we upgrade our DMARC version string from the current state to 'DMARC2.' This upgrade would not only denote the change of SPF removal, but also the switch from the Public Suffix List (PSL) to the Tree-Walk algorithm.
>
>By moving towards DMARC2, we not only update our standard to better reflect our present requirements, but we also make a clear commitment to the ongoing evolution and improvement of the protocol.


There's been a fair amount of discussion of the drop SPF part of this proposal, but I think less about the question of version bumps.  I'm going back to the top of the thread to focus on that.

I don't think there's much precedent for version bumps being successful in any reasonable time frame.  How long did it take to transition from SMTP to ESMTP?  Is it done yet?  Absent IPv4 address exhaustion, how many more decades would it have taken for IPv6 deployment to take off?  SSL/TLS is the best example I can think of, but even that, where there are very strong security and privacy incentives, has been too slow and very painful.  We have nothing like that level incentive for people to support an incompatible break between non-IETF DMARC and IETF DMARC.

Technically, it's a new protocol.  There's no technical difference between saying records now have to start with v=DMARC2 and they have to start with v=NOTDMARC.  It's a decision to abandon all existing deployments and start over.

What's the incentive that any existing DMARC users (senders or receivers) would have to invest additional resources in another email authentication protocol?  My expectation is that if the IETF decides to bump the version, very little deployment of the IETF variant.  "The IETF says this one is better" doesn't move budgets in any meaningful way.

My suggestion is that if we determine that a change requires a version bump, out response should be to not make that change instead.

For clarity, I don't think the tree walk should drive a version bump (and we already went over that, let's resist the temptation to do it again), but if it did, then I would rather stay with the PSL.

Please, no version bumps.

Scott K