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

[Scott Kitterman <[e-mail]>]

To the extent we might need it so far, I think the psd= tag is that flag.

Scott K

On June 10, 2023 7:34:59 PM UTC, Tim Wicinski <[e-mail]> wrote:
>I'd rather add an option to flag some behavior rather than do a version
>bump.
>
>Have to agree with Scott that version bumps take forever.
>(I had a network engineer recently tell me that DNS packets *MUST* be no
>larger than 512 bytes - and EDNS0 was 1999?)
>
>tim
>
>On Sat, Jun 10, 2023 at 3:03 PM Scott Kitterman <[e-mail]>
>wrote:
>
>>
>>
>> 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
>>
>> _______________________________________________
>> dmarc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dmarc
>>