FYI:
[NOTE:] This draft is based on the Problem Statement developed by
Wei Chuan and others (including me) over some months. This
version is offered as a refinement of that draft, with a
tighter focus. Rather than being a 'separate' document, it
should be treated as an aggressive edit of that draft. It has
only my name on it, for now, since the revisions and decision
to post it were only made by me, albeit with some advice from
the WG Chairs.
If this draft is adopted by the working group, I believe the
document's authorship needs to revert to the list currently on
Wei's version. /Dave
Name: draft-crocker-dkim-replay
Revision: 00
Title: DKIM Replay: Problem Statement
Document date: 2023-03-08
Group: Individual Submission
Pages: 11
URL: https://www.ietf.org/archive/id/draft-crocker-dkim-replay-00.txt
Status: https://datatracker.ietf.org/doc/draft-crocker-dkim-replay/
Html: https://www.ietf.org/archive/id/draft-crocker-dkim-replay-00.html
Htmlized: https://datatracker.ietf.org/doc/html/draft-crocker-dkim-replay
Abstract:
DomainKeys Identified Mail (DKIM, RFC6376) permits claiming some
responsibility for a message by cryptographically associating a
domain name with the message. For data covered by the cryptographic
signature, this also enables detecting changes made during transit.
DKIM survives basic email relaying. In a Replay Attack, a recipient
of a DKIM-signed message re-posts the message to other recipients,
while retaining the original, validating signature, and thereby
leveraging the reputation of the original signer. This document
discusses the resulting damage to email delivery, interoperability,
and associated mail flows. A significant challenge to mitigating
this problem is that it is difficult for receivers to differentiate
between legitimate forwarding flows and a DKIM Replay Attack.
--
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
