Re: [Ietf-dkim] Clarifying the problem

2023-03-10 Thread Emanuel Schorsch
On Fri, Feb 17, 2023 at 11:11 AM Michael Thomas wrote: > > I've said in multiple threads that the current problem both in the charter > and the problem draft are far too vague for us to address. Here are some > from me at least: > >1. Who are the victims? Just bulk senders? Are the bulk sende

Re: [Ietf-dkim] Welcome to the rechartered working group

2023-03-19 Thread Emanuel Schorsch
In my mind, there are two important things I would like to see achieved: 1) Distinguish indirect from direct flows (encode in some way which server / mailingList the original DKIM message was intended to come from). This is needed for domains that aren't easily identifiable as direct flows (SPF is

Re: [Ietf-dkim] Welcome to the rechartered working group

2023-03-22 Thread Emanuel Schorsch
On Wed, Mar 22, 2023 at 11:29 AM Murray S. Kucherawy wrote: > On Sun, Mar 19, 2023 at 11:04 PM Emanuel Schorsch 40google@dmarc.ietf.org> wrote: > >> In my mind, there are two important things I would like to see achieved: >> >> 1) Distinguish indirect from direc

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

2023-08-06 Thread Emanuel Schorsch
On Sun, Aug 6, 2023 at 11:52 AM Wei Chuang wrote: > > > On Sat, Aug 5, 2023 at 4:51 AM Laura Atkins > wrote: > >> >> >> On 5 Aug 2023, at 02:43, Jesse Thompson wrote: >> >> On Thu, Aug 3, 2023, at 11:08 AM, Laura Atkins wrote: >> >> I agree with this and have been working to recruit folks to co

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

2023-08-07 Thread Emanuel Schorsch
On Sun, Aug 6, 2023 at 10:23 PM Jesse Thompson wrote: > On Sun, Aug 6, 2023, at 2:00 PM, Emanuel Schorsch wrote: > > > > On Sun, Aug 6, 2023 at 11:52 AM Wei Chuang 40google@dmarc.ietf.org> wrote: > > > > On Sat, Aug 5, 2023 at 4:51 AM Laura Atkins > wrote

Re: [Ietf-dkim] replay is a bogus concept

2023-08-15 Thread Emanuel Schorsch
> > Still, knowing that he's a bad actor, you could skip signing. Are there > so > many new spammers every day? Or, rather, there is a bunch of professional > spammers who know how to hide? > Just to answer the second question: Yes, absolutely. Spammers are fully professional and organized group

Re: [Ietf-dkim] Replay attack definition discussion

2023-08-17 Thread Emanuel Schorsch
On Thu, Aug 17, 2023 at 2:06 PM Alessandro Vesely wrote: > On Thu 17/Aug/2023 18:21:35 +0200 Murray S. Kucherawy wrote: > > On Thu, Aug 17, 2023 at 3:30 AM Alessandro Vesely > wrote: > > > >>> I'm not convinced advice is necessary here. Do you really need signs > in > >>> banks that say "Don't

Re: [Ietf-dkim] Replay attack definition discussion

2023-08-18 Thread Emanuel Schorsch
> > > BUT, I think this is a good idea that is separate from DKIM Replay. > > Specifically, we do see non-free mail providers as victims of DKIM > Replay as > > well. > > > If the rate is similar, I agree. That kind of information is missing from > the I-D. > > > > For example, we have seen very l

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

2024-01-19 Thread Emanuel Schorsch
I don't have a strong horse in this race. But I'll just chime in that from my perspective I was thinking of both of these as DKIM Replay. I have been calling any case where the DKIM signature is not broken and the spammer resends multiple copies as DKIM Replay. On Fri, Jan 19, 2024 at 11:20 AM Joh

[Ietf-dkim] Re: Charter #4?

2025-01-27 Thread Emanuel Schorsch
Michael, I agree with you that there's a security risk to allowing footer modifications. But I think Wei's point is critical, the difference between the l= vulnerability and the algebra vulnerability is that the algebra will require clear attribution of which party made the modification. That makes