The Domain Keys Identified Mail (dkim) working group in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Domain Keys Identified Mail (dkim) --------------------------------------------------- Current Status: Active Working Group Chairs: Stephen Farrell <stephen.farrell@cs.tcd.ie> Barry Leiba <barryleiba@computer.org> Security Area Directors: Tim Polk <tim.polk@nist.gov> Sean Turner <turners@ieca.com> Security Area Advisor: Sean Turner <turners@ieca.com> Mailing Lists: General Discussion: ietf-dkim@mipassoc.org To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim Archive: http://mipassoc.org/pipermail/ietf-dkim/ Description of Working Group: Internet mail protocols do not certify the validity of any identification information associated with a message, including the author's name and address. This limits the ability to determine legitimate accountability for a message. It also limits the ability to determine unauthorized uses of these identifiers. The DKIM working group has produced two standards-track specifications. The first allows a domain to take responsibility, using digital signatures, for having taken part in the transmission of an email message. The second allows a domain to publish information about its practices in applying those signatures. Taken together, these allow receiving domains to ascertain responsibility for a message, and possibly to detect some unauthorized assertions of authorship. While the techniques specified by the DKIM working group will not prevent fraud or spam, they can assist in efforts to establish a basis for identifying actors that can be trusted. The standards-track specifications do not mandate any particular action by the receiving domain when a signature fails to validate. That said, with the understanding that guidance is necessary for implementers, the DKIM documents discuss a reasonable set of possible actions and strategies, and analyze their likely effects on attacks and on normal email delivery. +++ Previous Work +++ The previously chartered deliverables for the DKIM working group have been completed. To provide background, we list them here: * An informational RFC presenting a detailed threat analysis of, and security requirements for, DKIM. (RFC 4686) * A standards-track specification for DKIM signature and verification. (RFC 4871, updated by RFC 5672) * A standards-track specification for DKIM policy handling. (RFC 5617) * An informational RFC providing an overview of DKIM and how it can fit into overall messaging systems, how it relates to other IETF message signature technologies, implementation and migration considerations, and outlining potential DKIM applications and future extensions. (RFC 5585 and draft-ietf-dkim-deployment, in its final stages) (One previously chartered deliverable, a standards-track specification for DKIM DNS Resource Record(s), was dropped by agreement between the working group and the Area Directors.) +++ New Work +++ The working group is now ready to switch its focus to refining and advancing the DKIM protocols. The current deliverables for the DKIM working group are these: 1. Advance the base DKIM protocol (RFC 4871) to Draft Standard. This is the first priority for the working group. 2. Collect data on the deployment, interoperability, and effectiveness of the base DKIM protocol, with consideration toward updating the working group's informational documents. 3. Collect data on the deployment, interoperability, and effectiveness of the Author Domain Signing Practices protocol (RFC 5617), and determine if/when it's ready to advance on the standards track. Update it at Proposed Standard, advance it to Draft Standard, deprecate it, or determine another disposition, as appropriate. 4. Taking into account the data collected in (2) and (3), update the overview and deployment/operations documents. These are considered living documents, and should be updated periodically, as we have more real-world experience. 5. Consider issues related to mailing lists, beyond what is already documented. This includes considerations for mailing list software that supports or intends to support DKIM, as well as considerations for DKIM/ADSP deployment in the presence of mailing lists that do not have such support. Include recommendations in the informational documents, or produce a new informational document about mailing-list considerations. +++ What's Out Of Scope +++ As before, several related topics remain out of scope for the DKIM working group. These topics include: * Reputation and accreditation systems. While we expect these to add value to what is defined by the DKIM working group, their development will be separate, and is out of scope for the DKIM working group. * Message content encryption. * Additional key management protocols or infrastructure. * Signatures that are intended to make long-term assertions beyond the expected transit time of a message from originator to recipient, which is normally only a matter of a few days at most. * Signatures that attempt to make strong assertions about the identity of the message author, and details of user-level signing of messages (as distinguished from domain-level keys that are restricted to specific users). * Duplication of prior work in signed email, including S/MIME and OpenPGP. Goals and Milestones: Jul 2010 DKIM base (RFC 4871) interoperability report Nov 2010 WG last call on update to RFC4871 if necessary for advancement to DS Dec 2010 WG last call on an I-D addressing issues related to mailing lists Dec 2010 WG last call on an I-D detailing deployment and effectiveness data for DKIM base Dec 2010 WG last call on an I-D detailing deployment and effectiveness data for ADSP Mar 2011 Update overview and deployment informational RFCs as appropriate, and/or produce one or more new informational RFCs from information obtained above _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
