[Ietf-dkim] Re: Should we be recording all modifications

It appears that Taavi Eomäe said: >-=-=-=-=-=- >-=-=-=-=-=- >On 18/11/2024 00:19, Bron Gondwana wrote: >> And I do agree there needs to be a way to say "I made changes, and I'm >> not telling you how to undo them" as well. > >This has the risk of completely nullifying the intent behind the new >

[Ietf-dkim] Re: Should we be recording all modifications

It appears that Wei Chuang said: >I'm very much in agreement with the need to attribute who contributed which >content to the message. I think this is the key difference from the >RFC6376 DKIM l= body length tag (section 3.5) that tried to tolerate >mailing footer modification also, but left unk

[Ietf-dkim] Re: Charter: DKIMbis or a new thing

Alessandro Vesely wrote in <3aba29a1-e13c-4493-a71e-feb3f5b4c...@tana.it>: |On Mon 18/Nov/2024 18:53:11 +0100 Jim Fenton wrote: |> On 18 Nov 2024, at 9:23, Dave Crocker wrote: |>> On 11/17/2024 2:19 PM, Bron Gondwana wrote: |>>> Regarding the question of "is this DKIMbis or something bigger"? 

[Ietf-dkim] Re: Charter: DKIMbis or a new thing

On 18 Nov 2024, at 9:23, Dave Crocker wrote: > On 11/17/2024 2:19 PM, Bron Gondwana wrote: >> Regarding the question of "is this DKIMbis or something bigger"?  It's >> something bigger than just tweaks to DKIM. >> >> The choice of the name "DKIM2" is partially branding, and partially because >>

[Ietf-dkim] Re: Should we be recording all modifications

On 11/18/24 07:19, Bron Gondwana wrote: I don't believe it's that complex, and I do believe it's worth the effort in exchange for being able to tell with certainty which entity (by signature; which DNS domain) is responsible for creating each part of a message. You can then attribute parts of t

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On Sun 17/Nov/2024 11:30:09 +0100 Laura Atkins wrote: On 16 Nov 2024, at 10:39, Alessandro Vesely wrote: On 15/11/2024 20:13, Dave Crocker wrote: You might prefer more comfortable language but I was characterizing the very problematic tone that I perceive permeating work in this space, in rec

[Ietf-dkim] Re: Should we be recording all modifications

On Sun 17/Nov/2024 23:19:47 +0100 Bron Gondwana wrote: And if a message is bad then it's possible to derive where the badness was introduced - something not possible with DKIM or ARC if a message has been modified. I have a draft for a method at: https://datatracker.ietf.org/doc/draft-gondwa

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On 11/6/2024 6:54 PM, Wei Chuang wrote: signed recipient Small request for clarification: I'm not familiar with this term.  And the 'strong protections' paper you cite does not seem to use it. Since recipients don't do the signing, it is not safely intuitive to guess what the term means.

[Ietf-dkim] Re: Charter: DKIMbis or a new thing

On Mon 18/Nov/2024 18:53:11 +0100 Jim Fenton wrote: On 18 Nov 2024, at 9:23, Dave Crocker wrote: On 11/17/2024 2:19 PM, Bron Gondwana wrote: Regarding the question of "is this DKIMbis or something bigger"?  It's something bigger than just tweaks to DKIM. The choice of the name "DKIM2" is part

[Ietf-dkim] Re: Should we be recording all modifications

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <20241118210924.4dff9a743...@ary.qy>, John Levine writes >Right. We need to make it clear that the "trust me" bit is only intended >for mail from gateways with whom you already have a relationship. I have been calling the bit "it's compl

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On 11/6/2024 6:54 PM, Wei Chuang wrote: "message algebra " This topic has been a point of fascination for some years.  It is, indeed, attractive. It is also a research topic, absent a body of experience show

[Ietf-dkim] Re: Should we be recording all modifications

Bron Gondwana wrote in <71d3b35b-e9e1-43bd-a6ab-d0cb26152...@app.fastmail.com>: ... |[.] I have a draft for a method at: | |https://datatracker.ietf.org/doc/draft-gondwana-dkim2-modification-alegbra/ | |It can be used to describe all "add text" cases quite nicely, as well \ |as wrapped stru

[Ietf-dkim] Re: Should we be recording all modifications

On Tue, Nov 19, 2024, at 12:14, Steffen Nurpmeso wrote: > I wondered for myself how the bsdiff algorithm would work out for > such things. This is basically the bsdiff algorithm, but with the syntax converted to be something human readable and header safe. And obviously, only applied to the

[Ietf-dkim] Anti-replay, was PROPOSAL: reopen this working group and work on DKIM2

On Sun 17/Nov/2024 12:32:10 +0100 Richard Clayton wrote: You will note that the outline DKIM2 spec says that an m= setting for the very first DKIM2 signature can specify that an email must not be modified or "exploded". Hence standards compliant systems would prevent the attacks we currently see

[Ietf-dkim] Re: Charter: DKIMbis or a new thing

On 11/17/2024 2:19 PM, Bron Gondwana wrote: Regarding the question of "is this DKIMbis or something bigger"?  It's something bigger than just tweaks to DKIM. The choice of the name "DKIM2" is partially branding, and partially because it re-uses the existing DNS entries for DKIM keys and large

[Ietf-dkim] Re: Should we be recording all modifications

On Sun, Nov 17, 2024 at 2:20 PM Bron Gondwana wrote: > I don't believe it's that complex, and I do believe it's worth the effort > in exchange for being able to tell with certainty which entity (by > signature; which DNS domain) is responsible for creating each part of a > message. You can then a

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On 16 Nov 2024, at 13:30, John Levine wrote: > It appears that Murray S. Kucherawy said: >> A small operator or individual with a good idea that lacks the resources to >> test at scale shouldn't be excluded unnecessarily. Are the large operators >> reasonably willing to test promising ideas eve

[Ietf-dkim] Re: Should we be recording all modifications

On 18/11/2024 00:19, Bron Gondwana wrote: And I do agree there needs to be a way to say "I made changes, and I'm not telling you how to undo them" as well. This has the risk of completely nullifying the intent behind the new standard by providing a path of least resistance too many would take.