Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

2023-10-28 Thread Scott Kitterman
On Saturday, October 28, 2023 4:03:30 PM EDT Emanuel Schorsch wrote: > > As to why, I don't think there's a valid use case and the proponents for > > this haven't really thought it through. As an example, someone (I don't > > recall who) cited the issue of domain owners that publish SPF, but

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

2023-10-28 Thread Mark Alley
For the shared provider SPF upgrade example, I think Scott's previously mentioned method of using SPF '?' qualifier on the relevant shared mechanism mitigates the upgrade problem, and ensures only DKIM can provide passing authentication. Thinking back earlier this year to the well-publicized SPF

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

2023-10-28 Thread Emanuel Schorsch
> > As to why, I don't think there's a valid use case and the proponents for > this haven't really thought it through. As an example, someone (I don't > recall who) cited the issue of domain owners that publish SPF, but can't be > bothered to set up DKIM. The implication is that this minimum

Re: [dmarc-ietf] DMARC session at IETF 118

2023-10-28 Thread Wei Chuang
I'd vote for discussing the "auth=" tag proposal at IETF-118, and I can participate remotely. Discussing this on the mailing list is easier, but will be drawn out as it's harder to understand if there is consensus one way or the other. The advantage is that this will time box the discussion and

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

2023-10-28 Thread Hector Santos
Fwiiw, Lurker opinion: I ideally vote to make DMARCBis Experimental Status and begin to explore the “required” integration between envelope (5321 only) protocols and payload (5322) protocols. Specifically, work on a “proper” DKIM+SPF Policy Modeling with 3rd party signature support. But

Re: [dmarc-ietf] DMARC session at IETF 118

2023-10-28 Thread Scott Kitterman
On October 28, 2023 5:38:00 PM UTC, Barry Leiba wrote: >I'm starting this in a separate thread that I want to keep for ONLY >the following question: > >Do we want to use the session we have scheduled at IETF 118 to talk >about the issue that clearly is still in discussion about adding a tag

[dmarc-ietf] DMARC session at IETF 118

2023-10-28 Thread Barry Leiba
I'm starting this in a separate thread that I want to keep for ONLY the following question: Do we want to use the session we have scheduled at IETF 118 to talk about the issue that clearly is still in discussion about adding a tag to specify which authentication mechanism(s) to use when

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

2023-10-28 Thread Murray S. Kucherawy
On Sat, Oct 28, 2023 at 8:28 AM Richard Clayton wrote: > Paying attention to the (sometimes inferred) age of a signature is also > important for reducing the opportunity for replay, viz: it would be a > Good Thing for senders to set appropriately short expire times. > Why does it have to be

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

2023-10-28 Thread Scott Kitterman
On Saturday, October 28, 2023 11:26:40 AM EDT Richard Clayton wrote: > In message <3316620.Pp0j0xxFaF@localhost>, Scott Kitterman > writes > > >What's your plan for when easily getting a DMARC pass due to bad SPF > >records doesn't work anymore, so the bad guys focus more on DKIM replay? > > At

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

2023-10-28 Thread Scott Kitterman
On Saturday, October 28, 2023 10:51:27 AM EDT Scott Kitterman wrote: > >Even if we don't add the feature, we should address the vulnerability. Currently there is only a bullet in Section 4.8, Organizational Domain Discovery, saying: > > * The domain found in the RFC5321.MailFrom header if there

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

2023-10-28 Thread Richard Clayton
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <3316620.Pp0j0xxFaF@localhost>, Scott Kitterman writes >What's your plan for when easily getting a DMARC pass due to bad SPF records >doesn't work anymore, so the bad guys focus more on DKIM replay? At $DAYJOB$, DKIM replay is simply

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

2023-10-28 Thread Scott Kitterman
On Saturday, October 28, 2023 10:49:46 AM EDT Richard Clayton wrote: > In message <6bb2871c-da84-42ad-bae1-7b4828b0f...@tana.it>, Alessandro > Vesely writes > > >On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote: > >> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely wrote: > >>>If

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

2023-10-28 Thread Scott Kitterman
On October 28, 2023 12:01:05 PM UTC, Alessandro Vesely wrote: >On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote: >> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely wrote: >>> On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote: If there isn't a consensus to do a

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

2023-10-28 Thread Richard Clayton
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <6bb2871c-da84-42ad-bae1-7b4828b0f...@tana.it>, Alessandro Vesely writes >On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote: >> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely wrote: >>>If we add the feature, we should in

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

2023-10-28 Thread Alessandro Vesely
On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote: On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely wrote: On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote: If there isn't a consensus to do a DKIM-only feature, which seems to be the case, I agree, wrap up the few minor