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

Murray S. Kucherawy wrote in : |On Mon, Feb 5, 2024 at 1:39 PM Steffen Nurpmeso wrote: |> If a graphical user interface gives you a green "ok" button to |> click, or "red" otherwise, that is even better as in browser URL |> lines. Then pop up a tree-view of message modifications and |>

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

Dave Crocker wrote in : |On 2/5/2024 2:08 PM, Jim Fenton wrote: |> On 5 Feb 2024, at 14:02, Dave Crocker wrote: |>> On 2/5/2024 1:56 PM, Jim Fenton wrote: ... ..because that makes me sad over and over again.. | of 528 web users This is a

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

Whoa! I wondered about that!! Lock Icon was gone and it’s not a “switch” indication “options” icon. You know, a good bit of the time is a programmer getting excited with a new UI API and switches to it!! Imo, there was no need for that change, Everything in the options was 100% about

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

It appears that Murray S. Kucherawy said: >-=-=-=-=-=- > >On Mon, Feb 5, 2024 at 1:39 PM Steffen Nurpmeso wrote: > >> If a graphical user interface gives you a green "ok" button to >> click, or "red" otherwise, that is even better as in browser URL >> lines. Then pop up a tree-view of message

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

On Mon, Feb 5, 2024 at 1:39 PM Steffen Nurpmeso wrote: > If a graphical user interface gives you a green "ok" button to > click, or "red" otherwise, that is even better as in browser URL > lines. Then pop up a tree-view of message modifications and > alertize where it broke, checkbox for

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

On 2/5/2024 5:50 PM, Dave Crocker wrote: we'd see reductions in user understanding, awareness and resistance abuse. sigh. /increases /in user understanding, awareness and resistance abuse. reductions in user clicking errors, or somesuch -- Dave Crocker Brandenburg InternetWorking bbiw.net

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

On 2/5/2024 2:08 PM, Jim Fenton wrote: On 5 Feb 2024, at 14:02, Dave Crocker wrote: On 2/5/2024 1:56 PM, Jim Fenton wrote: And you will also provide citations to refereed research about what you just asserted as well, yes? Ahh, you want me to prove the negative. That's not exactly how these

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

Jim Fenton wrote in <3e7a38ef-4026-4943-8bc3-22516e3f1...@bluepopcorn.net>: |On 5 Feb 2024, at 14:02, Dave Crocker wrote: |> On 2/5/2024 1:56 PM, Jim Fenton wrote: |>> And you will also provide citations to refereed research about what \ |>> you just asserted as well, yes? |> |> Ahh, you

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

On 5 Feb 2024, at 14:02, Dave Crocker wrote: > On 2/5/2024 1:56 PM, Jim Fenton wrote: >> And you will also provide citations to refereed research about what you just >> asserted as well, yes? > > > Ahh, you want me to prove the negative. That's not exactly how these things > go. You said that

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

On 2/5/2024 1:56 PM, Jim Fenton wrote: nd you will also provide citations to refereed research about what you just asserted as well, yes? Ahh, you want me to prove the negative. That's not exactly how these things go. When someone says something works, the burden of documenting it is on

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

On 5 Feb 2024, at 13:46, Dave Crocker wrote: > On 2/5/2024 1:24 PM, Steffen Nurpmeso wrote: >> I*totally* disagree. >> It is also a matter of education. > > Yeah.  No.  The standard example is the failure of the URL lock symbol. > > But given your certitude, please provide refereed research

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

On 2/5/2024 1:24 PM, Steffen Nurpmeso wrote: I*totally* disagree. It is also a matter of education. Yeah.  No.  The standard example is the failure of the URL lock symbol. But given your certitude, please provide refereed research about persistent behavioral change from email header

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

Steffen Nurpmeso wrote in <20240205212412.Kq4PkTNC@steffen%sdaoden.eu>: |Dave Crocker wrote in | : ||On 2/5/2024 9:43 AM, Alessandro Vesely wrote: ||> It is debatable whether it is useful to display authentication ||> information to the end user.  Personally, I like to see it. || ||At

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

