Last Call Review of draft-ietf-dkim-deployment-
I am reviewing this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Feel free to forward to any appropriate forum.
This document covers development, deployment, operations, and migration considerations for DKIM (DomainKeys Identified Mail). I would expect such a document to give guidance to implementers and deployers of this technology that couldn't be included in the standards track documents because the standards wanted to allow flexibility to implementers and deployers. Such guidance would be particularly useful with DKIM because it's not at all obvious how to use it from the specs and if everyone makes those decisions independently it will limit the usefulness to everyone.
Unfortunately, it appears that there hasn't been enough real world experience with DKIM yet to provide a lot of useful guidance. This document seems more of a tutorial on DKIM than guidance. I have no problems with the guidance it gives (other than it mostly duplicates the contents of other specs), but there is a lot more that it would be good to have (assuming anyone has answers).
In Section 7.3, the document mentions problems likely to be introduced if Author Domain Signing Practices (ADSP) is enabled. There are common practices in mail processing that will cause email to be dropped if these practices are followed, and it would be useful to have an explicit list of things known to fail and their prevalence. For example, mailing list expanders (like the ones that got this message to most of you) are likely to break the DKIM signatures on messages they pass, causing those messages to subsequently be dropped by receiving agents if the sender has enabled ADSP. It would be good to know which of the common mail forwarders have this problem and give advice to the authors of mail forwarders as to how to avoid problems in the future. The most general solution is for the forwarder to change the "From: " field in the email message to itself and copy the name of the actual sender somewhere else. But that causes other problems. Similarly, there have been in the past many web sites that let you "mail a copy of this document to a friend" and let you specify the friend's email address and your own. ADSP would delete such mail sent by users who used such a web site if the site forged the "From:" field. I've noticed that practice is decreasing (Dilbert.com doesn't do it anymore). Guidance to web sites not to do that and to users about how much trouble to expect would be useful.
DKIM allows the signer to choose which header fields in the message are signed. Guidance on which fields should be signed and which should not would be helpful.
When rolling over keys, it's a matter of sender policy how long the old signing key should remain valid for verification after it is no longer used for signing. It would be good to hear a recommendation as to how long that should be. This would be coupled with guidance to verifiers as to how long after email is received it should be expected to be verifiable. Is it reasonable to wait until logs in and reads mail, or must it be checked as part of placing the mail in the user's inbox? Do we expect to change keys every few hours or every few years?
It probably belonged in the original DKIM spec, but it would be good to know how DKIM is supposed to interact with S/MIME or OpenPGP.
It appears DKIM allows the signing of only the first 'n' bytes of a message in order to give better performance. Advice and rationale for picking an 'n' would be helpful.
On page 8, quoting RFC5672 on the issue of interpretation of the d= and i= fields, this document says "To the extent that a receiver attempts to intuit any structured semantics for either of the identifiers, this is a heuristic function that is outside the scope of DKIM's specification and semantics." While true, the purpose of those fields is so that the receiver can intuit something from them. While DKIM may not specify the semantics to allow implementers flexibility, this document should suggest possibilities and report on existing practice (if any).
Another area where guidance would be useful is in what a receiving agent should display to users concerning DKIM signed messages. Perhaps the answer is *nothing*, where DKIM is only used as one of many heuristics for spam filtering. But either way, it would be good to know. If we expect users to configure some signers as good, advice as to how they are expected to learn what to do would also be helpful.
Section 8.4 begins "It is expected that the most common venue for a DKIM implementation will be within the infrastructure of an organization's email service". Section 8.5 begins "The DKIM specification is expected to be used primarily between Boundary MTAs...". I don't believe these can both be true. I'm more inclined to believe the latter because within an organization the organization can just filter email coming from the Internet and making sure the return address is not within the organization.