DKIM Reporting

Murray S. Kucherawy

<msk@sendmail.com>

The Problems to Solve

• Senders want to know when their brands are being violated– Mail being forged as coming from the sender

• Unsigned when DKIM policy is “all” or “strict”• Unauthorized third-party signatures when DKIM policy is

“strict”• Forged signatures, replay attacks

– Compromised or revoked keys

• Senders want to know when their mail is getting munged enroute– Such as by mailing list managers

The Problems to Solve

• Senders want to know if what they’re doing doesn’t work– New hashes, algorithms that are not yet widely

deployed• Implementors want to get back forensic

evidence when verification failures occur– Especially important at the Interop event

• Participants were asked to make sure their autoresponders returned forensic data on failures

– Need to get back canonical forms seen at the verifier• To compare what the verifier got to what the signer signed• Pinpoints in-transit modifications

Issue(s)

• Volume of mail generated by this can be big, of course– But the people making the request appear to

know that and are willing to take the risk– Proposal will have to discuss this, possibly

using deliberately scary language

Requirements

• Based on consensus on ietf-dkim• Senders need to be able to indicate that they

want to get these reports– Maybe break them down by type: unsigned,

verification failures, expired signatures, syntax errors, general policy failures, other kinds?

• Senders need to be able to specify where the reports should be sent

• Senders need to be able to indicate what format(s) they want– ARF? INCH? Something else?

Proposal

• A new draft which defines several extensions– Adds “r=“ tag to keys in DKIM base

• Presence indicates reports are desired for failures involving that particular key; value indicates to where they should be mailed

– Adds “r=“ tag to DKIM SSP• Presence indicates reports are desired for

unsigned mail and policy failures; value indicates to where they should be mailed

Proposal

• …also:– Adds “rf=“ tag to keys in DKIM base

• Enumerates acceptable report formats (e.g. ARF, INCH, something else)

• Maybe also need a way to request reports about specific types of failures that are of interest (see earlier slide)

– Adds “rf=“ tag to DKIM SSP• Same deal

Proposal

• …also:– Updates the current (-03) ARF draft, adding

fields to the message/feedback-report format needed to provide DKIM verification failure forensics

• Canonicalized headers• Maybe the canonicalized body• Maybe base64-encoded to ensure no changes in

transit• Maybe what was retrieved in the key and/or SSP

record as well, in case they change

Draft

• draft-kucherawy-dkim-reporting– Ignore the one that’s up there

• More of a placeholder• Was an idea under development• Needs examples

– Wait for -01• Will post it soon

– Should probably become a DKIM WG draft after that