Hi Richard,
Thanks, this helps. I just want to make sure I have correctly understood one
consequence of your answer, because I may be missing a constraint in the
current draft.
Consider a message which remains entirely within DKIM2-aware systems:
A (i=1) -> B (i=2) -> C -> D/Receiver
Suppose C receives the valid existing DKIM2 chain, but deliberately decides not
to continue it. Instead, C removes the existing DKIM2 history and starts a new
chain:
A (i=1) -> B (i=2) -> C
|
| discard existing chain
v
C (i=1) -> D/Receiver
Have I understood correctly that C is able to do this, and that D has no
protocol-level way to determine that the message previously had a valid DKIM2
chain?
In other words, would the result at D be indistinguishable from a message whose
DKIM2 history genuinely started at C?
I may have misunderstood the draft, or there may be a constraint that prevents
a DKIM2-aware intermediary from doing this. If so, could you point me to it?
If my understanding is correct, however, it seems that an intermediary can
deliberately discard authenticated history without the downstream verifier
being able to detect that this happened.
That feels like a limitation of the chain-of-custody model, so I would like to
make sure I am not overlooking something.
Best,
Pietro Mauri
-----Messaggio originale-----
Da: Richard Clayton <[email protected]>
Inviato: giovedì 27 agosto 2026 14:11
A: [email protected]
Oggetto: [Ietf-dkim] Re: R: Re: Non-participating nodes in the chain: an
interoperability gap, not a local-policy question
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]
93.PROD.OUTLOOK.COM>, MCN-IETF <[email protected]> writes
>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.
correct
>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
there is no "second chain" ... if you do not remove the existing
DKIM2-Signature records then your message will be malformed and it is most
likely to be rejected
>, can it determine in any way that
>this message previously had a DKIM2 chain which was interrupted or discarded?
no ... and why would a receiver wish to know that, or indeed why would it
consider your reporting of this information to be valid ?
>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"
yes
>rather than:
>
>"this is the original DKIM2 origin of this message"?
if history is discarded then it is gone : the notion that someone can attest to
you that they can reveal the history of a message to you is what underpinned
the ARC experiment. We have found that this is not valuable and so we are
moving on
>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?
absent any other meta-data and some fancy heuristics (or a signed attestation
from a notary passed out-of-band) yes
>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?
there is no "original message" that the receiver can identify, because there
are no signed recipes to construct it
>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.
DKIM2 can claim that there was a message before the first DKIM2-Signature was
applied by providing recipes in the i=1 instance.
Whether that is of any practical use to anyone is still to be determined by
interworking experiments. I would suggest prioritising running code so that you
can fully participate in those experiments
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBapApSGHfC/FfW545EQKzEQCfcISPPScUlZfrCX1XNu6Jsh9AgYkAnjRo
4bc0OCwsvyyvNUisHdNnOc9u
=SDqj
-----END PGP SIGNATURE-----
_______________________________________________
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/4hW0lP5GvszH2KJ/report-as-bad
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
