On 9/2/2023 7:29 AM, Jesse Thompson wrote:
On Tue, Aug 29, 2023, at 9:02 PM, Dave Crocker wrote:
DKIM, SPF, et al, are all 'collaborative' mechanisms. Originators
and receivers opt in to use them. Both sides are necessary. So I'm
wondering about looking for something the furthers the collaboration.
The lack of reporting to the originating DKIM signers about Replay and
other kinds of DKIM failure modes is an example of "limitations at the
sending side [...] trying to detect". Alex and I are starting to draft
a proposal for receivers to report to signers using rfc5965 and
rfc7489 semantics.
Since a Replay Attack has the act of replaying being done by an
attacker, it would not help to have a reporting mechanism for DKIM,
because the attacker would not use it.
If you are thinking of reporting by the later receiving platform, how
would this get used?
And the attacker can't bypass it, if the signature covers enough (or
all) of the message.
The "new header field" (or similar) approach alone would not open any
doors for revocation/invalidation of the fact that the signature was
applied on that first single message. Relying solely on fast key
rotation/invalidation would mean TTLs would need to be very low to
have any effect.
Keys cannot be rotated fast enough to be useful within the time frame
that attackers work in.
Key rotation works in a timeframe of days or weeks. Attackers work in
the timeframe of minutes.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
