-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
>> 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)
>> 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
>> 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...
>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
>In bigger systems that would mean a distributed cache for this?
I am not going to comment on proprietary designs
- --
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/AwUBaUFJNmHfC/FfW545EQL+WACfbGAsjVLBunjyHDpLpgGeGv9lYjAAn3Ig
PiVW3cF3VS66r10TDYO1GILC
=hUOb
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
