Hello.
To fix utter rubbish on what i had said, the ACDC draft does not
encrypt the subsignature because the RFC 5321 envelope data is
anyway known during the transit of the per-receiver-domain
message. (Which is different to the original approach: one
message for all receivers. Still envelope data is not public.)
I have never excluded myself from the list of gross incompetence.
But.
While writing an explicit paragraph on man-in-the-middle replay
because Michael Thomas said what he said -- and the optional ACDC
(bounce) id is now larger to support RFC 9562 UUIDs --, i stumbled
over the wording of dkim2's "nonce". (One, that is me, can be
scared this really makes it.)
Even though the dkim2 SECURITY section is not yet written, i think
it should be made clear that "may well be used as an index into
a database to access meta-data about an email that has been
handled in the past" can only talk about the sender, not the
receiver side -- this is a denial of service attack surface.
Whereas in practice one would surely sub-divide by d= (talking
DKIM v1 here), and likely add some kind of hardening (like
SipHash) on top, and could umbrella it all under "organizational
trust" of RFC 5863, it still is valid to say this is a DoS. So it
should be addressed. I'll add that to ACDC:
The optional "bounce identifier" offers enough room to store
Universally Unique IDentifiers<xref target="RFC9562"/>.
It <bcp14>MAY</bcp14> be generated to help sending domains
to uniquely identify messages within the DKIM t= and x= time delta.
Receiving domains should not use this identifier due to the
denial of service attack surface,
regardless of collected organizational trust (see R flag).
and
<em>Informative remark:</em>
Space constraints resulting from maintaining an identity cache
may be addressed by timing out entries by minutes or hours not seconds,
by partitioning the cache through DKIM d= tag values,
and by using a hash-attack proven message-digest output
instead of message (signature) content data for keys.
To selectively garbage collect cache entries on memory shortage,
collected reputation (see R flag) may be used.
And, while here, i throw into the non-existing discussion my words
To address replay attacks by man-in-the-middle
the DKIM x= tag <bcp14>MUST</bcp14> be used.
The maximum t= to x= delta <bcp14>MUST</bcp14> not be greater than
864000 seconds (ten days: to reach into the next working week).
Example delta values for tag auto-generation may be the bounce defaults
432000 seconds (five days: used for example by
the Mailman2 and mlmmj mailing-list managers and the postfix MTA),
345600 seconds (four days: OpenSMTPD MTA),
172800 seconds (two days: Exim MTA).
DKIMACDC aware receivers <bcp14>SHOULD</bcp14> keep a cache of
received message identities to address this kind of replay attack
during delta validity.
Ach, that bcp14. Writing IETF standards turns one into
a regulating maniac, screaming in UPPERCASE all the time.
Sigh.
Anyhow. The above "ten days" i want to throw in as a comparison
to the 7 that dkim2 uses, Mailman2 does not seem to use it, but
documents it (or past tense since it is now Mailman3 that i do not
know; many still run 2 though), and that is difference in between
hard and soft bounce, meaning the latter doubles the timeout: with
that we come to ten days for Mailman2. It could be this is in the
head of (quite some) people (the real timeout is configurable
anyway), so ...
Anyhow i like my ten days because there *are* nations which do
"not have a gross national product, but a gross national
happiness" (which is a citation).
More jck style, i hope.
Ciao,
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