Dave Crocker wrote in : |On 2/5/2024 9:43 AM, Alessandro Vesely wrote: |> It is debatable whether it is useful to display authentication |> information to the end user.  Personally, I like to see it. | |At scale, there is no debate among UX professionals.  Its presence |varies between

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

On 2/5/2024 9:43 AM, Alessandro Vesely wrote: It is debatable whether it is useful to display authentication information to the end user.  Personally, I like to see it. At scale, there is no debate among UX professionals.  Its presence varies between useless and confusing, for typical users.

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

On 05/02/2024 17:02, Hector Santos wrote: On Feb 3, 2024, at 8:23 AM, Alessandro Vesely wrote: RFC 5322 specifies lists for From:, To:, Cc:, Bcc:, Reply-To:, Resent-From:, Resent-To:, Resent-Cc: and Resent-Bcc:. My comment was regarding the MUA and the order data is read. I wonder which

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

> On Feb 3, 2024, at 8:23 AM, Alessandro Vesely wrote: > > On Fri 02/Feb/2024 14:34:22 +0100 Hector Santos wrote: >> Of course, the MUA is another issue. What read order should be expected for >> Oversign headers? Each MUA can be different although I would think streamed >> in data are

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

On Fri 02/Feb/2024 14:34:22 +0100 Hector Santos wrote: Of course, the MUA is another issue.  What read order should be expected for Oversign headers?  Each MUA can be different although I would think streamed in data are naturally read sequentially and the first display headers found are used

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

On 2/1/2024 6:38 AM, Alessandro Vesely wrote: On Wed 31/Jan/2024 18:34:46 +0100 Hector Santos wrote: If I add this feature to wcDKIM, it can be introduced as: [X] Enable DKIM Replay Protection That'd be deceptive, as DKIM replay in Dave's sense won't be blocked, while there can be other

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

On Wed 31/Jan/2024 18:34:46 +0100 Hector Santos wrote: If I add this feature to wcDKIM, it can be introduced as: [X] Enable DKIM Replay Protection That'd be deceptive, as DKIM replay in Dave's sense won't be blocked, while there can be other effects on signature robustness. A better

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

On Wed, Jan 31, 2024 at 9:35 AM Hector Santos wrote: > First time I have come across the term (“oversign”) and it appears to be > a feature with several products in the market. But checking the RFC, unless > I missed it, it’s not a RFC defined term. Replay is the term used. > You won't find

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

> On Jan 19, 2024, at 8:41 PM, John R Levine wrote: > > Manfred said: >> (Seems like "seal"ing would be a better term than "oversign"ing.) > > We've called it oversigning for a decade now. > Interesting. First time I have come across the term (“oversign”) and it appears to be a feature

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

Manfred said: (Seems like "seal"ing would be a better term than "oversign"ing.) We've called it oversigning for a decade now. R's, John ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim

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

John Levine wrote in <20240119192026.dedff8104...@ary.qy>: |It appears that Evan Burke said: |>> Insisting on using the same term for these two different cases has an |>> academic purity to it, but has already been demonstrated to be destructi\ |>> ve |>> in practical terms, because it

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

Dave Crocker wrote in <54bcc79e-2cec-4c49-8a5c-0ef64db68...@dcrocker.net>: |On 1/19/2024 6:51 AM, Al Iverson wrote: ... |[.]the scenario of |sending to a collaborating receiver and re-posting a message that has no |differences except the envelope rcpt-to value, does not have a know

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

Steffen Nurpmeso wrote in <20240120002211.9zE1qqLr@steffen%sdaoden.eu>: ... |[.]people which[.] So that is "people who", and then i wanted to apologise for naming Mr. Kucherawy "Kucheraway" in one of all those of my posts. Have a nice weekend i wish from Germany, --steffen | |Der Kragenbaer,

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

Emanuel Schorsch wrote in : |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.

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

