draft-ietf-dkim-overview-00.txt   draft-ietf-dkim-overview-01.txt 
Internet Engineering Task Force T. Hansen, Ed. DomainKeys Identified Mail T. Hansen
Internet-Draft AT&T Laboratories Internet-Draft AT&T Laboratories
Expires: December 20, 2006 D. Crocker Expires: December 27, 2006 D. Crocker
Brandenburg InternetWorking Brandenburg InternetWorking
P. Hallam-Baker P. Hallam-Baker
VeriSign Inc. VeriSign Inc.
June 18, 2006 June 25, 2006
DomainKeys Identified Mail Overview DomainKeys Identified Mail (DKIM) Service Overview
draft-ietf-dkim-overview-00.txt draft-ietf-dkim-overview-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 20, 2006. This Internet-Draft will expire on December 27, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
DomainKeys Identified Mail DKIM [I-D.ietf-dkim-base] defines a DomainKeys Identified Mail (DKIM) associates a "responsible" identity
domain-level authentication framework for email using public-key with a message and provides a means of verifying that the association
cryptography and key server technology to permit verification of the is legitimate.[I-D.ietf-dkim-base]. DKIM defines a domain-level
source and contents of messages by either Mail Transfer Agents (MTAs) authentication framework for email using public-key cryptography and
or Mail User Agents (MUAs). The ultimate goal of this framework is key server technology to permit verification of the source and
to permit a signing domain to assert responsibility for a message, contents of messages by either Mail Transfer Agents (MTAs) or Mail
thus proving and protecting message sender identity and the integrity User Agents (MUAs). The ultimate goal of this framework is to permit
of the messages they convey while retaining the functionality of a signing domain to assert responsibility for a message, thus proving
Internet email as it is known today. Proof and protection of email and protecting message sender identity and the integrity of the
identity, including repudiation and non-repudiation, may assist in messages they convey while retaining the functionality of Internet
the global control of "spam" and "phishing". email as it is known today. Proof and protection of email identity,
including repudiation and non-repudiation, may assist in the global
control of "spam" and "phishing".
This document provides an overview of DomainKeys Identified Mail and This document provides an overview of DomainKeys Identified Mail and
how it can fit into overall messaging systems, how it relates to how it can fit into overall messaging systems, how it relates to
other IETF message signature technologies, implementation and other IETF message signature technologies, implementation and
migration considerations, and outlines potential DKIM applications migration considerations, and outlines potential DKIM applications
and future extensions. and future extensions.
Note Note
This document is being discussed on the DKIM mailing list, This document is being discussed on the DKIM mailing list,
ietf-dkim@mipassoc.org. ietf-dkim@mipassoc.org.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. About This Document . . . . . . . . . . . . . . . . . . . 5 1.1. About This Document . . . . . . . . . . . . . . . . . . . 4
1.2. A Quick Overview of DKIM . . . . . . . . . . . . . . . . . 5 1.2. A Quick Overview of DKIM . . . . . . . . . . . . . . . . . 4
1.2.1. Axiom: Ubiquitous Authentication is Good . . . . . . . 5 1.3. Outline Potential DKIM Applications . . . . . . . . . . . 7
1.2.2. What is the purpose of DKIM? . . . . . . . . . . . . . 6 2. DKIM Within Existing Internet Email . . . . . . . . . . . . . 7
1.2.3. What does DKIM do? . . . . . . . . . . . . . . . . . . 7 2.1. Review of Internet Mail Service Architecture . . . . . . . 7
1.2.4. Who validates the signature? . . . . . . . . . . . . . 7 2.2. Where to Place DKIM Functions . . . . . . . . . . . . . . 10
1.2.5. What does DKIM *not* do? . . . . . . . . . . . . . . . 7 2.3. Impact on Email Activities . . . . . . . . . . . . . . . . 11
1.3. Outline Potential DKIM Applications . . . . . . . . . . . 8 2.4. Migrating from DomainKeys . . . . . . . . . . . . . . . . 12
2. DKIM Within Existing Internet Email . . . . . . . . . . . . . 8 2.5. { Misc Text -- Should go elsewhere, if used at all } . . . 13
2.1. Where to Place DKIM Functions . . . . . . . . . . . . . . 8 3. DKIM Within Existing Internet Email . . . . . . . . . . . . . 14
2.2. Impact on Email Activities . . . . . . . . . . . . . . . . 8 3.1. Review of Internet Mail Service Architecture . . . . . . . 14
2.2.1. Resources . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Where to Place DKIM Functions . . . . . . . . . . . . . . 17
2.2.2. Operations . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Impact on Email Activities . . . . . . . . . . . . . . . . 17
2.2.3. Users . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Migrating from DomainKeys . . . . . . . . . . . . . . . . 18
2.3. Migrating from DomainKeys . . . . . . . . . . . . . . . . 9 3.5. { Misc Text -- Should go elsewhere, if used at all } . . . 19
2.3.1. Signing . . . . . . . . . . . . . . . . . . . . . . . 9 4. DKIM Service Architecture . . . . . . . . . . . . . . . . . . 21
2.3.2. Verifying . . . . . . . . . . . . . . . . . . . . . . 10 5. Relationship to previous Message Signature Technologies . . . 23
2.4. { Misc Text -- Should go elsewhere, if used at all } . . . 10 5.1. Transparent Signature . . . . . . . . . . . . . . . . . . 23
3. Relationship to previous Message Signature Technologies . . . 11 5.2. Treat verification failure as if unsigned. . . . . . . . . 24
3.1. Transparent Signature . . . . . . . . . . . . . . . . . . 11 5.3. Legacy Client Semantics . . . . . . . . . . . . . . . . . 25
3.2. Treat verification failure as if unsigned. . . . . . . . . 12 5.4. Key Centric PKI . . . . . . . . . . . . . . . . . . . . . 25
3.3. Legacy Client Semantics . . . . . . . . . . . . . . . . . 13 5.5. Domain Level Assurance . . . . . . . . . . . . . . . . . . 27
3.4. Key Centric PKI . . . . . . . . . . . . . . . . . . . . . 13 5.6. Security Policy . . . . . . . . . . . . . . . . . . . . . 27
3.5. Domain Level Assurance . . . . . . . . . . . . . . . . . . 15 6. Implementation Considerations . . . . . . . . . . . . . . . . 28
3.6. Security Policy . . . . . . . . . . . . . . . . . . . . . 15 6.1. Development . . . . . . . . . . . . . . . . . . . . . . . 28
4. Implementation Considerations . . . . . . . . . . . . . . . . 16 6.2. Deployment . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1. Development . . . . . . . . . . . . . . . . . . . . . . . 16 6.3. Operations . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.1. Signer . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Outline Future Extensions . . . . . . . . . . . . . . . . . . 30
4.1.2. Validator . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Introducing a new signing algorithm . . . . . . . . . . . 31
4.1.3. Outbound mail user agent . . . . . . . . . . . . . . . 16 7.2. Possible future signature algorithm choices . . . . . . . 31
4.1.4. Outbound mail transport agent . . . . . . . . . . . . 16 7.3. Transition strategy . . . . . . . . . . . . . . . . . . . 32
4.1.5. DNS Server . . . . . . . . . . . . . . . . . . . . . . 16 7.4. Linkage to Other PKIs . . . . . . . . . . . . . . . . . . 33
4.1.6. Mailing list manager . . . . . . . . . . . . . . . . . 16 7.5. Trusted Third Party Assertions . . . . . . . . . . . . . . 34
4.1.7. Inbound mail transport agent . . . . . . . . . . . . . 16 7.6. Linkage to X.509 Certificates . . . . . . . . . . . . . . 35
4.1.8. Inbound mail user agent . . . . . . . . . . . . . . . 17 7.7. XKMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.9. Accreditation service . . . . . . . . . . . . . . . . 17 7.8. Verification in the Client . . . . . . . . . . . . . . . . 36
4.2. Deployment . . . . . . . . . . . . . . . . . . . . . . . . 17 7.9. Per user signature . . . . . . . . . . . . . . . . . . . . 37
4.2.1. Signing . . . . . . . . . . . . . . . . . . . . . . . 17 7.10. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.2. Verifying . . . . . . . . . . . . . . . . . . . . . . 17 7.11. Reuse of Key Record . . . . . . . . . . . . . . . . . . . 38
4.3. Operations . . . . . . . . . . . . . . . . . . . . . . . . 17 7.12. Use of Policy Record . . . . . . . . . . . . . . . . . . . 38
4.3.1. DNS Signature Record Deployment Considerations . . . . 17 8. What Needs To Be Moved Here From the Base Doc? . . . . . . . . 39
4.3.2. Thoughts on Expiring Signatures . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.3. DNS Policy Record Deployment Considerations . . . . . 18 10. Informative References . . . . . . . . . . . . . . . . . . . . 39
4.3.4. Subdomain Considerations . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.5. Third party Signature Delegations . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 42
5. Outline Future Extensions . . . . . . . . . . . . . . . . . . 18
5.1. Introducing a new signing algorithm . . . . . . . . . . . 19
5.2. Possible future signature algorithm choices . . . . . . . 19
5.3. Transition strategy . . . . . . . . . . . . . . . . . . . 20
5.3.1. Signer transition strategy . . . . . . . . . . . . . . 20
5.3.2. Verifier transition strategy . . . . . . . . . . . . . 21
5.4. Linkage to Other PKIs . . . . . . . . . . . . . . . . . . 21
5.5. Trusted Third Party Assertions . . . . . . . . . . . . . . 22
5.6. Linkage to X.509 Certificates . . . . . . . . . . . . . . 23
5.7. XKMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.8. Verification in the Client . . . . . . . . . . . . . . . . 24
5.9. Per user signature . . . . . . . . . . . . . . . . . . . . 25
5.10. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 25
5.11. Reuse of Key Record . . . . . . . . . . . . . . . . . . . 26
5.12. Use of Policy Record . . . . . . . . . . . . . . . . . . . 26
6. What Needs To Be Moved Here From the Base Doc? . . . . . . . . 27
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
8. Informative References . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 30
1. Introduction 1. Introduction
1.1. About This Document 1.1. About This Document
This document provides an overview of DomainKeys Identified Mail This document provides an overview of DomainKeys Identified Mail
(DKIM). It provides information for: those who are adopting DKIM; (DKIM). It provides information for: those who are adopting DKIM;
those who are developing DKIMd;, those who are deploying DKIM; and those who are developing DKIM; those who are deploying DKIM; and
those who are considering extending DKIM, either into other areas or those who are considering extending DKIM, either into other areas or
to provide additional features. to provide additional features.
This document does not provide information on threats to DKIM or This document does not provide information on threats to DKIM or
email, or details on the implementation. Such information can be email, or details on the implementation. Such information can be
found in other RFC documents.[I-D.ietf-dkim-base] [I-D.ietf-dkim- found in other RFC documents.[I-D.ietf-dkim-base] [I-D.ietf-dkim-
threats] Nor does this document describe how to solve the world's threats] Nor does this document describe how to solve the world's
problems with spam, phish, virii, worms, joe jobs, etc. problems with spam, phish, virii, worms, joe jobs, etc.
[ NOTE: a number of sections in this document are just placeholders [ NOTE: a number of sections in this document are just placeholders
skipping to change at page 5, line 46 skipping to change at page 4, line 46
The ultimate goal of DKIM is to achieve a situation where email The ultimate goal of DKIM is to achieve a situation where email
authentication is ubiquitous and the unsigned email becomes the authentication is ubiquitous and the unsigned email becomes the
exception the rule, as is the case today. Only when the majority of exception the rule, as is the case today. Only when the majority of
Internet email is authenticated is it possible to make interesting Internet email is authenticated is it possible to make interesting
conclusions about the lack of authentication. conclusions about the lack of authentication.
It follows then that a new message signature scheme is required to It follows then that a new message signature scheme is required to
meet the goal of ubiquitous authentication. In each of the above- meet the goal of ubiquitous authentication. In each of the above-
mentioned proposals, several design elements are shared: mentioned proposals, several design elements are shared:
The signature is carried in the message header and does not affect o The signature is carried in the message header and does not affect
the message body. the message body.
The signature may include certain headers. o The signature may include certain headers.
There is a policy mechanism, either explicit or implicit, that o There is a policy mechanism, either explicit or implicit, that
tells receivers when to expect a signature. tells receivers when to expect a signature.
Keys are self-created (it is not necessary to buy a certificate). o Keys are self-created (it is not necessary to buy a certificate).
Keys are stored in the DNS (it is not necessary to deploy a o Keys are stored in the DNS (it is not necessary to deploy a
separate key server). separate key server).
The remarkable similarity of these architectural proposals strongly The remarkable similarity of these architectural proposals strongly
suggests that this architecture should be the basis for unbiquitous suggests that this architecture should be the basis for ubiquitous
authentication. DKIM was produced by merging the two previous authentication. DKIM was produced by merging the two previous
proposals of DomainKeys and Identified Internet Mail. Significant proposals of DomainKeys and Identified Internet Mail. Significant
enhancements were then made from that base. enhancements were then made from that base.
The approach taken by DKIM differs from previous approaches to The approach taken by DKIM differs from previous approaches to
message signing in that: message signing in that:
the message signature is written as a message header field so that o the message signature is written as a message header field so that
neither human recipients nor existing MUA (Mail User Agent) neither human recipients nor existing MUA (Mail User Agent)
software are confused by signature-related content appearing in software are confused by signature-related content appearing in
the message body, the message body,
there is no dependency on public and private key pairs being o there is no dependency on public and private key pairs being
issued by well-known, trusted certificate authorities, issued by well-known, trusted certificate authorities,
there is no dependency on the deployment of any new Internet o there is no dependency on the deployment of any new Internet
protocols or services for public key distribution or revocation, protocols or services for public key distribution or revocation,
it makes no attempt to include encryption as part of the o it makes no attempt to include encryption as part of the
mechanism. mechanism.
1.2.2. What is the purpose of DKIM? 1.2.2. What is the purpose of DKIM?
DKIM lets an organization take responsibility for a message. The DKIM lets an organization take responsibility for a message. The
organization taking responsibility is a handler of the message, organization taking responsibility is a handler of the message,
either as its originator or as an intermediary. Their reputation is either as its originator or as an intermediary. Their reputation is
the basis for evaluating whether to trust the message for delivery. the basis for evaluating whether to trust the message for delivery.
The owner of the domain name being used for a DKIM signature is The owner of the domain name being used for a DKIM signature is
declaring that they are accountable for the message. This means that declaring that they are accountable for the message. This means that
their reputation is at stake. their reputation is at stake.
By design, DKIM purposely: By design, DKIM purposely:
is compatible with the existing email infrastructure and o is compatible with the existing email infrastructure and
transparent to the fullest extent possible transparent to the fullest extent possible
requires minimal new infrastructure o requires minimal new infrastructure
can be implemented independently of clients in order to reduce o can be implemented independently of clients in order to reduce
deployment time deployment time
does not require the use of trusted third parties (e.g., o does not require the use of trusted third parties (e.g.,
certificate authoritys) which might impose significant costs or certificate authorities) which might impose significant costs or
introduce delays to deployment introduce delays to deployment
can be deployed incrementally o can be deployed incrementally
allows delegation of signing to third parties o allows delegation of signing to third parties
is not intended be used for archival purposes o is not intended be used for archival purposes
DKIM authentication provides one link in a chain of responsibility, DKIM authentication provides one link in a chain of responsibility,
hopefully leading to better accountability by the senders. hopefully leading to better accountability by the senders.
1.2.3. What does DKIM do? 1.2.3. What does DKIM do?
DKIM defines a mechanism by which email messages can be DKIM defines a mechanism by which email messages can be
cryptographically signed, permitting a signing domain to claim cryptographically signed, permitting a signing domain to claim
responsibility for the introduction of a message into the mail responsibility for the introduction of a message into the mail
stream. The responsible organization adds a digital signature to the stream. The responsible organization adds a digital signature to the
skipping to change at page 8, line 22 skipping to change at page 7, line 22
can re-post the message in such a way that the signature would can re-post the message in such a way that the signature would
remain valid, although the new recipient(s) would not have been remain valid, although the new recipient(s) would not have been
specified by the originator. specified by the originator.
1.3. Outline Potential DKIM Applications 1.3. Outline Potential DKIM Applications
TBD TBD
2. DKIM Within Existing Internet Email 2. DKIM Within Existing Internet Email
Email service architecture review. 2.1. Review of Internet Mail Service Architecture
AdMD to AdMD, not MTA to MTA. (AdMD not equal Domain Name.) Internet Mail has a simple split between the user world, in the form
of Mail User Agents (MUA), and the transmission world, in the form of
the Mail Handling Service (MHS) composed of Mail Transfer Agents
(MTA). The MHS is responsible for accepting a message from one User
and delivering it to one or more others, creating a virtual MUA-to-
MUA exchange environment. The first MTA is called the Mail
Submission Agent (MSA) and the final MTA is called the Mail Delivery
Agent (MDA)
+--------+
+---------------->| User |
| +--------+
| ^
+--------+ | +--------+ .
| User +--+--------->| User | .
+--------+ | +--------+ .
. | ^ .
. | +--------+ . .
. +-->| User | . .
. +--------+ . .
. ^ . .
. . . .
V . . .
+---+----------------+------+------+---+
| | | | | |
| +--------------->+ | | |
| | | | |
| +---------------------->+ | |
| | | |
| +----------------------------->+ |
| |
| Mail Handling Service (MHS) |
+--------------------------------------+
2.1. Where to Place DKIM Functions Figure 1: Basic Internet Mail Service Model
DKIM may be run within any component of an AdMD, such as: Modern Internet Mail service is marked by many independent operators,
many different components for providing users with service and many
other components for performing message transfer. Consequently, it
is necessary to distinguish administrative boundaries that surround
sets of functional components.
Outbound: MSA or boundary MTA. 2.1.1. Administrative Actors
Inbound: Boundary MTA or MDA. Operation of Internet Mail services is apportioned to different
providers (or operators). Each can be composed of an independent
ADministrative Management Domain (ADMD). Examples include an end-
user operating their desktop client, a department operating a local
Relay, an IT department operating an enterprise Relay and an ISP
operating a public shared email service. These can be configured
into many combinations of administrative and operational
relationships, with each ADMD potentially having a complex
arrangement of functional components. Figure 2 depicts the
relationships among ADMDs. Perhaps the most salient aspect of an
ADMD is the differential trust that determines its policies for
activities within the ADMD, versus those involving interactions with
other ADMDs.
{explain basis tradeoffs/reasons for choices: s/w availability, user- Basic components of ADMD distinction include:
vs-ops, admin control/ease...}
2.2. Impact on Email Activities Edge: Independent transfer services, in networks at the edge of the
Internet Mail service.
2.2.1. Resources User: End-user services. This might be subsumed under the Edge
service, such as is common for web-based email access.
Transit: These are Mail Service Providers (MSP) offering value-added
capabilities for Edge ADMDs, such as aggregation and filtering.
Note that Transit services are quite different from packet-level
transit operation. Whereas end-to-end packet transfers usually go
through intermediate routers, email exchange across the open Internet
is often directly between the Edge ADMDs, at the email level.
+-------+ +-------+ +-------+
| ADMD1 | | ADMD3 | | ADMD4 |
| ----- | | ----- | | ----- |
| | +---------------------->| | | |
| User | | |-Edge--+--->|-User |
| | | | +--->| | | |
| V | | | +-------+ +-------+
| Edge--+---+ |
| | | +---------+ |
+-------+ | | ADMD2 | |
| | ----- | |
| | | |
+--->|-Transit-+---+
| |
+---------+
Figure 2: ADministrative Management Domains (ADMD) Example
The distinction between Transit network and Edge network transfer
services is primarily significant because it highlights the need for
concern over interaction and protection between independent
administrations. The interactions between functional components
within an ADMD are subject to the policies of that domain.
Common ADMD examples are:
Enterprise Service Providers:
Operating an organization's internal data and/or mail services.
Internet Service Providers:
Operating underlying data communication services that, in turn,
are used by one or more Relays and Users. It is not necessarily
their job to perform email functions, but they can, instead,
provide an environment in which those functions can be performed.
Mail Service Providers:
Operating email services, such as for end-users, or mailing lists.
2.1.2. Field Referencing Convention
In this document, references to structured fields of a message use a
two-part dotted notation. The first part cites the document that
contains the specification for the field and the second is the name
of the field. Hence <RFC2822.From> is the From field in an email
content header and <RFC2821.MailFrom> is the address in the SMTP
"Mail From" command.
DKIM associates a "responsible" identity with a message and provides
a means of verifying that the association is legitimate. Deciding
which ADMD shall perform signing or verifying, which identity to
assign and which functional components to use for DKIM processing
depend upon the nature of the trust/reputation that is of interest
and the most convenient or efficient way to use it.
2.2. Where to Place DKIM Functions
Messages may be signed or verified by any functional component within
an ADMD, as that domain wishes to arrange, such as:
Outbound: MUA, MSA or boundary MTA.
Inbound: Boundary MTA, MDA or MUA.
By having an MUA do the signing or verifying, there is no dependence
upon implementation by an email service infrastructure. By having an
MHS component do signing or verifying, there is no dependence upon
user training or the upgrade of potentially large numbers of user
applications.
Perhaps the most obvious choices within the MHS are the MSA or MDA,
and the outbound or inbound (boundary) MTA. By signing or verifying
at the outermost portion of the MHS, true end-to-end service is
provided, requiring the smallest amount of trust on the rest of the
infrastructure. By signing or verifying at a boundary, the smallest
number of systems need modifying and the signature is subject to the
smallest amount of handling that can break the signature.
The choice of identity to use might not be obvious. Examples
include:
Author The domain associated with the RFC2822.From field provides
basic authorization for the author to generate mail. Because the
organization controlling that domain is closest to the author,
they well might be in the best position to offer their reputation
as a basis for asserting that the content is "safe".
Operator Email reputation services have long-used the IP Address of a
client SMTP server as the basis for assessing whether to permit
relay or delivery of a message. These Addresses identify the
operator of an email service, rather than necessarily indicating
the author of messages being sent by that service. Use of an
operator's domain name is a natural extension of this model.
Third-party An independent service might wish to certify an author, a
message or an operator, by providing its own signature to a
message. Hence, evaluation of the message will be based upon the
identity of that third-party, rather than any of the identities
involved in creation or transfer of the message. Indeed, this
model is already emerging among a number of reputation-vetting
services and is similar to the way a credit card permits a
customer to make purchases, based upon the reputation of the
credit card company -- and its willingness to issue the card.
Ultimately, the choice of component for signing will depend upon both
the identity being used and the tradeoff between flexibility of uses,
versus administrative and operational control. The choice of
component for verification will depend upon the intended use and
similar concerns about flexibility and control. A typical choice for
reputation-related verification will be to place the signature
verification function "close" to the message-filtering engine.
2.3. Impact on Email Activities
2.3.1. Resources
Although the cryptographic authentication are considered to be Although the cryptographic authentication are considered to be
computationally expensive, the real impact of a mechanism, like DKIM, computationally expensive, the real impact of a mechanism, like DKIM,
is remarkably small. Direct impact on CPU-load has been measured to is remarkably small. Direct impact on CPU-load has been measured to
be 10-15%. Usually, email is i/o-intensive, with unused be 10-15%. Usually, email is i/o-intensive, with unused
computational capacity. So, it is likely that no new hardware will computational capacity. So, it is likely that no new hardware will
be required. be required.
2.2.2. Operations 2.3.2. Operations
Administrative cost to deploy, versus expected reduction in the cost Administrative cost to deploy, versus expected reduction in the cost
of administration for problem email. of administration for problem email.
Challenge of mobile users. Server-resident folders -- web or imap -- Challenge of mobile users. Server-resident folders -- web or imap --
no problem. Laptop-resident folders, requires remote MSA access or no problem. Laptop-resident folders, requires remote MSA access or
per-user keying and mobile-author awareness. per-user keying and mobile-author awareness.
Key creation and replacement. Update DNS and signing component Key creation and replacement. Update DNS and signing component
2.2.3. Users 2.3.3. Users
Challenge of mobile users. Server-resident folders -- web or imap -- Challenge of mobile users. Server-resident folders -- web or imap --
no problem. Laptop-resident folders, requires remote MSA access or no problem. Laptop-resident folders, requires remote MSA access or
per-user keying and mobile-author awareness. per-user keying and mobile-author awareness.
Challenge of mailing lists. Different list styles warrant different Challenge of mailing lists. Different list styles warrant different
signature policies. signature policies.
Can be hidden from end-user; used by filter engine. Method and Can be hidden from end-user; used by filter engine. Method and
benefits for displaying to users unknown. benefits for displaying to users unknown.
2.3. Migrating from DomainKeys 2.4. Migrating from DomainKeys
2.3.1. Signing 2.4.1. Signing
2.3.1.1. DNS Records 2.4.1.1. DNS Records
DKIM is upward compatible with existing DomainKeys (DK) DNS records, DKIM is upward compatible with existing DomainKeys (DK) DNS records,
so that a DKIM module does not automatically require additional DNS so that a DKIM module does not automatically require additional DNS
administration! DKIM has enhanced the DK DNS key record, to permit administration! DKIM has enhanced the DK DNS key record, to permit
the addition of several parameters. the addition of several parameters.
2.3.1.2. Signing Module 2.4.1.2. Signing Module
DKIM uses a different RFC2822 [RFC2822] header field for storing the DKIM uses a different RFC2822 [RFC2822] header field for storing the
signature, in order to distinguish it from DK. signature, in order to distinguish it from DK.
DKIM includes language to make it clear which particular header field DKIM includes language to make it clear which particular header field
is signed, if there is more than one header field of a given name in is signed, if there is more than one header field of a given name in
the message. the message.
DKIM allows some values that were scalars in DomainKeys to be colon- DKIM allows some values that were scalars in DomainKeys to be colon-
separated arrays. For example, the list of query methods used to separated arrays. For example, the list of query methods used to
skipping to change at page 10, line 13 skipping to change at page 13, line 13
DKIM permits copying the original version of headers fields and their DKIM permits copying the original version of headers fields and their
values, to aid in diagnosing signatures that do not survive transit. values, to aid in diagnosing signatures that do not survive transit.
DKIM has the ability to limit keys to hash algorithms specified in a DKIM has the ability to limit keys to hash algorithms specified in a
list, in the DNS record. list, in the DNS record.
DKIM allows body length limits, to permit signatures, to survive DKIM allows body length limits, to permit signatures, to survive
transit through some intermediaries, such as some mailing list agents transit through some intermediaries, such as some mailing list agents
that add text to the end of the message. that add text to the end of the message.
2.3.1.3. Boundary MTA 2.4.1.3. Boundary MTA
Enforce signature policies and practises Enforce signature policies and practises
2.3.2. Verifying 2.4.2. Verifying
2.3.2.1. DNS Client 2.4.2.1. DNS Client
2.3.2.2. Verifying module 2.4.2.2. Verifying module
See "Signing Module". See "Signing Module".
2.3.2.3. Boundary MTA 2.4.2.3. Boundary MTA
Strip "local" signatures that are not local? Strip "local" signatures that are not local?
2.4. { Misc Text -- Should go elsewhere, if used at all } 2.5. { Misc Text -- Should go elsewhere, if used at all }
DKIM permits the signing identity to be different from the identities DKIM permits the signing identity to be different from the identities
used for the author or the initial posting agent. This is essential, used for the author or the initial posting agent. This is essential,
for example, to enable support of signing by authorized third- for example, to enable support of signing by authorized third-
parties, and to permit signatures by email providers who are parties, and to permit signatures by email providers who are
otherwise independent of the domain name of the message author. otherwise independent of the domain name of the message author.
DKIM permits restricting the use of a signature key to particular DKIM permits restricting the use of a signature key to particular
types of services, such as only for email. This is helpful when types of services, such as only for email. This is helpful when
delegating signing authority, such as to a particular department or delegating signing authority, such as to a particular department or
skipping to change at page 11, line 9 skipping to change at page 14, line 9
DKIM self-signs the DKIM-Signature header field, to protect against DKIM self-signs the DKIM-Signature header field, to protect against
its being modified. its being modified.
In order to survive the vagaries of different email transfer systems, In order to survive the vagaries of different email transfer systems,
mechanisms like DKIM must evaluate the message data in some canonical mechanisms like DKIM must evaluate the message data in some canonical
form, such as treating a string of spaces as tabs as if they were a form, such as treating a string of spaces as tabs as if they were a
single space. DKIM has added the "relaxed" canonicalization in place single space. DKIM has added the "relaxed" canonicalization in place
of "nofws". of "nofws".
3. Relationship to previous Message Signature Technologies 3. DKIM Within Existing Internet Email
3.1. Review of Internet Mail Service Architecture
Internet Mail has a simple split between the user world, in the form
of Mail User Agents (MUA), and the transmission world, in the form of
the Mail Handling Service (MHS) composed of Mail Transfer Agents
(MTA). The MHS is responsible for accepting a message from one User
and delivering it to one or more others, creating a virtual MUA-to-
MUA exchange environment. The first MTA is called the Mail
Submission Agent (MSA) and the final MTA is called the Mail Delivery
Agent (MDA)
+--------+
+---------------->| User |
| +--------+
| ^
+--------+ | +--------+ .
| User +--+--------->| User | .
+--------+ | +--------+ .
. | ^ .
. | +--------+ . .
. +-->| User | . .
. +--------+ . .
. ^ . .
. . . .
V . . .
+---+----------------+------+------+---+
| | | | | |
| +--------------->+ | | |
| | | | |
| +---------------------->+ | |
| | | |
| +----------------------------->+ |
| |
| Mail Handling Service (MHS) |
+--------------------------------------+
Figure 3: Basic Internet Mail Service Model
Modern Internet Mail service is marked by many independent operators,
many different components for providing users with service and many
other components for performing message transfer. Consequently, it
is necessary to distinguish administrative boundaries that surround
sets of functional components.
3.1.1. Administrative Actors
Operation of Internet Mail services is apportioned to different
providers (or operators). Each can be composed of an independent
ADministrative Management Domain (ADMD). Examples include an end-
user operating their desktop client, a department operating a local
Relay, an IT department operating an enterprise Relay and an ISP
operating a public shared email service. These can be configured
into many combinations of administrative and operational
relationships, with each ADMD potentially having a complex
arrangement of functional components. Figure 2 depicts the
relationships among ADMDs. Perhaps the most salient aspect of an
ADMD is the differential trust that determines its policies for
activities within the ADMD, versus those involving interactions with
other ADMDs.
Basic components of ADMD distinction include:
Edge: Independent transfer services, in networks at the edge of the
Internet Mail service.
User: End-user services. These might be subsumed under an Edge
service, such as is common for web-based email access.
Transit: These are Mail Service Providers (MSP) offering value-added
capabilities for Edge ADMDs, such as aggregation and filtering.
Note that Transit services are quite different from packet-level
transit operation. Whereas end-to-end packet transfers usually go
through intermediate routers, email exchange across the open Internet
is often directly between the Edge ADMDs, at the email level.
+-------+ +-------+ +-------+
| ADMD1 | | ADMD3 | | ADMD4 |
| ----- | | ----- | | ----- |
| | +---------------------->| | | |
| User | | |-Edge--+--->|-User |
| | | | +--->| | | |
| V | | | +-------+ +-------+
| Edge--+---+ |
| | | +---------+ |
+-------+ | | ADMD2 | |
| | ----- | |
| | | |
+--->|-Transit-+---+
| |
+---------+
Figure 4: ADministrative Management Domains (ADMD) Example
The distinction between Transit network and Edge network transfer
services is primarily significant because it highlights the need for
concern over interaction and protection between independent
administrations. The interactions between functional components
within an ADMD are subject to the policies of that domain.
Common ADMD examples are:
Enterprise Service Providers:
Operating an organization's internal data and/or mail services.
Internet Service Providers:
Operating underlying data communication services that, in turn,
are used by one or more Relays and Users. It is not necessarily
their job to perform email functions, but they can, instead,
provide an environment in which those functions can be performed.
Mail Service Providers:
Operating email services, such as for end-users, or mailing lists.
3.1.2. Field Referencing Convention
In this document, references to structured fields of a message use a
two-part dotted notation. The first part cites the document that
contains the specification for the field and the second is the name
of the field. Hence <RFC2822.From> is the From field in an email
content header and <RFC2821.MailFrom> is the address in the SMTP
"Mail From" command.
DKIM associates a "responsible" identity with a message and provides
a means of verifying that the association is legitimate. The choices
of what ADMD to have perform signing or verifying, which identity to
assign and which functional components to use for DKIM processing
depend upon the nature of the trust/reputation that is of interest
and the most convenient or efficient way to use it.
3.2. Where to Place DKIM Functions
Messages may be signed or verified by any functional component within
an ADMD, as that domain wishes to arrange, such as:
Outbound: MUA, MSA or boundary MTA.
Inbound: Boundary MTA, MDA or MUA.
By having an MUA do the signing or verifying, there is no dependence
upon implementation by an email service infrastructure. By having
and MHS component do signing or verifying, there is no dependence
upon user training or the upgrade of potentially large numbers of
user applications.
Perhaps the most obvious choices within the MHS are the MSA or MDA,
and the outbound or inbound (boundary) MTA. By signing or verifying
at the outermost portion of the MHS, true end-to-end service is
provided, requiring the smallest amount of trust on the rest of the
infrastructure. By signing or verifying at a boundary, the smallest
number of systems need modifying and the signature is subject to the
smallest amount of handling that can break the signature.
Ultimately, deciding where to sign a message is likely to depend upon
a combination of the identity being used, and tradeoffs between
flexibility, control, and administrative ease.
3.3. Impact on Email Activities
3.3.1. Resources
Although the cryptographic authentication are considered to be
computationally expensive, the real impact of a mechanism, like DKIM,
is remarkably small. Direct impact on CPU-load has been measured to
be 10-15%. Usually, email is i/o-intensive, with unused
computational capacity. So, it is likely that no new hardware will
be required.
3.3.2. Operations
Administrative cost to deploy, versus expected reduction in the cost
of administration for problem email.
Challenge of mobile users. Server-resident folders -- web or imap --
no problem. Laptop-resident folders, requires remote MSA access or
per-user keying and mobile-author awareness.
Key creation and replacement. Update DNS and signing component
3.3.3. Users
Challenge of mobile users. Server-resident folders -- web or imap --
no problem. Laptop-resident folders, requires remote MSA access or
per-user keying and mobile-author awareness.
Challenge of mailing lists. Different list styles warrant different
signature policies.
Can be hidden from end-user; used by filter engine. Method and
benefits for displaying to users unknown.
3.4. Migrating from DomainKeys
3.4.1. Signing
3.4.1.1. DNS Records
DKIM is upward compatible with existing DomainKeys (DK) DNS records,
so that a DKIM module does not automatically require additional DNS
administration! DKIM has enhanced the DK DNS key record, to permit
the addition of several parameters.
3.4.1.2. Signing Module
DKIM uses a different RFC2822 [RFC2822] header field for storing the
signature, in order to distinguish it from DK.
DKIM includes language to make it clear which particular header field
is signed, if there is more than one header field of a given name in
the message.
DKIM allows some values that were scalars in DomainKeys to be colon-
separated arrays. For example, the list of query methods used to
find a key and the "t=" tags (originally testing, now flags).
DKIM permits copying the original version of headers fields and their
values, to aid in diagnosing signatures that do not survive transit.
DKIM has the ability to limit keys to hash algorithms specified in a
list, in the DNS record.
DKIM allows body length limits, to permit signatures, to survive
transit through some intermediaries, such as some mailing list agents
that add text to the end of the message.
3.4.1.3. Boundary MTA
Enforce signature policies and practises
3.4.2. Verifying
3.4.2.1. DNS Client
3.4.2.2. Verifying module
See "Signing Module".
3.4.2.3. Boundary MTA
Strip "local" signatures that are not local?
3.5. { Misc Text -- Should go elsewhere, if used at all }
DKIM permits the signing identity to be different from the identities
used for the author or the initial posting agent. This is essential,
for example, to enable support of signing by authorized third-
parties, and to permit signatures by email providers who are
otherwise independent of the domain name of the message author.
DKIM permits restricting the use of a signature key to particular
types of services, such as only for email. This is helpful when
delegating signing authority, such as to a particular department or
to a third-party outsourcing service.
With DKIM the signer MUST explicitly list the headers that are
signed. This is an improvement because it requires the signer to use
the more conservative (likely to verify correctly) mechanism and
makes it considerably more robust against the handling of
intermediary MTAs.
DKIM self-signs the DKIM-Signature header field, to protect against
its being modified.
In order to survive the vagaries of different email transfer systems,
mechanisms like DKIM must evaluate the message data in some canonical
form, such as treating a string of spaces as tabs as if they were a
single space. DKIM has added the "relaxed" canonicalization in place
of "nofws".
4. DKIM Service Architecture
DKIM provides an end-to-end service for signing and verifying
messages that are in transit. It is divided into components that can
be performed using different, external services, such as for key
retrieval, although the basic DKIM operation provides an initial set.
|
| - RFC2822 Message
V
+---------------------------------------------+
+-----------+ | ORIGINATING OR RELAYING ADMD |
| | | ============================ |
| Signer | | |
| Practises +......>| SIGN MESSAGE |
| | | ...> ADD A SIGNATURE HEADER FIELD |
+-----+-----+ .....>| . GET (Domain, Selector, Priv-Key) |
. . | ... COMPUTE SIGNATURE |
. V +----------------+----------------------------+
. +-------+ | - Message
. | | | 1*(Domain, Selector,
. | Key | | Sig)
. | Store | [Internet]
. | | |
. +---+---+ V
. . +---------------------------------------------+
. . | RELAYING OR DELIVERING ADMD |
. . | =========================== |
. . | |
. . | VERIFY MESSAGE (Verifier Practises) |
. . | ...> VERIFY A SIGNATURE HEADER FIELD |
. . | . GET A SIGNATURE |
. .....>| . LOOKUP PUB-KEY (Domain, Selector) |
. | . VERIFY SIGNATURE VALUE |
. | ... EVALUATE SIGNATURE CONSTRAINTS |
. +-------------------+-------------------------+
. | - Verified Domain(s)
. V - [Report]
. +---------------------------------------------+
. | |
. | MESSAGE DISPOSITION |
.............>| SIGNER PRACTICES |
.............>| REPUTATION |
. | |
+-----+------+ +---------------------------------------------+
| |
| Reputation |
| |
+------------+>
Figure 5: DKIM Service Architecture
Basic message process divides between signing the message, validating
the signature, and the performing further decision-making based upon
the validated signature. The component doing the signing applies
whatever signing policies are in force, including ones that determine
what private key to use. Validation may be performed by any
functional component along the relay and delivery path. The public
key is retrieved, based upon the parameters strored in the message.
The example shows use of the validated identity for assessing an
associated reputation. However it could be applied for other tasks,
such as management tracking of mail.
5. Relationship to previous Message Signature Technologies
DKIM is the fifth IETF proposal for an email signature scheme. The DKIM is the fifth IETF proposal for an email signature scheme. The
first RFC describing Privacy Enhanced Mail (PEM) was published in first RFC describing Privacy Enhanced Mail (PEM) was published in
1987 [RFC0989]. The PEM scheme went through a number of revisions 1987 [RFC0989]. The PEM scheme went through a number of revisions
and eventually transformed into MIME Object Security Services in 1995 and eventually transformed into MIME Object Security Services in 1995
[RFC1848]. [RFC1848].
Neither PEM nor MOSS ever achieved significant deployment. PEM Neither PEM nor MOSS ever achieved significant deployment. PEM
relied on the prior deployment of an extensive PKI predicated on a relied on the prior deployment of an extensive PKI predicated on a
rigid hierarchy of Certificate Authorities. By the time it was rigid hierarchy of Certificate Authorities. By the time it was
skipping to change at page 11, line 45 skipping to change at page 23, line 48
format to transport a PKCS #7 data object. S/MIME was particularly format to transport a PKCS #7 data object. S/MIME was particularly
attractive for software developers who had already implemented SSL as attractive for software developers who had already implemented SSL as
much of the code required to support could be reused. much of the code required to support could be reused.
Development of S/MIME and OpenPGP has continued in the IETF since. Development of S/MIME and OpenPGP has continued in the IETF since.
While both have achieved a significant user base neither has achieved While both have achieved a significant user base neither has achieved
ubiquity. In particular it is notable that only a small percentage ubiquity. In particular it is notable that only a small percentage
of messages on the IETF mailing lists concerned with security are of messages on the IETF mailing lists concerned with security are
signed. signed.
3.1. Transparent Signature 5.1. Transparent Signature
The core goals of DKIM require that use of message signatures becomes The core goals of DKIM require that use of message signatures becomes
ubiquitous. For this to be possible it must be possible to apply a ubiquitous. For this to be possible it must be possible to apply a
signature to any message in any circumstance with a negligible chance signature to any message in any circumstance with a negligible chance
of causing a negative user experience for any recipient regardless of of causing a negative user experience for any recipient regardless of
the legacy email client used. the legacy email client used.
Experiences from S/MIME and PGP deployment strongly indicate that Experiences from S/MIME and PGP deployment strongly indicate that
this usability goal can only be met if the addition of the signature this usability goal can only be met if the addition of the signature
leaves the message body unchanged. leaves the message body unchanged.
skipping to change at page 12, line 41 skipping to change at page 24, line 44
In the case of an S/MIME signature the recipient is at a minimum In the case of an S/MIME signature the recipient is at a minimum
expected to have a client capable of decoding the MIME multipart/ expected to have a client capable of decoding the MIME multipart/
security format. In practice this means that the recipient must security format. In practice this means that the recipient must
support S/MIME. OpenPGP allows the use of a signature encapsulation support S/MIME. OpenPGP allows the use of a signature encapsulation
that is not MIME based. This has the advantage that the message can that is not MIME based. This has the advantage that the message can
be read using a standard email client. The disadvantage with this be read using a standard email client. The disadvantage with this
approach is that the application of the signature is visible to the approach is that the application of the signature is visible to the
user and thus intrusive. user and thus intrusive.
3.2. Treat verification failure as if unsigned. 5.2. Treat verification failure as if unsigned.
PGP and S/MIME were both designed to meet a high standard of PGP and S/MIME were both designed to meet a high standard of
cryptographic excellence. At the time the protocols were designed it cryptographic excellence. At the time the protocols were designed it
was generally considered that the correct thing for an application to was generally considered that the correct thing for an application to
do in the case of a signature verification failure was to warn the do in the case of a signature verification failure was to warn the
user that the message was unsigned. In a small number of cases the user that the message was unsigned. In a small number of cases the
application went even further 'warning' the user whenever a signed application went even further 'warning' the user whenever a signed
message was received. message was received.
This type of user experience has since been severely deprecated. A This type of user experience has since been severely deprecated. A
skipping to change at page 13, line 26 skipping to change at page 25, line 29
It is highly unlikely that an attacker is going to add a digital It is highly unlikely that an attacker is going to add a digital
signature to a message unless doing so causes the message to be signature to a message unless doing so causes the message to be
treated more favorably than an unsigned one. Any messages that carry treated more favorably than an unsigned one. Any messages that carry
signatures that fail verification are thus much more likely to be a signatures that fail verification are thus much more likely to be a
genuine message that has been damaged in transit than an attempted genuine message that has been damaged in transit than an attempted
forgery. It makes no sense to warn the recipient unless it is known forgery. It makes no sense to warn the recipient unless it is known
that the sender always signs email messages and that there is a high that the sender always signs email messages and that there is a high
probability that a forgery would be attempted. probability that a forgery would be attempted.
3.3. Legacy Client Semantics 5.3. Legacy Client Semantics
The deployed base of S/MIME is both a benefit and a burden. While The deployed base of S/MIME is both a benefit and a burden. While
the S/MIME protocol is in principle capable of extension to support the S/MIME protocol is in principle capable of extension to support
many of the features of DKIM, the same is not true of the deployed many of the features of DKIM, the same is not true of the deployed
S/MIME base. S/MIME base.
While the S/MIME protocol can in principle support semantics such as While the S/MIME protocol can in principle support semantics such as
domain level signatures or make use of keys stored in the DNS the domain level signatures or make use of keys stored in the DNS the
legacy deployed base does not. The behavior of legacy clients legacy deployed base does not. The behavior of legacy clients
receiving an S/MIME message dependent on the novel semantics is receiving an S/MIME message dependent on the novel semantics is
likely to result in a negative user experience in a significant likely to result in a negative user experience in a significant
number of cases. number of cases.
3.4. Key Centric PKI 5.4. Key Centric PKI
Unlike all four previous IETF email security initiatives, DKIM Unlike all four previous IETF email security initiatives, DKIM
employs a key centric, directory based PKI as opposed to a employs a key centric, directory based PKI as opposed to a
certificate based PKI in the style of Kohnfelder (X.509) or Zimmerman certificate based PKI in the style of Kohnfelder (X.509) or Zimmerman
(web of trust). (web of trust).
While message syntax and PKI are orthogonal in principle, While message syntax and PKI are orthogonal in principle,
implementation practice means that most S/MIME clients only support implementation practice means that most S/MIME clients only support
use of keys contained in X.509/PKIX digital certificates. use of keys contained in X.509/PKIX digital certificates.
skipping to change at page 15, line 5 skipping to change at page 27, line 7
The principle disadvantage of using DNS over XKMS is that the DNS is The principle disadvantage of using DNS over XKMS is that the DNS is
a network administration resource designed to answer questions about a network administration resource designed to answer questions about
current network configuration. While it is quite possible to re-use current network configuration. While it is quite possible to re-use
the DNS infrastructure to support queries about past and even future the DNS infrastructure to support queries about past and even future
network configurations this is not the core objective of the network configurations this is not the core objective of the
infrastructure. The DNS is thus unsuited to supporting any use of infrastructure. The DNS is thus unsuited to supporting any use of
digital signatures in which long term archival is desirable or the digital signatures in which long term archival is desirable or the
possibility of repudiation is undesirable. possibility of repudiation is undesirable.
3.5. Domain Level Assurance 5.5. Domain Level Assurance
As previously mentioned PGP and S/MIME were designed in the heyday of As previously mentioned PGP and S/MIME were designed in the heyday of
the security end-to-end principle. It has since been realized that the security end-to-end principle. It has since been realized that
the end points with respect to trust are not the same as the end the end points with respect to trust are not the same as the end
points with respect to the communication protocol. points with respect to the communication protocol.
When Alice sends a personal message to Bob it is Alice the person, When Alice sends a personal message to Bob it is Alice the person,
not the machine Alice happens to be using that is the true trust end not the machine Alice happens to be using that is the true trust end
point. When Alice sends a piece of business correspondence to Bob it point. When Alice sends a piece of business correspondence to Bob it
is her employer. is her employer.
skipping to change at page 15, line 29 skipping to change at page 27, line 31
personal level may be desirable in some circumstances the Internet personal level may be desirable in some circumstances the Internet
now has a billion users. Attempting to achieve accountability in a now has a billion users. Attempting to achieve accountability in a
population of a billion users is impractical, particularly when the population of a billion users is impractical, particularly when the
owner of the domain example.com has the ability to create a owner of the domain example.com has the ability to create a
practically unlimited number of accounts within that domain at will. practically unlimited number of accounts within that domain at will.
The logical unit of accountability for DKIM is therefore the DNS The logical unit of accountability for DKIM is therefore the DNS
domain name to which the signing key record is bound and not the domain name to which the signing key record is bound and not the
individual email user. individual email user.
3.6. Security Policy 5.6. Security Policy
The innovation in DKIM that has no precedent in the previous email The innovation in DKIM that has no precedent in the previous email
security standards is the publication of a security policy. The security standards is the publication of a security policy. The
purpose of DKIM is to allow a party to accept responsibility for an purpose of DKIM is to allow a party to accept responsibility for an
email message by signing it. A message with a signature is treated email message by signing it. A message with a signature is treated
as if it is unsigned. For a recipient to interpret an unsigned as if it is unsigned. For a recipient to interpret an unsigned
message it is necessary to know whether it should expect a message message it is necessary to know whether it should expect a message
from that source to be signed and if so the signature characteristics from that source to be signed and if so the signature characteristics
to expect. to expect.
skipping to change at page 16, line 6 skipping to change at page 28, line 9
publish a policy stating that all legitimate messages from the domain publish a policy stating that all legitimate messages from the domain
are signed. are signed.
While the Sender-ID/SPF security policy format allows application to While the Sender-ID/SPF security policy format allows application to
existing formats including PGP and S/MIME the advantages to existing formats including PGP and S/MIME the advantages to
developing the protocol and security policy in tandem are developing the protocol and security policy in tandem are
considerable. It is not practical to expect to be able to write a considerable. It is not practical to expect to be able to write a
useful sender signing policy for S/MIME or PGP within the constraints useful sender signing policy for S/MIME or PGP within the constraints
of the 512 byte response message size imposed on the legacy DNS. of the 512 byte response message size imposed on the legacy DNS.
4. Implementation Considerations 6. Implementation Considerations
4.1. Development 6.1. Development
What software has to change, to use DKIM? What software has to change, to use DKIM?
4.1.1. Signer 6.1.1. Signer
The signer needs to add code in the appropriate agent, to perform The signer needs to add code in the appropriate agent, to perform
signing, and they need to modify their DNS administrative tools to signing, and they need to modify their DNS administrative tools to
permit creation of DKIM key records. permit creation of DKIM key records.
4.1.2. Validator 6.1.2. Validator
A validator needs to add code to the appropriate agent and then feed A validator needs to add code to the appropriate agent and then feed
the result into the portion of their system needing it, such as a the result into the portion of their system needing it, such as a
filtering engine. filtering engine.
The mere existence of a valid signature does not imply that the mail The mere existence of a valid signature does not imply that the mail
is acceptable, such as for delivery. Acceptability requires an is acceptable, such as for delivery. Acceptability requires an
assessment phase. Hence the result of signature validation must be assessment phase. Hence the result of signature validation must be
fed into a vetting mechanism that is part of the validator's filter. fed into a vetting mechanism that is part of the validator's filter.
4.1.3. Outbound mail user agent 6.1.3. Outbound mail user agent
TBD TBD
4.1.4. Outbound mail transport agent 6.1.4. Outbound mail transport agent
TBD TBD
4.1.5. DNS Server 6.1.5. DNS Server
TBD TBD
4.1.6. Mailing list manager 6.1.6. Mailing list manager
TBD TBD
4.1.7. Inbound mail transport agent 6.1.7. Inbound mail transport agent
TBD TBD
4.1.8. Inbound mail user agent 6.1.8. Inbound mail user agent
TBD TBD
4.1.9. Accreditation service 6.1.9. Accreditation service
TBD TBD
4.2. Deployment 6.2. Deployment
4.2.1. Signing 6.2.1. Signing
4.2.1.1. DNS Records 6.2.1.1. DNS Records
add sig key info add sig key info
4.2.1.2. Signing Module 6.2.1.2. Signing Module
Delete old signs with same key; add new sig Delete old signs with same key; add new sig
4.2.1.3. Boundary MTA 6.2.1.3. Boundary MTA
Enforce signature policies and practises Enforce signature policies and practises
4.2.2. Verifying 6.2.2. Verifying
4.2.2.1. DNS Client 6.2.2.1. DNS Client
Ensure able to obtain DKIM key sig records Ensure able to obtain DKIM key sig records
4.2.2.2. Verifying module 6.2.2.2. Verifying module
Validate sig; channel info to filtering engine. Maybe provide user- Validate sig; channel info to filtering engine. Maybe provide user-
visible info. visible info.
4.2.2.3. Boundary MTA 6.2.2.3. Boundary MTA
Strip "local" signatures that are not local? Strip "local" signatures that are not local?
4.3. Operations 6.3. Operations
4.3.1. DNS Signature Record Deployment Considerations 6.3.1. DNS Signature Record Deployment Considerations
TBD TBD
4.3.2. Thoughts on Expiring Signatures 6.3.2. Thoughts on Expiring Signatures
TBD TBD
4.3.3. DNS Policy Record Deployment Considerations 6.3.3. DNS Policy Record Deployment Considerations
TBD TBD
4.3.4. Subdomain Considerations 6.3.4. Subdomain Considerations
TBD TBD
4.3.5. Third party Signature Delegations 6.3.5. Third party Signature Delegations
TBD TBD
5. Outline Future Extensions 7. Outline Future Extensions
The design of DKIM is unapologetically focused on overcoming the need The design of DKIM is unapologetically focused on overcoming the need
for immediate deployment and achieving ubiquitous use in the near for immediate deployment and achieving ubiquitous use in the near
future. As such the original design discussions have generally taken future. As such the original design discussions have generally taken
the approach 'if in doubt leave it out'. the approach 'if in doubt leave it out'.
The need to exclude consideration of these features in the near term The need to exclude consideration of these features in the near term
is in no way intended to preclude their development at a later date. is in no way intended to preclude their development at a later date.
Nor is the lack of a specification describing the use of DKIM with a Nor is the lack of a specification describing the use of DKIM with a
different PKI infrastructure intended to indicate an intention to different PKI infrastructure intended to indicate an intention to
skipping to change at page 19, line 14 skipping to change at page 31, line 14
three way stalemate. three way stalemate.
Another possible future is that DKIM provides the 'bootstrap' that Another possible future is that DKIM provides the 'bootstrap' that
enables ubiquitous use of legacy infrastructure including the enables ubiquitous use of legacy infrastructure including the
deployed base of PGP and S/MIME capable email clients and the deployed base of PGP and S/MIME capable email clients and the
existing business infrastructure of commercial Certificate existing business infrastructure of commercial Certificate
Authorities. Such a strategy would make use of DKIM in conjunction Authorities. Such a strategy would make use of DKIM in conjunction
with existing PKI standards such as PKIX and XKMS and leverage with existing PKI standards such as PKIX and XKMS and leverage
features of PGP and S/MIME where appropriate. features of PGP and S/MIME where appropriate.
5.1. Introducing a new signing algorithm 7.1. Introducing a new signing algorithm
Regardless of whether extension of the DKIM feature set is desirable Regardless of whether extension of the DKIM feature set is desirable
the need to replace the signature algorithm is practically a the need to replace the signature algorithm is practically a
certainty. The RSA signature algorithm at best provides equivalent certainty. The RSA signature algorithm at best provides equivalent
security to an 80 bit symmetric cipher when used with a 1024 bit key security to an 80 bit symmetric cipher when used with a 1024 bit key
[cite]. Extending the key size to 2048 bits improves the cipher [cite]. Extending the key size to 2048 bits improves the cipher
strength to only 112 bit equivalence. Achieving 128 bit security strength to only 112 bit equivalence. Achieving 128 bit security
requires a minimum of 3072 bits. Achieving equivalent cipher requires a minimum of 3072 bits. Achieving equivalent cipher
strength to a 192 bit symmetric algorithm requires a prohibitive key strength to a 192 bit symmetric algorithm requires a prohibitive key
size. size.
skipping to change at page 19, line 41 skipping to change at page 31, line 41
The default DNS response packet limit of 512 bytes places an The default DNS response packet limit of 512 bytes places an
effective upper bound of 4096 bits on a DKIM key. In practice the effective upper bound of 4096 bits on a DKIM key. In practice the
need for packaging, meta-data and the desirability of using DNSSEC to need for packaging, meta-data and the desirability of using DNSSEC to
sign the record reduces the upper bound to no more than 2048 bits. sign the record reduces the upper bound to no more than 2048 bits.
The size of the DKIM signature itself is a weaker constraint. Even The size of the DKIM signature itself is a weaker constraint. Even
so, while 1024 and even 2048 bit signatures are likely to be so, while 1024 and even 2048 bit signatures are likely to be
acceptable in most implementations larger signature sizes may become acceptable in most implementations larger signature sizes may become
prohibitive, particularly as the signature must be Base 64 encoded. prohibitive, particularly as the signature must be Base 64 encoded.
5.2. Possible future signature algorithm choices 7.2. Possible future signature algorithm choices
ECC cryptography offers a means of implementing public key ECC cryptography offers a means of implementing public key
cryptography using a key size and signature size that are each only cryptography using a key size and signature size that are each only
twice the size of the equivalent symmetric key algorithm. twice the size of the equivalent symmetric key algorithm.
While ECC offers clear technical advantages over algorithms based on While ECC offers clear technical advantages over algorithms based on
the difficulty on solving the discrete log problem in a finite field the difficulty on solving the discrete log problem in a finite field
it is not possible at this point to be confident that a means of it is not possible at this point to be confident that a means of
applying ECC that is consistent with the position on intellectual applying ECC that is consistent with the position on intellectual
property adopted by the DKIM working group has been found. property adopted by the DKIM working group has been found.
skipping to change at page 20, line 21 skipping to change at page 32, line 21
the design of DSA if key sizes greater than 512 bits and use of hash the design of DSA if key sizes greater than 512 bits and use of hash
functions stronger than SHA-1 had been supported at the time. In functions stronger than SHA-1 had been supported at the time. In
March 2006 a proposed revision of the DSA signature algorithm March 2006 a proposed revision of the DSA signature algorithm
answered these objections permitting larger key sizes and specifying answered these objections permitting larger key sizes and specifying
use of stronger hash functions including SHA-256 and SHA 512. While use of stronger hash functions including SHA-256 and SHA 512. While
the advantages offered by DSA are not sufficient to warrant an the advantages offered by DSA are not sufficient to warrant an
immediate transition to the new algorithm at this late stage it is immediate transition to the new algorithm at this late stage it is
highly probably that the algorithm will be employed by DNSSEC when highly probably that the algorithm will be employed by DNSSEC when
finally deployed. finally deployed.
5.3. Transition strategy 7.3. Transition strategy
Deployment of a new signature algorithm without a 'flag day' requires Deployment of a new signature algorithm without a 'flag day' requires
a transition strategy such that signers and verifiers can phase in a transition strategy such that signers and verifiers can phase in
support for the new algorithm independently and if necessary phase support for the new algorithm independently and if necessary phase
out support for the old algorithm independently. out support for the old algorithm independently.
DKIM achieves these requirements through two features. First a DKIM achieves these requirements through two features. First a
signed message may contain multiple signatures created by the same signed message may contain multiple signatures created by the same
signer. Secondly the security policy layer allows the signing signer. Secondly the security policy layer allows the signing
algorithms in use to be advertised, thus preventing a downgrade algorithms in use to be advertised, thus preventing a downgrade
attack. attack.
5.3.1. Signer transition strategy 7.3.1. Signer transition strategy
Let the old signing algorithm be A, the new signing algorithm be B. Let the old signing algorithm be A, the new signing algorithm be B.
The sequence of events by which a Signer may introduce a new signing The sequence of events by which a Signer may introduce a new signing
algorithm without disruption of service to legacy verifiers is as algorithm without disruption of service to legacy verifiers is as
follows: follows:
1. Signer signs with algorithm A 1. Signer signs with algorithm A
A. Signer advertises that it signs with algorithm A A. Signer advertises that it signs with algorithm A
skipping to change at page 21, line 16 skipping to change at page 33, line 16
4. Signer determines that support for algorithm A it to be withdrawn 4. Signer determines that support for algorithm A it to be withdrawn
A. Signer removes advertisement for Algorithm A A. Signer removes advertisement for Algorithm A
B. Signer waits for cached copies of earlier signature policy to B. Signer waits for cached copies of earlier signature policy to
expire expire
C. Signer stops signing with Algorithm A C. Signer stops signing with Algorithm A
5.3.2. Verifier transition strategy 7.3.2. Verifier transition strategy
The actions of the verifier are independent of the signer's actions The actions of the verifier are independent of the signer's actions
and do not need to be performed in a particular sequence. The and do not need to be performed in a particular sequence. The
verifier may make a decision to cease accepting algorithm A without verifier may make a decision to cease accepting algorithm A without
first deploying support for algorithm B. Similarly a verifier may be first deploying support for algorithm B. Similarly a verifier may be
upgraded to support algorithm B without requiring algorithm B to be upgraded to support algorithm B without requiring algorithm B to be
withdrawn. The decisions of the verifier must make are therefore: withdrawn. The decisions of the verifier must make are therefore:
o The verifier MAY change the degree of confidence associated with The verifier MAY change the degree of confidence associated with
any signature at any time, including determining that a given any signature at any time, including determining that a given
signature algorithm provides a limited assurance of authenticity signature algorithm provides a limited assurance of authenticity
at a given key strength. at a given key strength.
A. A verifier MAY chose to evaluate signature records in any A. A verifier MAY chose to evaluate signature records in any
order it chooses, including making use of the signature order it chooses, including making use of the signature
algorithm for this purpose. algorithm for this purpose.
o The verifier MAY make a determination that Algorithm A does not The verifier MAY make a determination that Algorithm A does not
offer a useful level of security, that the cost of verifying the offer a useful level of security, that the cost of verifying the
signature is less than the value of doing so. signature is less than the value of doing so.
A. In this case the verifier ignores signatures created using the A. In this case the verifier ignores signatures created using the
algorithm A and references to algorithm A in policy records algorithm A and references to algorithm A in policy records
are treated as if the algorithm is not implemented. are treated as if the algorithm is not implemented.
o The verifier MAY decide to add support for additional signature The verifier MAY decide to add support for additional signature
algorithms at any time. algorithms at any time.
A. The verified MAY add support for algorithm B at any time. A. The verified MAY add support for algorithm B at any time.
5.4. Linkage to Other PKIs 7.4. Linkage to Other PKIs
The principle limitations in DKIM are the lack of support for end- The principle limitations in DKIM are the lack of support for end-
user keying, the lack of support for long term verification of user keying, the lack of support for long term verification of
signatures and the lack of support for trusted third party issued signatures and the lack of support for trusted third party issued
assertions. Each of these limitations is determined by the key assertions. Each of these limitations is determined by the key
distribution mechanism rather than the signature format. distribution mechanism rather than the signature format.
Although the DNS infrastructure could in principle be extended to Although the DNS infrastructure could in principle be extended to
support these features this approach would require substantial support these features this approach would require substantial
modifications that entirely negate the advantage of employing an modifications that entirely negate the advantage of employing an
existing infrastructure. The point of using DNS is to reuse the DNS existing infrastructure. The point of using DNS is to reuse the DNS
infrastructure, not the DNS protocol. infrastructure, not the DNS protocol.
The preferred approach to addressing these limitations is to support The preferred approach to addressing these limitations is to support
use of a PKI infrastructure designed to support these requirements use of a PKI infrastructure designed to support these requirements
such as PKIX, PGP or XKMS. such as PKIX, PGP or XKMS.
5.5. Trusted Third Party Assertions 7.5. Trusted Third Party Assertions
A DKIM signature tells the signature verifier that the owner of a A DKIM signature tells the signature verifier that the owner of a
particular domain name accepts responsibility for the message. particular domain name accepts responsibility for the message.
Combining this information with information that allows the behavior Combining this information with information that allows the behavior
of the domain name owner to be predicted may allow the probability of the domain name owner to be predicted may allow the probability
that the message is abusive to be determined without the need for that the message is abusive to be determined without the need for
heuristic content analysis. heuristic content analysis.
Recipients of large volumes of email can generate reputation data for Recipients of large volumes of email can generate reputation data for
email senders internally. Recipients of smaller volumes of messages email senders internally. Recipients of smaller volumes of messages
skipping to change at page 23, line 9 skipping to change at page 35, line 9
Smaller recipients are not in a position to require accreditation, Smaller recipients are not in a position to require accreditation,
nor is it practical for each large sender to accredit every sender. nor is it practical for each large sender to accredit every sender.
Trusted Third Party accreditation services allow an email sender to Trusted Third Party accreditation services allow an email sender to
obtain an accreditation that is recognized by every email recipient obtain an accreditation that is recognized by every email recipient
that recognizes the Trusted Third Party. that recognizes the Trusted Third Party.
[Need use of both systems] [Need use of both systems]
[Need means of advertising existence of positive reputation data] [Need means of advertising existence of positive reputation data]
5.6. Linkage to X.509 Certificates 7.6. Linkage to X.509 Certificates
The industry standard for distribution of Trusted Third Party data The industry standard for distribution of Trusted Third Party data
tied to a public key is the X.509v3/PKIX standard. X.509 based PKI tied to a public key is the X.509v3/PKIX standard. X.509 based PKI
is designed to support requirements such as long term archiving of is designed to support requirements such as long term archiving of
signatures, end entity signing and Trusted Third Party assertions. signatures, end entity signing and Trusted Third Party assertions.
Combining the DKIM signature format with the PKIX PKI infrastructure Combining the DKIM signature format with the PKIX PKI infrastructure
provides an equivalent set of capabilities to S/MIME. provides an equivalent set of capabilities to S/MIME.
Two approaches may be used to inform signature verifiers that an Two approaches may be used to inform signature verifiers that an
X.509 certificate has been issued that makes an assertion about the X.509 certificate has been issued that makes an assertion about the
skipping to change at page 23, line 49 skipping to change at page 35, line 49
In other cases a signer may intentionally discourage transport In other cases a signer may intentionally discourage transport
verification by only providing an X.509 certificate. verification by only providing an X.509 certificate.
An X.509 application of particular interest is the use of DKIM as a An X.509 application of particular interest is the use of DKIM as a
signature format for Secure Internet Letterhead (Letterhead). signature format for Secure Internet Letterhead (Letterhead).
Letterhead employs X.509 certificates containing a LOGOTYPE attribute Letterhead employs X.509 certificates containing a LOGOTYPE attribute
extension [LOGOTYPE] to identify the certificate subject and/or extension [LOGOTYPE] to identify the certificate subject and/or
issuer to the user by means of a brand image such as a corporate issuer to the user by means of a brand image such as a corporate
logo. [PHB-NIST] logo. [PHB-NIST]
5.7. XKMS 7.7. XKMS
XKMS is a key centric PKI that supports registration and location of XKMS is a key centric PKI that supports registration and location of
keys. XKMS is layered as a Web service and the existence of XKMS keys. XKMS is layered as a Web service and the existence of XKMS
service for a domain is typically advertised by means of a DNS SRV service for a domain is typically advertised by means of a DNS SRV
record. record.
XKISS, the key location component of XKMS provides a superset of the XKISS, the key location component of XKMS provides a superset of the
capabilities of the DKIM DNS key distribution mechanism. As XKMS is capabilities of the DKIM DNS key distribution mechanism. As XKMS is
layered on SOAP over HTTP over TCP/IP the overhead incurred in layered on SOAP over HTTP over TCP/IP the overhead incurred in
retrieving keys through XKMS is substantially higher than the single retrieving keys through XKMS is substantially higher than the single
skipping to change at page 24, line 31 skipping to change at page 36, line 31
X.509 based PKI that makes use of sophisticated features such as X.509 based PKI that makes use of sophisticated features such as
cross certification. The verifier may at its option rely on the XKMS cross certification. The verifier may at its option rely on the XKMS
service to provide a trusted key or request the complete certificate service to provide a trusted key or request the complete certificate
path allowing offline verification. path allowing offline verification.
A signer may notify signature verifiers that a key may be retrieved A signer may notify signature verifiers that a key may be retrieved
using XKMS by means of the q= attribute. The verifier may then using XKMS by means of the q= attribute. The verifier may then
discover the corresponding XKMS service using the SRV mechanism as discover the corresponding XKMS service using the SRV mechanism as
setout in the XKMS specification. setout in the XKMS specification.
5.8. Verification in the Client 7.8. Verification in the Client
The DKIM specification is designed to support edge to edge The DKIM specification is designed to support edge to edge
authentication. The specification neither supports nor prohibits authentication. The specification neither supports nor prohibits
verification of DKIM signatures in the client. In particular the verification of DKIM signatures in the client. In particular the
specification does not attempt to define client semantics for specification does not attempt to define client semantics for
signatures or provide an exhaustive list of user interface security signatures or provide an exhaustive list of user interface security
considerations. considerations.
For client based verification to be practical it is likely the a For client based verification to be practical it is likely the a
client needs to be capable of determining that it is able to receive client needs to be capable of determining that it is able to receive
messages that do not get clobbered before coming to any conclusions messages that do not get clobbered before coming to any conclusions
with respect to unsigned messages. with respect to unsigned messages.
DKIM requires that all verifiers treat messages with signatures that DKIM requires that all verifiers treat messages with signatures that
do not verify as if they are unsigned. If verification in the client do not verify as if they are unsigned. If verification in the client
is to be acceptable to users it is also essential that successful is to be acceptable to users it is also essential that successful
verification of a signature does not result in a less satisfactory verification of a signature does not result in a less satisfactory
user experience than leaving the message unsigned. user experience than leaving the message unsigned.
5.9. Per user signature 7.9. Per user signature
Although DKIM is designed to support domain level signatures the DKIM Although DKIM is designed to support domain level signatures the DKIM
core design neither supports nor prohibits use of per user core design neither supports nor prohibits use of per user
signatures. A DKIM key record can specify restrictions on the email signatures. A DKIM key record can specify restrictions on the email
addresses it can be used to sign for. These restrictions are not addresses it can be used to sign for. These restrictions are not
intended to be exhaustive nor are detailed semantics or security intended to be exhaustive nor are detailed semantics or security
considerations set out for interpreting per user signatures. The considerations set out for interpreting per user signatures. The
primary use this feature is intended to support is to allow a company primary use this feature is intended to support is to allow a company
to delegate signing authority for bulk marketing communications to delegate signing authority for bulk marketing communications
without the risk of effectively delegating the authority to sign without the risk of effectively delegating the authority to sign
skipping to change at page 25, line 30 skipping to change at page 37, line 30
as the ability to perform long term validation of the key. Linkage as the ability to perform long term validation of the key. Linkage
to some form of PKI is likely to be necessary. to some form of PKI is likely to be necessary.
In addition any scheme that involves maintenance of a significant In addition any scheme that involves maintenance of a significant
number of public keys will require infrastructure to support that number of public keys will require infrastructure to support that
management. A system in which the end user is required to generate a management. A system in which the end user is required to generate a
public key pair and transmit it to the DNS administrator out of band public key pair and transmit it to the DNS administrator out of band
is not likely to meet acceptance criteria for either usability or is not likely to meet acceptance criteria for either usability or
security. As a minimum a key registration protocol must be defined. security. As a minimum a key registration protocol must be defined.
5.10. Encryption 7.10. Encryption
DKIM is not designed to support encryption. A strong case can be DKIM is not designed to support encryption. A strong case can be
made for applying the DKIM style of transparent security, key centric made for applying the DKIM style of transparent security, key centric
key management and domain level keying. It is not clear that re- key management and domain level keying. It is not clear that re-
using the DKIM signature architecture is the best way to achieve this using the DKIM signature architecture is the best way to achieve this
goal. goal.
The DKIM signature format in particular is designed to allow meta- The DKIM signature format in particular is designed to allow meta-
data to be attached to a message without modifying the content. data to be attached to a message without modifying the content.
Content encryption by its very nature requires modification of the Content encryption by its very nature requires modification of the
skipping to change at page 26, line 9 skipping to change at page 38, line 9
encrypted email messages are acceptable and to specify key encrypted email messages are acceptable and to specify key
distribution infrastructure(s) by which the necessary encryption keys distribution infrastructure(s) by which the necessary encryption keys
may be discovered. may be discovered.
A policy infrastructure of this type is implicit in the XKMS A policy infrastructure of this type is implicit in the XKMS
standard. One drawback to this approach is that policy distribution standard. One drawback to this approach is that policy distribution
an key distribution are conflated, an approach hat is satisfactory an key distribution are conflated, an approach hat is satisfactory
for message level encryption schemes such as PGP and S/MIME but less for message level encryption schemes such as PGP and S/MIME but less
satisfactory for transport layer encryption such as SSL. satisfactory for transport layer encryption such as SSL.
5.11. Reuse of Key Record 7.11. Reuse of Key Record
A number of proposals have been made which attempt to reuse the DKIM A number of proposals have been made which attempt to reuse the DKIM
key record. Architects considering this approach should be aware of key record. Architects considering this approach should be aware of
the advantages and limitations. the advantages and limitations.
As a minimum each of the security considerations listed in the DKIM As a minimum each of the security considerations listed in the DKIM
specification should be considered and its possible relevance to the specification should be considered and its possible relevance to the
proposed field of use carefully evaluated. Application of a security proposed field of use carefully evaluated. Application of a security
mechanism outside the context in which it was originally designed for mechanism outside the context in which it was originally designed for
is a principle cause of security failures. is a principle cause of security failures.
skipping to change at page 26, line 48 skipping to change at page 38, line 48
immediate need. As such many of the design decisions are not the immediate need. As such many of the design decisions are not the
decisions that would be taken if the choice was unconstrained by the decisions that would be taken if the choice was unconstrained by the
limitations of the current legacy DNS. In particular the use of Base limitations of the current legacy DNS. In particular the use of Base
64 encoded public keys distributed through TXT records is not ideal. 64 encoded public keys distributed through TXT records is not ideal.
Applications that do not face the same constraints as DKIM should Applications that do not face the same constraints as DKIM should
carefully evaluate the feasibility of using the binary key record. carefully evaluate the feasibility of using the binary key record.
In particular an application predicated on the use of DNSSEC to In particular an application predicated on the use of DNSSEC to
authenticate keys should assume support for DKIM binary key records. authenticate keys should assume support for DKIM binary key records.
5.12. Use of Policy Record 7.12. Use of Policy Record
DKIM demonstrates the power of using the DNS to distribute security DKIM demonstrates the power of using the DNS to distribute security
policy information. It is not possible to achieve robust security policy information. It is not possible to achieve robust security
unless the parties to a conversation know the security capabilities unless the parties to a conversation know the security capabilities
and expectations of the other. and expectations of the other.
Any party proposing re-use of the DKIM policy record should carefully Any party proposing re-use of the DKIM policy record should carefully
consider whether their needs would be better met by proposing a consider whether their needs would be better met by proposing a
flexible security policy architecture in the DKIM style rather than flexible security policy architecture in the DKIM style rather than
proposing ad-hoc extensions and variations. proposing ad-hoc extensions and variations.
At a minimum any proposal for new security policy formats that make At a minimum any proposal for new security policy formats that make
use of the TXT record should employ a new policy prefix and ensure use of the TXT record should employ a new policy prefix and ensure
that mislabeled and wild-carded policy records are not accidentally that mislabeled and wild-carded policy records are not accidentally
misinterpreted. misinterpreted.
6. What Needs To Be Moved Here From the Base Doc? 8. What Needs To Be Moved Here From the Base Doc?
MUA considerations MUA considerations
key delegation/ 3rd party key delegation/ 3rd party
7. Acknowledgements 9. Acknowledgements
TBD TBD
8. Informative References 10. Informative References
[I-D.ietf-dkim-base] [I-D.ietf-dkim-base]
Allman, E., "DomainKeys Identified Mail Signatures Allman, E., "DomainKeys Identified Mail Signatures
(DKIM)", draft-ietf-dkim-base-02 (work in progress), (DKIM)", draft-ietf-dkim-base-02 (work in progress),
May 2006. May 2006.
[I-D.ietf-dkim-threats] [I-D.ietf-dkim-threats]
Fenton, J., "Analysis of Threats Motivating DomainKeys Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", draft-ietf-dkim-threats-03 (work Identified Mail (DKIM)", draft-ietf-dkim-threats-03 (work
in progress), May 2006. in progress), May 2006.
skipping to change at page 29, line 7 skipping to change at page 41, line 7
Object Security Services", RFC 1848, October 1995. Object Security Services", RFC 1848, October 1995.
[RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
Exchange Formats", RFC 1991, August 1996. Exchange Formats", RFC 1991, August 1996.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
Authors' Addresses Authors' Addresses
Tony Hansen (editor) Tony Hansen
AT&T Laboratories AT&T Laboratories
200 Laurel Ave. 200 Laurel Ave.
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Email: tony+dkimov@maillennium.att.com Email: tony+dkimov@maillennium.att.com
Dave Crocker Dave Crocker
Brandenburg InternetWorking Brandenburg InternetWorking
675 Spruce Dr. 675 Spruce Dr.
 End of changes. 101 change blocks. 
179 lines changed or deleted 672 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/