1 / 9

DKIM Reporting

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”

mitch
Download Presentation

DKIM Reporting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DKIM Reporting Murray S. Kucherawy <msk@sendmail.com>

  2. 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

  3. 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

  4. 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

  5. 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?

  6. 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

  7. 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

  8. 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

  9. 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

More Related