WG Review: Domain Keys Identified Mail (dkim)

The IESG <iesg-secretary@ietf.org> Tue, 20 December 2005 19:40 UTC

Received: from localhost.cnri.reston.va.us ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EonLg-0001fm-HQ; Tue, 20 Dec 2005 14:40:36 -0500
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EonLd-0001eC-4G; Tue, 20 Dec 2005 14:40:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24211; Tue, 20 Dec 2005 14:39:29 -0500 (EST)
Received: from [] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EonO6-0002ly-Pu; Tue, 20 Dec 2005 14:43:07 -0500
Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EonLZ-0007pQ-0J; Tue, 20 Dec 2005 14:40:29 -0500
Content-Type: text/plain
Mime-Version: 1.0
To: IETF-Announce@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <E1EonLZ-0007pQ-0J@newodin.ietf.org>
Date: Tue, 20 Dec 2005 14:40:29 -0500
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
Cc: ietf-dkim@mipassoc.org
Subject: WG Review: Domain Keys Identified Mail (dkim)
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: iesg@ietf.org
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
Sender: ietf-announce-bounces@ietf.org
Errors-To: ietf-announce-bounces@ietf.org

A new IETF working group has been proposed in the Security Area.  
The IESG has not made any determination as yet. The following draft charter was
submitted, and is provided for informational purposes only.  
Please send your comments to the IESG mailing list (iesg@ietf.org) by December


Domain Keys Identified Mail (dkim)


Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Russ Housley <housley@vigilsec.com>

General Discussion: ietf-dkim@mipassoc.org 
To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim
Archive: http://mipassoc.org/pipermail/ietf-dkim/


The Internet mail protocols and infrastructure allow mail sent from one domain
to purport to be from another. While there are sometimes legitimate reasons for
doing this, it has become a source of general confusion, as well as a mechanism
for fraud and for distribution of spam (when done illegitimately, it's called
"spoofing"). The DKIM working group will produce standards-track specifications
that allow a domain to take responsibility, using digital signatures, for having
taken part in the transmission of an email message and to publish "policy"
information about how it applies those signatures. Taken together, these will
assist receiving domains in detecting (or ruling out) certain forms of spoofing
as it pertains to the signing domain.

The DKIM working group will produce a summary of the threats that are addressed
by the proposed standards-track specifications, while acknowledging their
limitations and scope. The DKIM working group will also produce security
requirements to guide their efforts, and will analyze the impact on senders and
receivers who are not using DKIM, particularly any cases in which mail may be
inappropriately labeled as suspicious or spoofed.

While the techniques specified by the DKIM working group will not prevent fraud
or spam, they will provide a tool for defense against them by assisting
receiving domains in detecting some spoofing of known domains.
The standards-track specifications will 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
should discuss a reasonable set of possible actions and strategies, and analyze
their likely effects on attacks and on normal email delivery.
The DKIM working group will not attempt to establish requirements for trust
relationships between domains nor to specify reputation or accreditation

The DKIM working group will consider mailing-list behaviour that is currently
deemed acceptable, will make every effort to allow such mailing lists to
continue to operate in a DKIM environment, and will provide a plan for smooth
transition of mailing lists that fail to operate. The specifications will also
advise mailing lists on how to take advantage of DKIM if they should choose to
do so.

The signatures will use public-key cryptography and will be based on domain
name identifiers. Public keys needed to validate the signatures will be stored
in the responsible identity's DNS hierarchy. The specifications will be based on
the following Internet Drafts:

* draft-fenton-dkim-threats
* draft-allman-dkim-base
* draft-allman-dkim-ssp

which represent experimentation and consensus from a number of designers and
early implementors.

Since experimentation resulted in significant Internet deployment of these
specifications, the DKIM working group will make every reasonable attempt to
keep changes compatible with what is deployed, making incompatible changes only
when they are necessary for the success of the specifications.

The resulting protocols must meet typical criteria for success. In addition to
security, these include usability, scalability, ease of deployment, and
cryptographic algorithm independence.

To prevent this task from becoming unwieldy, several related topics are
considered 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.

Once the primary goals are met, the DKIM working group may also study whether
to adopt a work item for specifying a common mechanism to communicate the
results of message verification to the message recipient.
The generation of a standards-track specification on this topic will require an
update to the DKIM working group charter.

The deliverables for the DKIM working group are these:

* An informational RFC presenting a detailed threat analysis of, and security
requirements for, DKIM. IESG approval of this document is a prerequisite for the
submission of the standards-track specifications.
* A standards-track specification for DKIM signature and verification.
* A standards-track specification for DKIM policy handling.
* A standards-track specification for DKIM DNS Resource Record(s).
* An informational RFC providing an overview of DKIM and how it can fit into
overall messaging systems, implementation and migration considerations, and
outlining potential DKIM applications and future extensions.


02/06 WG last call on DKIM threats and security requirements
05/06 WG last call on DKIM signature specification
09/06 WG last call on DKIM policy specification
12/06 WG last call on DKIM DNS Resource Record
12/06 WG last call on overview document

IETF-Announce mailing list