Re: [dmarc-ietf] Version bump: was DMARC2 & SPF Dependency Removal
On Sat 10/Jun/2023 21:03:00 +0200 Scott Kitterman wrote: 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. Let's recall the logic we adopted to design the tree walk: On Sat 26/Feb/2022 18:14:30 +0100 John R Levine wrote: I'm finding it hard to understand the advantage of a scheme that requires millions of DMARC records to change rather than one that changes 52. Please, no version bumps. +1 Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Version bump: was DMARC2 & SPF Dependency Removal
On Sat, Jun 10, 2023 at 3:55 PM Scott Kitterman wrote: > To the extent we might need it so far, I think the psd= tag is that flag. > I am totally good with that. tim ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Version bump: was DMARC2 & SPF Dependency Removal
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 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 >wrote: > >> >> >> On June 8, 2023 12:58:51 PM UTC, Tobias Herkula > 401und1...@dmarc.ietf.org> 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 >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Version bump: was DMARC2 & SPF Dependency Removal
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 wrote: > > > On June 8, 2023 12:58:51 PM UTC, Tobias Herkula 401und1...@dmarc.ietf.org> 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 > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
