Last Call Review of draft-ietf-dkim-deployment-
review-ietf-dkim-deployment-secdir-lc-kaufman-2009-12-24-00

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

Specific suggestions:

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.

        --Charlie