-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
>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)
>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.
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.
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.
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).
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.
- --
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/AwUBaT8iuGHfC/FfW545EQIkcQCgndPlMk2mLFNc+3R/MhXTCMrB6RAAnijL
OMKgV0YK7yWQLgUAOfSfCaF1
=OAR4
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
