Hello all, I am concerned with the phishing implications of recipes. For example, for irs.gov or paypal.org the phishing potential seems quite high of being able to modify URLs, dollar amounts, sending instructions or other key information with recipes and still having a DMARC pass. I understand that the recipes allow uncovering who the malicious actor was. But detection algorithms will never be perfect and with the current UX that most mail providers use, any mail that slipped past those detection algorithms using recipes would be an extremely convincing phishing attack.
I would love to hear people's general thoughts on this topic and any potential solutions they have in mind. To start the conversation, two specific proposals I thought of that might help (though I'm open to alternative solutions): 1) Move the current paragraph in the BCP <https://www.ietf.org/archive/id/draft-ietf-dkim-dkim2-bcp-00.html#section-5.7-1> on "Continue doing From munging" to be a MUST under the body recipe section of the spec <https://datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-spec/>, and require verifiers to also verify that the visible fromHeader matches the envelope MAIL FROM when verifying a recent Body Recipe hop. Since this risk is specifically caused by the body recipe section. The lack of fromMunging from the IETF reminded me of the importance of moving this from a suggestion to a required part of the verification step. Otherwise, the IETF mailing list would go from taking ownership of messages and having a clear DMARC fail to suddenly having a DMARC Pass for the original senders. 2) For "11.1. Output States" distinguish PASS from PASS - RECIPE. To me, the ability to achieve a pass while changing the content is concerning enough that it needs to be a clearly distinguished PASS state. This doesn't by itself change anything, different receivers can have different handling of PASS - RECIPE. But it will make the semantics clear (e.g. in the Gmail "Show Original" tab which shows the DKIM result) and allow DMARCbis/BIMI to have more granular handling when they are updated to decide how to handle DKIM2. Best, Emanuel
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
