Hello Pietro,
your questions are good and I think they become clearer once two cases
that this thread has run together are separated, because they have
different answers.
Case one: intentional re-origination. An intermediary deliberately
terminates the inbound chain, discards the prior DKIM2 headers and signs
afresh as i=1. Here the loss of history is not a failure; it is the
point. A privacy-preserving relay, an alias service, exists precisely to
not carry the prior state forward. The resulting i=1 is
indistinguishable from any other first-hop origination and that is
correct, not a gap. The receiver does not need to recover the prior
history, because responsibility attaches to the act of signing at i=1:
whoever signs takes full accountability for the message they present,
whether they composed it, generated it or admitted it from a DKIM1
source.
So to your question: i=1 does not assert 'the genuine origin of this
message'; it asserts that whoever signs there takes responsibility from
that point on. What preceded it is not represented because no one
carried it forward and for this case that is the correct outcome, not a
missing capability. The absence of a prior chain is the normal state of
any message entering DKIM2 for the first time and treating it as
suspicious is not implementable in any case: the receiver has no
reliable signal to act on. Received headers are not one, they are
mutable and vary legitimately in countless ways, so a heuristic built on
them could reject a great deal of ordinary mail.
Case two: a non-participating node in the path. This is the case I
raised and it is a different situation. Here no one intentionally
re-originates. A node that is not DKIM2-aware - a forwarder performing
SRS, a list, a DLP gateway - alters the message in transit and breaks
the chain without declaring anything, because by definition it cannot.
There is no deliberate restart, only an incidental break. And here the
receiver's position is genuinely different from case one: the failure it
sees is indistinguishable from an attacker who altered the same content
after signing. From the message alone, a legitimate legacy transit and a
malicious alteration produce the identical signal.
This is where a per-hop result record matters, and it is worth being
precise about what it does and does not claim. It does not ask the
receiver to trust an assertion about history: that was ARC's model and I
understand the reservations about it. It makes a narrower statement: "at
my hop, verification of the prior signature failed". That is an
attestation a node makes about its own act of verification, not a claim
about what some other party did upstream. The receiver need not believe
anyone's account of the message's past; it only learns that the break
was already present at a given hop. During the transition that is enough
to do the one thing that matters: carry the message forward flagged
rather than reject it blind, because the cause of the failure, a broken
DKIM2 participant versus a legacy non-participant, cannot be determined
from the message and rejecting on an undeterminable cause discards
legitimate mail along with the rest.
So to your underlying question - where does cryptographically verifiable
history begin - it begins at i=1 in both cases. The difference is that
in case one the absence of anything before i=1 is deliberate and
unremarkable, while in case two something was there and was broken by a
node that never participated and the receiver benefits from knowing that
much, without needing to know more.
Regards,
Vittorio Moccia
Il 2026-08-27 12:32 MCN-IETF ha scritto:
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)
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
