Alessandro Vesely wrote in <[email protected]>: |On Mon 09/Jun/2025 18:44:05 +0200 Bron Gondwana wrote: |> On Mon, Jun 9, 2025, at 11:30, Alessandro Vesely wrote: |>> [...] As Dave said, there always will be legitimate scenarios |>> that match replay abuse scenarios. |> |> I think this is the root of our disagreement. I fundamentally disagree \ |> that there will be legitimate scenarios that match replay abuse scenario\ |> s with DKIM2. | |After your description, quoted below, I gather our disagreement stems \ |form the |term *replay abuse scenario*. | |Definition #1: Replay abuse is a message signed by a reputable domain |rebroadcast by a foreign MTA without re-signing it.
For ACDC: the original sender and the original recipient(s) are locked. You may modify or remove according info, but this breaks signatures. |Definition #2: Replay abuse is a message signed by a reputable domain |rebroadcast by a foreign MTA without recipient consent. What exactly is recipient consent? If you change the envelope, you need to re-setup the signatures, otherwise they break. |By definition #1, replay abuse is not possible within DKIM2. However, \ |if the |forwarder in turn DKIM2 signs the message for each new recipient (defini\ |tion |#2) it becomes formally indistinguishable from mailing list traffic. If i resend a message to someone else, or to the same persons, to whoever: i resend a message. If i have changed the envelope or the message itself beforehand, i have to create a new signature, to make the message verify. Nothing changes thus, it is the same as it ever was. However, with ACDC, all the modifications of the message up to the original sender can be verified (in the best case, say). This enables user interfaces to adopt -- which currently is impossible!! You can collect "organizational trust" (RFC 5863, section 2.5), which ACDC makes *very* easy, and, different to ARC which creates cryptographic seals on fishy data, cryptographically verifiable! This is a tremendous improvement i am hoping for for many years!! User interfaces can adapt, for example the MUA i maintain has "mlist" and "mlsubscribe" commands, so i could then say that [email protected] is allowed according to some "mailing-list template of modifications". Other than that you will not be able to automatize this completely *unless* you invent some kind of "authority database", as Mr. Chuang of Google i think it was envisioned. But even with an "organizational trust" database that was collected over a long time, and even in conjunction of the "Chuang DB" aka RPKI database, you will not be able to avoid what you call "replay", but what is not replay as i understand the words. For as long as identities can be stolen/misused, or whatever. By "replay" i understand that someone i capable to take *the original message*, and that is impossible, because it is cryptographically verifiable that you as a recipient was not addressed by the original sender. And UIs can adapt, cryptographically safe. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
