Hi! On 12/16/25 12:57, Richard Clayton wrote:
In message <[email protected]>, Hannah Stern <[email protected]> writes
On 12/14/25 21:48, Richard Clayton wrote:
4 repeat until you get back to the original state of the message or a "z" recipe tells you that you need to unconditionally trust someone... they presumably have placed an Authentication-Results header field into the message and you have to use that for your DMARC and/or reputation calculations.
I guess in this case A-R has to be signed? What handling is suggested in such a "z" case if you _don't_ trust the modifier?
if you don't trust someone who modifies a message then I think you should refuse to accept the message.
One of the features of DKIM2 is that it allows you to (a) identify who changed a message and (b) assign a reputation to the associated signer... however, how you actually use that reputation is out of scope for a protocol spec
Makes sense, thanks.
5 Check the DKIM2-Signature for the lowest numbered Message-Instance that you reached. IF this is 1 then you will use the From header field for you DMARC assessment.
Is this kind of alignment still delegated to DMARC or a part of DKIM2 now? I.e. is it a DKIM2 requirement that the i=1 signer domain aligns not only with the i=1 mf= address, but also with From?
We are not touching DMARC ... but I expect that DMARC will revise relevant documents to say "DKIM2" rather than "DKIM" in appropriate places ... However, since DMARC is all about the From: header field, I expect a revised document would discuss how best to handle situations where that header field has been altered (noting that the reason for many such modifications disappears in the DKIM2 world)
So theoretically with DKIM2 without DMARC we'd only verify the mf= values, but not look at From at all (except for hashing it into the signature)? Only in DKIM2 with DMARC we'd check alignment between the i=1 signature and the From in the matching Message-Instance? (Or would we check the From as we see it if one of the signatures that has this version of From aligns with it? Or both?)
(I know that technically this Work Group doesn't touch DMARC, but as there's some overlap in persons involved, perhaps there's already an idea how DMARC and DKIM2 might be specified to overlap. Also things like if in a DMARC+DKIM2 world we'd retire the alternative of SPF alignment...)
6 Check that the mf= rt= chain is correct to avoid DKIM replay attacks.
I currently think this means checking all the DKIM2-Signature header fields because someone may have done a replay attack by forging a header field. This is disappointing in that we had hoped to avoid "check everything" -- however, since the DKIM2-Signature field header signatures are calculated over only a few header fields it should not be super-expensive to do this and if you can duplicate intermediate states of your hash function then you can do an O(N) calculation rather than O(N-squared).
As hash functions are fast compared to RSA, I wouldn't worry about whether we hash all header fields or just a few.
there is a not entirely insignificant cost to unwrapping and normalising the header fields. You can do that only once (or process line segments without a copy) but those algorithmic choices have to be traded off against your working memory budget
I'm not sure how many DKIM2 verifiers would run on very constrained hardware. My personal experience is more on "generic" somewhat modern server hardware, where some MB of memory and many millions of CPU cycles don't hurt so much. (And most SHA256 implementations allow incremental hashing, so there's no need to keep all of the canonicalized header in RAM at once if one wants to reduce memory footprint. In comparison it would probably take a bit more effort to not keep the full body of an intermediate Message-Instance in RAM.)
7 If the message has been marked to be "exploded" then use the reputation of system that did this to assess how many copies of the message you are prepared to accept -- if there is no explosion declared and you receive multiple copies of the message then there is an attack going on.
Would that step be mandatory?
if you want to avoid DKIM replay you will need to test for it occurring; now the mf= rt= stuff may help you a bit, but a malicious sender can explode a message without declaring they have done so...
If they explode it to different recipients they have to declare it in rt=, don't they? So it's no difference if they explode _one_ message and sign the exploded versions or if they originate several unrelated messages and sign each of them?
That would mean keeping a cache of relevant information. But what's the lookup key? Body hash? Body hash plus certain headers? mv=1 body hash/headers (hashed)?
I think the DKIM2-Signature value is the best key ... but you may be able to use others
So there's no exact specification what counts as "same message, but exploded" in contrast to "many different messages"?
In bigger systems that would mean a distributed cache for this?
I am not going to comment on proprietary designs
Fair. Hannah. -- Hannah Stern Software Developer Mail Transfer Development 1&1 Mail & Media Development & Technology GmbH | | | Phone: +49 721 91374-4519 E-Mail: [email protected] | Web: www.mail-and-media.com www.gmx.net www.web.de www.mail.com www.united-internet-media.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452 Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Thomas Ludwig, Dr. Verena Patzelt Member of United Internet Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that saving, distribution or use of the content of this e-mail in any way is prohibited. If you have received this e-mail in error, please notify the sender and delete the e-mail. _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