Steffen Nurpmeso wrote in <20240119235632.VOlkKoIX@steffen%sdaoden.eu>: |Dave Crocker wrote in | <54bcc79e-2cec-4c49-8a5c-0ef64db68...@dcrocker.net>: ||On 1/19/2024 6:51 AM, Al Iverson wrote: ... ||[.]does not have a know ||solution. | |There would be a RFC 6376 backward compatible

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

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

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

It appears that Evan Burke said: >> Insisting on using the same term for these two different cases has an >> academic purity to it, but has already been demonstrated to be destructive >> in practical terms, because it creates confused discussion. >No, that's exactly backwards. The oversigning

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

On Fri, Jan 19, 2024 at 7:01 AM Dave Crocker wrote: > On 1/19/2024 6:51 AM, Al Iverson wrote: > > I'm > sort of boggling at the attempt to keep potential header changes and > DKIM oversigning out of the exploit definition and potential solution > consideration. I just don't think it makes sense

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

On 1/19/2024 6:51 AM, Al Iverson wrote: I'm sort of boggling at the attempt to keep potential header changes and DKIM oversigning out of the exploit definition and potential solution consideration. I just don't think it makes sense to exclude this. It makes sense because oversigning is

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

I don't know what other people have decided off in spec land to call this, but here what I'm seeing is somebody taking a message, adding headers (or not), re-injecting the message to another recipient, it being received with DKIM signature intact, that's DKIM replay. I'm sort of boggling at the

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

On 1/18/2024 1:46 PM, Dave Crocker wrote: The issue is not whether those broader concerns are... concerns.  They are.  But the topic of DKIM Replay has to do with a scenario that is affected by things like oversigning. sigh.  sorry. small, insignificant typo, merely flipping the sign bit...

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

Dave Crocker wrote in <82f48c8d-b89c-404f-87ac-4619628dd...@dcrocker.net>: |On 1/16/2024 3:57 PM, Evan Burke wrote: ... |> Without oversigning those headers, DKIM would pass, | |Yes, oversigning is useful.  And it has been useful for a very long Just to make that clear to myself, who is

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

On 1/16/2024 3:57 PM, Evan Burke wrote: DKIM Replay re-sends an /unmodified/ copy of the message, where only the SMTP RCPT-To is different.  DKIM doesn't (and can't) cover that SMTP command. I'd call it DKIM replay if the signature is intact. You are, of course, free to use any

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

On Tue, Jan 16, 2024 at 8:58 AM Dave Crocker wrote: > Ahh. OK. Oversigning, to prevent sending a version of the message onward > -- but with one or another field added -- is generally viewed as a Good > Thing. I have tried to locate one, but I believe there are some best > practices documents

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

On 16/01/2024 17:52, Mike Hillyer wrote: One example of this documented is Brian Godiksen's blog post at https://www.socketlabs.com/blog/dkim-replay-attacks-preventive-measures-to-protect-email-deliverability The post explicitly mentions subject, to, from, date and reply-to headers. I

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

It appears that Mike Hillyer said: >In the interest of the rule of unforseen consequences, we're trying to avoid >oversigning any headers that would break further downstream processing. Does >anyone >know of any headers that *should* be DKIM signed, but *should not* be >oversigned? Offhand,

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

On 1/16/2024 8:52 AM, Mike Hillyer wrote: In my discussions, I've been told of malicious parties sending messages with blank subject headers (not missing, the header name is there with no value), and adding a second subject header with the payload subject line, and some MUAs will either show the

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

In my discussions, I've been told of malicious parties sending messages with blank subject headers (not missing, the header name is there with no value), and adding a second subject header with the payload subject line, and some MUAs will either show the subject because it is higher up in the

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

On 1/16/2024 8:18 AM, Mike Hillyer wrote: In an effort to make it easier for our users to prevent DKIM replay attacks, we're looking at adding an option to our DKIM signing module to automatically oversign headers in the DKIM signature, adding an additional entry in the headers list to assert

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

Hello All, In an effort to make it easier for our users to prevent DKIM replay attacks, we're looking at adding an option to our DKIM signing module to automatically oversign headers in the DKIM signature, adding an additional entry in the headers list to assert a null header, preventing a