Hi,
As I understand the recent discussion, if an intermediary receives a message
for which the existing DKIM2 chain can no longer be continued, it may remove
the previous DKIM2 information and start a new chain with m=1, i=1.
If that is correct, I am wondering what the final receiver can actually know
about the history before the new i=1.
For example:
A (i=1) -> B (i=2) -> legacy intermediary -> C
|
DKIM2 chain lost
C -> new DKIM2 chain (i=1) -> D -> Receiver
When the Receiver verifies the second chain, can it determine in any way that
this message previously had a DKIM2 chain which was interrupted or discarded?
Or, from the Receiver's point of view, is this indistinguishable from a message
whose DKIM2 history genuinely started at C?
In other words, does i=1 only mean:
"this is the beginning of the DKIM2 chain that I can verify"
rather than:
"this is the original DKIM2 origin of this message"?
If the previous chain is completely removed, I assume the Receiver cannot
distinguish between a legitimate restart after a legacy intermediary and
someone simply removing an existing DKIM2 chain and starting a new one. Is that
correct?
There is also a related identity question. If a DKIM2 intermediary discards an
existing chain and starts a new one at i=1, what authenticated identity, if
any, can a Receiver associate with the original message, as opposed to the
identity represented by the new i=1 signer?
I am mainly trying to understand exactly where the cryptographically verifiable
history starts and, equally importantly, whether DKIM2 gives the Receiver any
indication that some history existed before that point.
Best,
Pietro Mauri
-----Messaggio originale-----
Da: William Weiner <[email protected]>
Inviato: giovedì 27 agosto 2026 00:36
A: vmoccia <[email protected]>
Cc: Ietf Dkim <[email protected]>
Oggetto: [Ietf-dkim] Re: Non-participating nodes in the chain: an
interoperability gap, not a local-policy question
On Wed, 26 Aug 2026, Vittorio wrote:
> [...] Delegating that to local policy does not resolve the
> interoperability question; it declares that the specification will not
> address it.
The point about layer is well-stated. Local policy cannot govern whether two
implementations interoperate across a path they do not both control.
Re-originating services are a related sub-case worth naming alongside the
non-participating-node case. Unlike a non-participating node that breaks the
chain incidentally, a re-originator - alias service, privacy-preserving mailing
list, and similar - terminates the inbound message and originates a new one
intentionally. The result at the final receiver is the same: a valid single-hop
DKIM2 signature with no prior chain. From the message alone, the receiver
cannot distinguish legitimate re-origination from a stripped one.
The "I dunno" third state you and Bron describe is the right shape for both
cases. What is missing from the BCP is the definition that tells a receiver
when "I dunno" is the correct verdict for a legitimate reason, versus when it
should be treated as suspicious. Without that definition, local policy fills
the gap - which, as you note, is the wrong layer.
Proposed definitional text for the re-originator case is at GitHub Issue #2 on
dkim2wg/spec, filed June 2026 with no WG response to date:
https://urlsand.esvalabs.com/?u=https%3A%2F%2Fgithub.com%2Fdkim2wg%2Fspec%2Fissues%2F2&e=b336b1a5&h=32f539b0&f=n&p=y&m=4hVfdD47YfzH1pc
William Weiner
Weiner Advanced Development LLC / EMail Parrot (emparrot.com)
> From: Vittorio <[email protected]>
> To: "Ietf Dkim"<[email protected]>
> Date: Wed, 26 Aug 2026 08:15:29 -0600 > Subject: [Ietf-dkim]
> Non-participating nodes in the chain: an interoperability gap, not a
> local-policy question > > Hello.
>
> The chain-of-custody model in draft-05 shares a property with any DKIM2 >
> design built on the same foundation: it assumes the modifying parties on >
> a path participate in the chain. Section 7 addresses the transparent > case
> explicitly - an MTA that changes nothing "need not be made DKIM2 > aware."
> That is correct and welcome. What is not addressed is the other > case: a
> node that is not DKIM2-aware and does modify the message - a > list
> rewriting a Subject and appending a footer, a gateway altering the > body.
> This breaks the chain and it is not an edge case; during > coexistence it
> is the common case, for as long as any non-participating > node sits on
> ordinary delivery paths.
>
> When this was raised earlier, the response was that such a message falls >
> to local policy. I want to be precise about why that answer does not fit >
> the problem. Local policy governs what a receiver does with a message - >
> accept, reject, flag. It cannot govern whether two implementations >
> interoperate across a path that includes a node neither of them > controls.
> A chain broken by a non-participating node produces, at the > next hop, a
> verification failure whose cause cannot be determined from > the message
> alone: it is indistinguishable from an attacker who altered > the same
> content after signing. Delegating that to local policy does not > resolve
> the interoperability question; it declares that the > specification will
> not address it. For a problem that is, at its root, > about
> interoperability during a multi-year transition, that is the wrong > layer
> to leave it at.
>
> Bron has just raised the adjacent case - a signature that verifies but >
> uses an algorithm a downstream verifier does not understand - and asked >
> for a way to signal that failure explicitly rather than let mail >
> disappear silently. John's reply already sketches the shape of the >
> answer: a feedback mechanism reporting, per signature, "good, bad, or I >
> dunno." The non-participating-node case is the same shape in a more >
> severe form and it needs exactly that third value. When a prior seal is >
> broken by a node that never entered the chain, the downstream hop cannot >
> determine the cause from the message alone - "I dunno" is the honest and >
> only correct verdict - yet it still needs to record that the break >
> predates its own handling and carry the message forward flagged, rather >
> than reject it blind or accept it without record. The mechanism Bron and >
> John are converging on for the algorithm case answers this one too.
>
> I raise this now because draft-05 has closed several open points but not >
> this one and because it is structural: it sits in the foundation both > the
> base specification and any conforming profile share, not in any > optional
> layer where the two differ.
>
> Regards,
> Vittorio Moccia
>
> _______________________________________________
> Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email
> to [email protected] >
_______________________________________________
Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to
[email protected]
--
Questo messaggio e' stato analizzato con Libraesva ESG ed e' risultato non
infetto.
Seguire il link qui sotto per segnalarlo come spam:
https://mail2.mcnsrl.it/action/4hVfdD47YfzH1pc/report-as-bad
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
