Hi!
On 12/14/25 21:48, Richard Clayton wrote:
In message <[email protected]>, Hannah Stern
<[email protected]> writes
Why can, in your example, the changes mv=3 to mv=5 not be coalesced?
That ought to be not so difficult algorithmically. (Similarly as one can
merge two consecutive "diff" patchsets into one without having the whole
file or running a full diff algorithm.)
as noted already, a "pipeline" may mean that several changes are made by
different processes and each records what they did. I don't think it is
at all difficult to deal with
Yes, that's what John also explained and makes sense to me. Thanks.
And once one coalesces the patchsets, the property would hold again that
each DKIM2-Signature (i=) has either 0 or 1 "patch" associated, like it
was in the older proposals (when it was still named DKIM2-Changes or
similar).
I can't see why this is a useful metric/property ... you hold two
arrays, one for each header type and process them separately (see below)
Yes. So the constraint is instead that for i_1 > i_2, mv_1 >= mv_2.
In what I see here, you'd have to check 2 sets of sequence numbers to
know that history doesn't go backwards (i.e. there's a monotonous
mapping from i= to mv=).
yes each set of headers needs to run from 1 to N and the v= values need
to be in ascending order with no gaps
what I believe you need to do (and some of this text will appear in the
next version of my I-D -- albeit I am trying to punt anything about
reputation to another document) is to
1 check that the highest numbered DKIM2-Signature header field is
correctly signed and the mf=/rt= for that appears to be correct. If
not then reject the message, otherwise you can conditionally accept
it (either by holding the SMTP session open while you cogitate, or
accepting the message and generating a DSN if you decide not to
accept the message after all). Note that if this signature works out
and other things are wrong then the previous hop screwed up (or is
wicked) and either way you can make it their problem to report the
delivery failure.
2 assess whether the hashes in the highest numbered Message-Instance
header field are correct for the state of the message at present. If
not then reject the message.
As hashes are fast, this can probably be easily done synchronously just
by the way of checking the signature (step 1 of yours).
3 use the recipes in that header field to recreate the previous state
of the message and then check that the hashes are correct. If not
then reject the message.
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?
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?
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. The body has will often
be more expensive (even if we cache it for all Message-Instances where
the body didn't change). Hashing is not expensive at all, and even
checking usual RSA signatures isn't so expensive. (Unless someone
creates a signing key specifically to vex verifiers, with many modulus
bits and with an unually high exponent. Talking of that, are there any
specified _upper_ limits for key modulus bits/exponent bits, to curb the
potential for partial denial of service attacks?)
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? 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)?
In bigger systems that would mean a distributed cache for this?
Kind regards,
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]
