Hi, I think the recent discussion has helped me understand the issue better, and I would like to add one consideration about the transition.
I understand Richard's point that accepting a broken Chain of Custody as if nothing had happened would weaken one of the main security properties DKIM2 is trying to provide. I do not think we should solve the interoperability problem by simply making a broken chain acceptable. At the same time, I am not sure that availability of a DKIM2 software update necessarily translates into rapid DKIM2 deployment. Updating software for security reasons and enabling a new authentication mechanism are rather different operational decisions. Even if DKIM2 support eventually becomes a simple package or milter update, an operator still needs to understand what enabling it will do to the existing mail flows. In a real environment there may be gateways, forwarders, mailing lists, DLP systems, security products and other intermediaries, some DKIM2-aware and some not. An operator may therefore have perfectly current software and still deliberately leave DKIM2 disabled until the consequences for those flows are understood and tested. This seems particularly important for domains which already have a mature DKIM1/DMARC deployment, perhaps with p=reject. I would be reluctant to change the authentication behaviour of such a production domain until I understood how DKIM2 Chain of Custody, i=1, alignment and DMARC interact across all the relevant paths. So I suspect the coexistence period may be determined less by how quickly DKIM2 code becomes available and more by how quickly operators can safely enable it. The recent discussion about restarting a chain also makes me wonder whether this points to a related policy question. We have established that a new valid i=1 does not necessarily identify the original origin of the message, and John confirmed that if an intermediary discards the previous chain and starts again, a downstream receiver may have no protocol-level way to know that the previous chain existed. John also pointed out that if the RFC5322.From remains in the original domain while the new i=1 signer uses another d=, the result is unaligned, and that such an i=1 would be expected to have poor reputation. This is where I wonder whether reputation alone is sufficient. Reputation can tell a receiver whether it trusts the new i=1 signer, but it cannot tell the receiver whether the RFC5322.From domain intended that signer to represent its identity. For example: From: [email protected] A (i=1) -> B (i=2) -> C | | previous chain no longer available v C (i=1, d=c.example) | v Receiver The new DKIM2 chain may be perfectly valid and C may even have an excellent reputation, but i=1 is not aligned with a.example. It seems to me that the owner of a.example should be able to express what receivers are expected to do in that situation. Some domains may be willing to tolerate an unaligned i=1, particularly during transition, while others may want it treated as an authentication failure, quarantined or rejected. That starts to look very much like a DMARC policy question to me. Perhaps this is also where Wei's proposal to consider DKIM2 and DMARC more holistically becomes important. DKIM2 can establish the cryptographic facts about the chain that is available, while a DMARC-like policy can say what the RFC5322.From domain expects when the first DKIM2 signer is, or is not, aligned. I am not proposing syntax here, and perhaps I am getting ahead of where the WG currently is. But after the discussion about chain restart and non-participating nodes, I am increasingly convinced that a DKIM2-aware evolution of DMARC, or an equivalent sender-published policy mechanism, may be necessary. Otherwise it seems that we have a very strong mechanism for establishing the validity of the available Chain of Custody, but no sender-controlled way to say what should happen when that chain begins with an identity which is not aligned with the identity presented to the user. Best, Pietro Mauri -----Messaggio originale----- Da: Richard Clayton <[email protected]> Inviato: domenica 30 agosto 2026 17:49 A: [email protected] Oggetto: [Ietf-dkim] 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]>, Vittorio <[email protected]> writes >>> How do you propose to do that? and which of the aims of this working >>> group will you ignore as you proceed? > >None of them and the how follows directly. > >The transition is handled by not rejecting good mail on a failure whose >cause cannot be determined. OK ... that's "local policy" ... go ahead > When b= verifies, the signing node's >signature is genuine and its own declaration is not in question. There is no b= in DKIM2 ... I assume you mean the body hash in the i=1 Message-Instance field is still correct. > But >content outside that guarantee can still change. By which I assume you mean all of the header fields and the Chain of Custody ... > In that case the >verifier cannot tell a non-participating legacy node from an attacker >exploiting the same absence. correct >This is where it differs from ARC and answers the trust objection >raised earlier. I am not asserting the hop was good. I am recording >that something failed and that its cause cannot be determined. There is >no assertion to trust: a node attests to the outcome of its own >verification, not to what happened upstream, and claims nothing about >prior state. Attestation of flow, not reconstruction of it. Provided that you do not send the message to strangers then this is all fine ... you can accept any email you wish. If you do send the email to someone else with a broken Chain of Custody then the DKIM2 spec says that it should be rejected. If you say that it should be accepted then DKIM2 becomes useless, so don't do that. >The mechanism does not remove replay protection; It will: ... at present at $DAYJOB$ see significant amounts of email sent from InvoiceCompany where the invoice says "congratulations on purchasing you iPhone, any issues call 01-555-123456". This is a genuine email from InvoiceCompany who has unwisely allowed BadPerson to sign up to their invoice issuing service. You cannot reject email as a replay on body contents hashes alone; you will end up rejecting lots of perfectly good email that is sent in bulk without personalisation (DKIM2 will not do that because of the Chain or Custody and the documentation of the SMTP protocol parameters). BUT by all means have a local policy with your own heuristics for replay detection; and by all means explain in the BCP why some local policies may make sense to some receivers. Just don't insist that any else adopt such policies. - -- 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/AwUBapRQ9WHfC/FfW545EQIBPACffKgWSn+9mLzaD/tgxF/kB5zLx2EAnjXC NIHl9WbC5ln+9/rCZSnFc6HK =J+yl -----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/4hXxTg2d4TzGprf/report-as-bad _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
