draft-ietf-dkim-overview-01.txt   draft-ietf-dkim-overview-02.txt 
DomainKeys Identified Mail T. Hansen DomainKeys Identified Mail T. Hansen
Internet-Draft AT&T Laboratories Internet-Draft AT&T Laboratories
Expires: December 27, 2006 D. Crocker Intended status: Informational D. Crocker
Brandenburg InternetWorking Expires: April 25, 2007 Brandenburg InternetWorking
P. Hallam-Baker P. Hallam-Baker
VeriSign Inc. VeriSign Inc.
June 25, 2006 October 22, 2006
DomainKeys Identified Mail (DKIM) Service Overview DomainKeys Identified Mail (DKIM) Service Overview
draft-ietf-dkim-overview-01.txt draft-ietf-dkim-overview-02
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 27, 2006. This Internet-Draft will expire on April 25, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
DomainKeys Identified Mail (DKIM) associates a "responsible" identity DomainKeys Identified Mail (DKIM) associates a "responsible" identity
with a message and provides a means of verifying that the association with a message and provides a means of verifying that the association
is legitimate.[I-D.ietf-dkim-base]. DKIM defines a domain-level is legitimate.[I-D.ietf-dkim-base]. DKIM defines a domain-level
authentication framework for email using public-key cryptography and authentication framework for email using public-key cryptography and
key server technology to permit verification of the source and key server technology. This permits verifying the source or
contents of messages by either Mail Transfer Agents (MTAs) or Mail intermediary for a message, as well as the contents of messages. The
User Agents (MUAs). The ultimate goal of this framework is to permit ultimate goal of this framework is to permit a signing domain to
a signing domain to assert responsibility for a message, thus proving assert responsibility for a message, thus proving and protecting the
and protecting message sender identity and the integrity of the identity associated with the message and the integrity of the
messages they convey while retaining the functionality of Internet messages itself, while retaining the functionality of Internet email
email as it is known today. Proof and protection of email identity, as it is known today. Such protection of email identity, may assist
including repudiation and non-repudiation, may assist in the global in the global control of "spam" and "phishing". This document
control of "spam" and "phishing". provides an overview of DKIM and describes how it can fit into a
messaging service, how it relates to other IETF message signature
This document provides an overview of DomainKeys Identified Mail and technologies. It also includes implementation and migration
how it can fit into overall messaging systems, how it relates to considerations.
other IETF message signature technologies, implementation and
migration considerations, and outlines potential DKIM applications
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. About This Document . . . . . . . . . . . . . . . . . . . 4 2. The DKIM Value Proposition . . . . . . . . . . . . . . . . . . 6
1.2. A Quick Overview of DKIM . . . . . . . . . . . . . . . . . 4 3. DKIM's Goals . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Outline Potential DKIM Applications . . . . . . . . . . . 7 3.1. Treat verification failure as if unsigned. . . . . . . . 8
2. DKIM Within Existing Internet Email . . . . . . . . . . . . . 7 3.2. Domain-level assurance . . . . . . . . . . . . . . . . . 8
2.1. Review of Internet Mail Service Architecture . . . . . . . 7 3.3. Incremental adoption . . . . . . . . . . . . . . . . . . 8
2.2. Where to Place DKIM Functions . . . . . . . . . . . . . . 10 3.4. Minimal infrastructure . . . . . . . . . . . . . . . . . 9
2.3. Impact on Email Activities . . . . . . . . . . . . . . . . 11 3.5. Transparent signature . . . . . . . . . . . . . . . . . . 9
2.4. Migrating from DomainKeys . . . . . . . . . . . . . . . . 12 3.6. Security policy . . . . . . . . . . . . . . . . . . . . . 9
2.5. { Misc Text -- Should go elsewhere, if used at all } . . . 13 4. A Quick Overview of DKIM . . . . . . . . . . . . . . . . . . . 9
3. DKIM Within Existing Internet Email . . . . . . . . . . . . . 14 4.1. What is a DKIM signature? . . . . . . . . . . . . . . . . 10
3.1. Review of Internet Mail Service Architecture . . . . . . . 14 4.2. The Selector construct . . . . . . . . . . . . . . . . . 10
3.2. Where to Place DKIM Functions . . . . . . . . . . . . . . 17 4.3. Who validates the signature? . . . . . . . . . . . . . . 10
3.3. Impact on Email Activities . . . . . . . . . . . . . . . . 17 4.4. What does DKIM NOT do? . . . . . . . . . . . . . . . . . 11
3.4. Migrating from DomainKeys . . . . . . . . . . . . . . . . 18 4.5. Does DKIM eliminate anonymity for email? . . . . . . . . 11
3.5. { Misc Text -- Should go elsewhere, if used at all } . . . 19 4.6. Outline potential DKIM applications . . . . . . . . . . . 11
4. DKIM Service Architecture . . . . . . . . . . . . . . . . . . 21 4.7. What is a DKIM policy? . . . . . . . . . . . . . . . . . 11
5. Relationship to previous Message Signature Technologies . . . 23 5. DKIM Within Existing Internet Email . . . . . . . . . . . . . 12
5.1. Transparent Signature . . . . . . . . . . . . . . . . . . 23 5.1. Review of Internet Mail Service Architecture . . . . . . 12
5.2. Treat verification failure as if unsigned. . . . . . . . . 24 5.2. Where to Place DKIM Functions . . . . . . . . . . . . . . 15
5.3. Legacy Client Semantics . . . . . . . . . . . . . . . . . 25 5.3. Impact on Email Activities . . . . . . . . . . . . . . . 16
5.4. Key Centric PKI . . . . . . . . . . . . . . . . . . . . . 25 5.4. Migrating from DomainKeys . . . . . . . . . . . . . . . . 18
5.5. Domain Level Assurance . . . . . . . . . . . . . . . . . . 27 6. DKIM Service Architecture . . . . . . . . . . . . . . . . . . 19
5.6. Security Policy . . . . . . . . . . . . . . . . . . . . . 27 7. Implementation Considerations . . . . . . . . . . . . . . . . 21
6. Implementation Considerations . . . . . . . . . . . . . . . . 28 7.1. Development . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. Development . . . . . . . . . . . . . . . . . . . . . . . 28 7.2. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2. Deployment . . . . . . . . . . . . . . . . . . . . . . . . 29 7.3. DNS Server . . . . . . . . . . . . . . . . . . . . . . . 24
6.3. Operations . . . . . . . . . . . . . . . . . . . . . . . . 29 7.4. Accreditation service . . . . . . . . . . . . . . . . . . 24
7. Outline Future Extensions . . . . . . . . . . . . . . . . . . 30 8. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Introducing a new signing algorithm . . . . . . . . . . . 31 8.1. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2. Possible future signature algorithm choices . . . . . . . 31 8.2. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 26
7.3. Transition strategy . . . . . . . . . . . . . . . . . . . 32 8.3. Transition strategy . . . . . . . . . . . . . . . . . . . 27
7.4. Linkage to Other PKIs . . . . . . . . . . . . . . . . . . 33 9. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.5. Trusted Third Party Assertions . . . . . . . . . . . . . . 34 9.1. DNS Signature Record Deployment Considerations . . . . . 28
7.6. Linkage to X.509 Certificates . . . . . . . . . . . . . . 35 10. Outline Future Extensions . . . . . . . . . . . . . . . . . . 31
7.7. XKMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.1. Introducing a new signing algorithm . . . . . . . . . . . 32
7.8. Verification in the Client . . . . . . . . . . . . . . . . 36 10.2. Possible future signature algorithm choices . . . . . . . 32
7.9. Per user signature . . . . . . . . . . . . . . . . . . . . 37 10.3. Linkage to Other PKIs . . . . . . . . . . . . . . . . . . 33
7.10. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 37 10.4. Trusted Third Party Assertions . . . . . . . . . . . . . 33
7.11. Reuse of Key Record . . . . . . . . . . . . . . . . . . . 38 10.5. Linkage to X.509 Certificates . . . . . . . . . . . . . . 34
7.12. Use of Policy Record . . . . . . . . . . . . . . . . . . . 38 10.6. XKMS . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8. What Needs To Be Moved Here From the Base Doc? . . . . . . . . 39 10.7. Verification in the Client . . . . . . . . . . . . . . . 36
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 10.8. Per user signature . . . . . . . . . . . . . . . . . . . 36
10. Informative References . . . . . . . . . . . . . . . . . . . . 39 10.9. Encryption . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 10.10. Reuse of Key Record . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . . . 42 10.11. Use of Policy Record . . . . . . . . . . . . . . . . . . 38
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
12. { Misc Text -- Should go elsewhere, if used at all } . . . . . 38
12.1. What Needs To Be Moved Here From the Base Doc? . . . . . 39
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
13.1. References -- Normative . . . . . . . . . . . . . . . . . 39
13.2. Informative References . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . . . 41
1. Introduction 1. Introduction
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 is intended for those who are adopting, developing, or
those who are developing DKIM; those who are deploying DKIM; and deploying DKIM. It also will be helpful for those who are
those who are considering extending DKIM, either into other areas or considering extending DKIM, either into other areas or to support
to provide additional features. additional features. This Overview does not provide information on
threats to DKIM or email, or details on the protocol specifics, which
can be found in [I-D.ietf-dkim-base] and [I-D.ietf-dkim-threats],
respectively. The document assumes a background in basic network
security technology and services.
This document does not provide information on threats to DKIM or NOTE: It must be stressed that neither this document nor DKIM
email, or details on the implementation. Such information can be attempt to provide solutions to the world's problems with spam,
found in other RFC documents.[I-D.ietf-dkim-base] [I-D.ietf-dkim- phish, virii, worms, joe jobs, etc. DKIM creates one, basic tool
threats] Nor does this document describe how to solve the world's in what needs to be a large arsenal of tools, for improving the
problems with spam, phish, virii, worms, joe jobs, etc. safety of Internet mail. However by itself, DKIM is not
sufficient to that task and this Overview does not pursue the
issues of integrating DKIM into these larger efforts. Rather, it
is a basic introduction to the technology and its deployment.
[ NOTE: a number of sections in this document are just placeholders NOTE: A number of sections in this document are just placeholders,
for now ] for now.
1.2. A Quick Overview of DKIM There have been four other efforts at standardizing an email
signature scheme:
1.2.1. Axiom: Ubiquitous Authentication is Good o Privacy Enhanced Mail (PEM) was first published in 1987 [RFC0989]
and eventually transformed into MIME Object Security Services in
1995 [RFC1848]. Today, they are only of historical interest.
DKIM builds on previous work in the form of Domain Keys, Identified o Pretty Good Privacy (PGP) was developed by Phil Zimmerman and
Internet Mail, Authenticated Sender, Meta-Mail, etc. The starting first released in 1991.[RFC1991] A later version was standardized
point for all of these technologies, and now DKIM, is the belief that as OpenPGP. [RFC3156]
authenticating email is a good thing to do in and of itself. It has
been pointed out that it is unlikely that RFC 822 [RFC0822] would
pass today without some form of strong authentication mechanism.
DKIM provides such a strong authentication mechanism.
The ultimate goal of DKIM is to achieve a situation where email o RSA Security, the holder of the patent rights to the principle
authentication is ubiquitous and the unsigned email becomes the public key cryptography algorithm, independently developed Secure
exception the rule, as is the case today. Only when the majority of MIME (S/MIME) to transport a PKCS #7 data object. [RFC3851]
Internet email is authenticated is it possible to make interesting
conclusions about the lack of authentication.
It follows then that a new message signature scheme is required to Development of S/MIME and OpenPGP has continued. While both have
meet the goal of ubiquitous authentication. In each of the above- achieved a significant user base neither has achieved ubiquity in
mentioned proposals, several design elements are shared: deployment or use and their goals differ from those of DKIM.
o The signature is carried in the message header and does not affect In principle the S/MIME protocol can support semantics such as domain
the message body. level signatures or make use of keys stored in the DNS. However the
currently deployed base does not and modifying it to do so would
require extensive effort.
o The signature may include certain headers. Unlike all four previous IETF email security initiatives, DKIM
employs a key centric Public Key Infrastructure (PKI) as opposed to
one that is based on a certificate in the style of Kohnfelder (X.509)
or Zimmerman (web of trust). That is, the owner of a key asserts its
validity, rather than relying on having a broader semantic
implication of the assertion, such as a quality assessment of the
key's owner/. DKIM treats quality assessment as an independent,
value-added service, beyond the initial work of deploying a
validating signature service.
o There is a policy mechanism, either explicit or implicit, that NOTE: It would be useful to include a citation to a general
tells receivers when to expect a signature. discussion about PKI issues, including their long history of
difficulties with respect to the Internet.
o Keys are self-created (it is not necessary to buy a certificate). Further, DKIM's PKI is supported as additional information records to
the existing Domain Name Service, rather than requiring deployment of
a new query infrastructure. This approach also has significant
performance advantages as DNS is layers on UDP and key retrieval is
typically achieved in a single round trip.
o Keys are stored in the DNS (it is not necessary to deploy a 2. The DKIM Value Proposition
separate key server).
The remarkable similarity of these architectural proposals strongly Spam can be understood as two separate problems. The first is the
suggests that this architecture should be the basis for ubiquitous problem of the companies that are inappropriately aggressive, in
authentication. DKIM was produced by merging the two previous sending out unsolicited marketing email. This accounts for, perhaps,
proposals of DomainKeys and Identified Internet Mail. Significant 5% of the spam volume and is in any case usually handled by existing
enhancements were then made from that base. spam filters. The second problem is rogue spam -- often involving
criminal activities -- mostly sent from coerced botnets of
compromised machines. For this latter set of mail, the origins of a
message are often falsely stated.
The approach taken by DKIM differs from previous approaches to Even without the addition of independent accreditation services, DKIM
message signing in that: allows pair-wise sets of (possibly large) email providers and spam
filtering companies to distinguish mail that is associated with a
known organization, from mail that might deceptively purport to have
the affiliation. This in turn allows the development of 'whitelist'
schemes whereby authenticated mail from a known source with good
reputation is allowed to bypass spam filters.
o the message signature is written as a message header field so that In effect the email receiver is using their set of known
neither human recipients nor existing MUA (Mail User Agent) relationships to generate their own accreditation/reputation data.
software are confused by signature-related content appearing in This works particularly well for traffic between large sending
the message body, providers and large receiving providers. However it also works well
for any operator, public or private, that has mail traffic dominated
by exchanges among a stable set of organizations.
o there is no dependency on public and private key pairs being NOTE: Perhaps add some citations to detailed discussions about spam
issued by well-known, trusted certificate authorities, and phishing and the role of authentication and accreditation in
fighting them?
o there is no dependency on the deployment of any new Internet DKIM used in conjunction with a real-time blacklist allows phishing
protocols or services for public key distribution or revocation, emails to be preemptively blocked. The value of a cousin domain,
that could be mistaken for the legitimate domain, is significantly
reduced if the number of emails that can be successfully sent from it
is small.
o it makes no attempt to include encryption as part of the Phishing attacks are typically made against trusted brands, that is,
mechanism. names that are closely affiliated with well-known organizations. A
DKIM-based accreditation service can enforce a basic separation
between domains used by such known organizations and domains used by
others.
1.2.2. What is the purpose of DKIM? Receivers who successfully validate a signature can use information
about the signer as part of a program to limit spam, spoofing,
phishing, or other undesirable behavior, although the DKIM
specification itself does not prescribe any specific actions by the
recipient.
3. DKIM's Goals
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 typically is a handler of the
either as its originator or as an intermediary. Their reputation is message, either as its originator or as an intermediary. It can also
the basis for evaluating whether to trust the message for delivery. be an independent service, providing assistance to a handler of the
message. Their reputation is 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:
o 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
skipping to change at page 6, line 17 skipping to change at page 8, line 15
o can be deployed incrementally o can be deployed incrementally
o allows delegation of signing to third parties o allows delegation of signing to third parties
o 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? 3.1. Treat verification failure as if unsigned.
DKIM defines a mechanism by which email messages can be PGP and S/MIME were both designed for strong cryptographic
protection. This included treating validation failure as message
failure, at least warning the user that the message was unsigned. In
a small number of cases the application went even further 'warning'
the user whenever a signed message was received. This approach has
proved problematic. Hence for DKIM, the guidance is that an email
signature verifier is to treat messages with signatures that fail as
if they were unsigned.
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
treated more favorably than an unsigned one. Any messages that carry
signatures that fail verification are thus much more likely to be a
genuine message that has been damaged in transit than an attempted
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
probability that a forgery would be attempted.
3.2. Domain-level assurance
PGP and S/MIME apply the end-to-end principle in terms of individual
originators and recipients, notably using full email addresses. DKIM
seeks accountability at the more coarse grain of an organization or,
perhaps, a department. A deployed construct that enables this
granularity is the domain name, to which the signing key record is
bound.
3.3. Incremental adoption
DKIM can immediately provide benefit between any two organizations
that exchange email and implement DKIM. In the usual manner of
"network effects", the benefits of DKIM increase dramatically as its
adoption increases.
Over time, DKIM adoption might become sufficiently widespread to
permit special, negative handling of messages that are not signed.
However early benefits do not require this more-stringent
enforcement.
3.4. Minimal infrastructure
DKIM can be implemented at a variety of places within an
organization's email service. This permits the organization to
choose how much or how little they want DKIM to be part of their
infrastructure, rather than part of a more localized operation.
Similarly, DKIM's reliance on the Domain Name Service greatly reduces
the amount of new administrative infrastructure that must be deployed
over the open Internet.
Even with use of the DNS, one challenge is that it is usually
operated by different administrative staff than those who operate an
organization's email service. In order to ensure that DKIM DNS
records are accurate, this imposes a requirement for careful
coordination between the two operations groups.
3.5. Transparent signature
S/MIME and PGP are both modify the message body. Hence, their
presence is visible to all email recipients and their user software
must be able to process the associated constructs. In order to
facilitate incremental adoption, DKIM is designed to be transparent
for recipients that do not support it.
3.6. Security policy
DKIM is pursuing an incremental innovation, over basic identity
authentication, through the publication of security policies
associated with one or of the identities presented in a message. For
example, a valid DKIM signature allows the signing party to assert
responsibility for a message . For a recipient to interpret an
unsigned message it is necessary to know whether it should expect a
message from that source to be signed and if so the signature
characteristics to expect. It would, therefore, be helpful for a
potential signer to be able to publish whether they sign all of their
message. Once this is published, recipients can choose to handle the
receipt of unsigned messages with added caution.
4. A Quick Overview of DKIM
DKIM has a very constrained set of capabilities, primarily targeting
email while it is in transit, from an originator to one or more
recipients. 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 presence of a message in the mail stream. A
stream. The responsible organization adds a digital signature to the responsible organization adds a digital signature to the message,
message, associating it with a domain name of that organization. associating it with a domain name of that organization. Typically,
Typically, signing will be done by an service agent within the signing will be done by a service agent within the authority of the
authority of the message originator's Administrative Management message originator's Administrative Management Domain (ADMD).
Domain (ADMD). (Signing might be performed by any of the functional (Signing might be performed by any of the functional components in
components in that environment, including a Mail User Agent (MUA), a that environment, including a Mail User Agent (MUA), a Mail
Mail Submission Agent (MSA), or an Internet Boundary MTA. DKIM also Submission Agent (MSA), or an Internet Boundary MTA. DKIM also
permits signing to be performed by authorized third-parties.) permits signing to be performed by authorized third-parties.)
1.2.4. Who validates the signature? 4.1. What is a DKIM signature?
A signature covers the message body and selected header fields. The
signer computes a hash of the selected header fields and another hash
of the body. They then use a private key to cryptographically encode
this information, along with other signing parameters. The signature
information is placed into a new header field of the RFC2822
[RFC2822] message.
4.2. The Selector construct
In order to allow a domain name to support multiple, simultaneous
keys, a particular signature is identified by the combination of the
domain name and an added field, called the "selector". Both of these
are coded into the DKIM-Signature header field. Selectors are
assigned according to the administrative needs of the signing domain,
such as for rolling over to a new key or for delegating of the right
to authenticate a portion of the namespace to a trusted third party.
Examples include: jun2005.eng._domainkey.example.com
widget.promotion._domainkey.example.com
NOTE: It is intended that assessments of DKIM identities be based
on the domain name, rather than include the selector. This
permits the selector to be used only for key administration,
rather than having an effect on reputation assessment.
4.3. Who validates the signature?
After a message has been signed, any agent in the message transit After a message has been signed, any agent in the message transit
path can choose to validate the signature. Message recipients can path can choose to validate the signature. Validation of the
verify the signature by querying the signer's domain directly to signature, by a later agent in the path, demonstrates that the
retrieve the appropriate public key, and thereby confirm that the signing identity took responsibility for the message
message was attested to by a party in possession of the private key
for the signing domain. Typically, validation will be done by an
agent in the ADMD of the message recipient. Again, this may be done
by any functional component within that environment. (Notably this
means that the signature can be used by the recipient ADMD's
filtering software, rather than requiring the recipient end-user to
make an assessment.)
1.2.5. What does DKIM *not* do? Message recipients can verify the signature by querying the signer's
domain directly to retrieve the appropriate public key, and thereby
confirm that the message was attested to by a party in possession of
the private key for the signing domain. Typically, validation will
be done by an agent in the ADMD of the message recipient. Again,
this may be done by any functional component within that environment.
(Notably this means that the signature can be used by the recipient
ADMD's filtering software, rather than requiring the recipient end-
user to make an assessment.)
4.4. What does DKIM NOT do?
DKIM does not: DKIM does not:
o offer any assertions about the behaviors of the identity doing the o offer any assertions about the behaviors of the identity doing the
signing. signing.
o prescribe any specific actions for receivers to take upon o prescribe any specific actions for receivers to take upon
successful (or unsuccessful) signature validation. successful (or unsuccessful) signature validation.
o provide protection after message delivery. o provide protection after message delivery.
o protect against re-sending (replay of) a message that already has o protect against re-sending (replay of) a message that already has
a valid signature; therefore a transit intermediary or a recipient a valid signature; therefore a transit intermediary or a recipient
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 4.5. Does DKIM eliminate anonymity for email?
The ability to send a message that does not identify its author is
considered to be a valuable quality of the current email system. It
turns out that DKIM is particularly helpful to this goal, because a
DKIM signature will typically be used to identity an email system
operator, rather than a content author. Knowing that a mail
definitely came from example.com does not threaten the anonymity of
the user, if it is still possible to obtain effectively anonymous
accounts at example.com and other web mail providers.
4.6. Outline potential DKIM applications
TBD TBD
2. DKIM Within Existing Internet Email 4.7. What is a DKIM policy?
2.1. Review of Internet Mail Service Architecture TBD
5. DKIM Within Existing Internet Email
5.1. Review of Internet Mail Service Architecture
Internet Mail has a simple split between the user world, in the form 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 of Mail User Agents (MUA), and the transmission world, in the form of
the Mail Handling Service (MHS) composed of Mail Transfer Agents the Mail Handling Service (MHS) composed of Mail Transfer Agents
(MTA). The MHS is responsible for accepting a message from one User (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- and delivering it to one or more others, creating a virtual MUA-to-
MUA exchange environment. The first MTA is called the Mail MUA exchange environment. The first MTA is called the Mail
Submission Agent (MSA) and the final MTA is called the Mail Delivery Submission Agent (MSA) and the final MTA is called the Mail Delivery
Agent (MDA) Agent (MDA)
+--------+ +--------+
+---------------->| User | +---------------->| User |
| +--------+ | +--------+
| ^ | ^
+--------+ | +--------+ . +--------+ | +--------+ .
| User +--+--------->| User | . | User +--+--------->| User | .
+--------+ | +--------+ . +--------+ | +--------+ .
. | ^ . . | ^ .
. | +--------+ . . . | +--------+ . .
. +-->| User | . . . +-->| User | . .
skipping to change at page 8, line 19 skipping to change at page 12, line 33
| User +--+--------->| User | . | User +--+--------->| User | .
+--------+ | +--------+ . +--------+ | +--------+ .
. | ^ . . | ^ .
. | +--------+ . . . | +--------+ . .
. +-->| User | . . . +-->| User | . .
. +--------+ . . . +--------+ . .
. ^ . . . ^ . .
. . . . . . . .
V . . . V . . .
+---+----------------+------+------+---+ +---+----------------+------+------+---+
| | | | | | | . . . . |
| +--------------->+ | | | | +...............>+ . . |
| | | | | | . . . |
| +---------------------->+ | | | +......................>+ . |
| | | | | . . |
| +----------------------------->+ | | +.............................>+ |
| | | |
| Mail Handling Service (MHS) | | Mail Handling Service (MHS) |
+--------------------------------------+ +--------------------------------------+
Figure 1: Basic Internet Mail Service Model Figure 1: Basic Internet Mail Service Model
Modern Internet Mail service is marked by many independent operators, Modern Internet Mail service is marked by many independent operators,
many different components for providing users with service and many many different components for providing users with service and many
other components for performing message transfer. Consequently, it other components for performing message transfer. Consequently, it
is necessary to distinguish administrative boundaries that surround is necessary to distinguish administrative boundaries that surround
sets of functional components. sets of functional components.
2.1.1. Administrative Actors 5.1.1. Administrative Actors
Operation of Internet Mail services is apportioned to different Operation of Internet Mail services is apportioned to different
providers (or operators). Each can be composed of an independent providers (or operators). Each can be composed of an independent
ADministrative Management Domain (ADMD). Examples include an end- ADministrative Management Domain (ADMD). An ADMD operates with an
independent set of policies and interacts with other ADMDs according
to differing types and amounts of trust.. Examples include an end-
user operating their desktop client, a department operating a local user operating their desktop client, a department operating a local
Relay, an IT department operating an enterprise Relay and an ISP Relay, an IT department operating an enterprise Relay and an ISP
operating a public shared email service. These can be configured operating a public shared email service. These can be configured
into many combinations of administrative and operational into many combinations of administrative and operational
relationships, with each ADMD potentially having a complex relationships, with each ADMD potentially having a complex
arrangement of functional components. Figure 2 depicts the arrangement of functional components. Figure 2 depicts the
relationships among ADMDs. Perhaps the most salient aspect of an relationships among ADMDs. Perhaps the most salient aspect of an
ADMD is the differential trust that determines its policies for ADMD is the differential trust that determines its policies for
activities within the ADMD, versus those involving interactions with activities within the ADMD, versus those involving interactions with
other ADMDs. other ADMDs.
Basic components of ADMD distinction include: Basic components of ADMD distinction include:
Edge: Independent transfer services, in networks at the edge of the Edge -- Independent transfer services, in networks at the edge
Internet Mail service. of the Internet Mail service.
User: End-user services. This might be subsumed under the Edge User -- End-user services. These might be subsumed under an
service, such as is common for web-based email access. Edge service, such as is common for web-based email access.
Transit: These are Mail Service Providers (MSP) offering value-added Transit -- These are Mail Service Providers (MSP) offering
capabilities for Edge ADMDs, such as aggregation and filtering. value-added capabilities for Edge ADMDs, such as aggregation
and filtering.
Note that Transit services are quite different from packet-level Note that Transit services are quite different from packet-level
transit operation. Whereas end-to-end packet transfers usually go transit operation. Whereas end-to-end packet transfers usually go
through intermediate routers, email exchange across the open Internet through intermediate routers, email exchange across the open Internet
is often directly between the Edge ADMDs, at the email level. is often directly between the Edge ADMDs, at the email level.
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| ADMD1 | | ADMD3 | | ADMD4 | | ADMD1 | | ADMD3 | | ADMD4 |
| ----- | | ----- | | ----- | | ----- | | ----- | | ----- |
| | +---------------------->| | | | | | +---------------------->| | | |
skipping to change at page 9, line 47 skipping to change at page 14, line 36
Figure 2: ADministrative Management Domains (ADMD) Example Figure 2: ADministrative Management Domains (ADMD) Example
The distinction between Transit network and Edge network transfer The distinction between Transit network and Edge network transfer
services is primarily significant because it highlights the need for services is primarily significant because it highlights the need for
concern over interaction and protection between independent concern over interaction and protection between independent
administrations. The interactions between functional components administrations. The interactions between functional components
within an ADMD are subject to the policies of that domain. within an ADMD are subject to the policies of that domain.
Common ADMD examples are: Common ADMD examples are:
Enterprise Service Providers: Enterprise Service Providers -- Operating an organization's
internal data and/or mail services.
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: 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.
Operating email services, such as for end-users, or mailing lists. Mail Service Providers -- Operating email services, such as for
end-users, or mailing lists.
2.1.2. Field Referencing Convention 5.1.2. Field Referencing Convention
In this document, references to structured fields of a message use a In this document, references to structured fields of a message use a
two-part dotted notation. The first part cites the document that two-part dotted notation. The first part cites the document that
contains the specification for the field and the second is the name 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 of the field. Hence <RFC2822.From> is the From field in an email
content header and <RFC2821.MailFrom> is the address in the SMTP content header and <RFC2821.MailFrom> [RFC2821] is the address in the
"Mail From" command. SMTP "Mail From" command.
5.2. Where to Place DKIM Functions
DKIM associates a "responsible" identity with a message and provides DKIM associates a "responsible" identity with a message and provides
a means of verifying that the association is legitimate. Deciding a means of verifying that the association is legitimate. Deciding
which ADMD shall perform signing or verifying, which identity to which ADMD shall perform signing or verifying, which identity to
assign and which functional components to use for DKIM processing assign and which functional components to use for DKIM processing
depend upon the nature of the trust/reputation that is of interest depend upon the nature of the trust/reputation that is of interest
and the most convenient or efficient way to use it. 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 Messages may be signed or verified by any functional component within
an ADMD, as that domain wishes to arrange, such as: an ADMD, as that domain wishes to arrange. Examples include:
Outbound: MUA, MSA or boundary MTA. Outbound -- MUA, MSA or boundary MTA.
Inbound: Boundary MTA, MDA or MUA. Inbound -- Boundary MTA, MDA or MUA.
By having an MUA do the signing or verifying, there is no dependence By having an MUA do the signing or verifying, there is no dependence
upon implementation by an email service infrastructure. By having an upon implementation by an email service infrastructure. By having an
MHS component do signing or verifying, there is no dependence upon MHS component do signing or verifying, there is no dependence upon
user training or the upgrade of potentially large numbers of user user training or the upgrade of potentially large numbers of user
applications. applications.
Perhaps the most obvious choices within the MHS are the MSA or MDA, For implementation by an ADMD's email service operators, perhaps the
and the outbound or inbound (boundary) MTA. By signing or verifying most obvious choices within the MHS are the MSA or MDA, and the
at the outermost portion of the MHS, true end-to-end service is outbound or inbound (boundary) MTA. By signing or verifying at the
provided, requiring the smallest amount of trust on the rest of the MSA and MDA, respectively, this outermost portion of the MHS provides
infrastructure. By signing or verifying at a boundary, the smallest true end-to-end service, and requires the smallest amount of trust of
number of systems need modifying and the signature is subject to the the intervening service infrastructure. By signing or verifying at a
smallest amount of handling that can break the signature. boundary, the smallest number of systems need modifying within an
ADMD and the signature is subject to the smallest amount of handling
that can break the signature. Note, however, that this will
eliminate DKIM signing for mail that stays within the ADMD.
The choice of identity to use might not be obvious. Examples The choice of identity to use might not be obvious. Examples
include: include:
Author The domain associated with the RFC2822.From field provides Author -- The domain associated with the RFC2822.From field
basic authorization for the author to generate mail. Because the provides basic authorization for the author to generate mail.
organization controlling that domain is closest to the author, Because the organization controlling that domain is closest to
they well might be in the best position to offer their reputation the author, they well might be in the best position to offer
as a basis for asserting that the content is "safe". their reputation as a basis for asserting that the content is
"safe".
Operator Email reputation services have long-used the IP Address of a Operator -- Email recipient services have long-used the IP
client SMTP server as the basis for assessing whether to permit Address of a client SMTP server as the basis for assessing
relay or delivery of a message. These Addresses identify the whether to permit relay or delivery of a message. These
operator of an email service, rather than necessarily indicating Addresses identify the operator of an email service, rather
the author of messages being sent by that service. Use of an than necessarily indicating the author of messages being sent
operator's domain name is a natural extension of this model. 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 Third-party -- An independent service might wish to certify an
message or an operator, by providing its own signature to a author, a message or an operator, by providing its own
message. Hence, evaluation of the message will be based upon the signature to a message. Hence, evaluation of the message will
identity of that third-party, rather than any of the identities be based upon the identity of that third-party, rather than any
involved in creation or transfer of the message. Indeed, this of the identities involved in creating or transferring the
model is already emerging among a number of reputation-vetting message. Indeed, this model is already emerging among a number
services and is similar to the way a credit card permits a of reputation-vetting services and is similar to the way a
customer to make purchases, based upon the reputation of the credit card permits a customer to make purchases, based upon
credit card company -- and its willingness to issue the card. 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 Ultimately, deciding where to sign a message will depend upon both
the identity being used and the tradeoff between flexibility of uses, the identity being used and tradeoffs among flexibility of uses,
versus administrative and operational control. The choice of administrative control, and operational control. Deciding where to
component for verification will depend upon the intended use and verify a message will depend upon the intended use and similar
similar concerns about flexibility and control. A typical choice for concerns about flexibility and control. A typical choice for
reputation-related verification will be to place the signature reputation-related verification will be to place the signature
verification function "close" to the message-filtering engine. verification function "close" to the message-filtering engine.
2.3. Impact on Email Activities 5.3. Impact on Email Activities
2.3.1. Resources 5.3.1. Resources
Although the cryptographic authentication are considered to be Although cryptographic authentication is 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%. Mail handling tends to be, i/o-intensive, so that
computational capacity. So, it is likely that no new hardware will dedicated email platforms tend to have unused computational capacity.
be required. It is therefore likely that no new hardware will be required for
these systems to be able to add DKIM support.
2.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
2.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.
2.4. Migrating from DomainKeys
2.4.1. Signing
2.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.
2.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.
2.4.1.3. Boundary MTA
Enforce signature policies and practises
2.4.2. Verifying
2.4.2.1. DNS Client
2.4.2.2. Verifying module
See "Signing Module".
2.4.2.3. Boundary MTA
Strip "local" signatures that are not local?
2.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".
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 5.3.2. Operations
a combination of the identity being used, and tradeoffs between
flexibility, control, and administrative ease.
3.3. Impact on Email Activities The costs to deploy, administer and operate DKIM vary greatly,
depending upon the placement of DKIM-related modules. The greatest
flexibility comes from placing the modules as close as possible to
the end user. However this also imposes the greatest costs. The
most common scenarios are likely to be:
3.3.1. Resources Boundary MTA -- Here, DKIM is used only for email external to the
ADMD. Administration and operation is the simplest, but could
cause problems for mobile users who are associated with the
organization but must send mail using facilities that are
independent of their home ADMD. It also provides no assistance
for inter-departmental accountability within the ADMD..
Although the cryptographic authentication are considered to be MSA/MDA (Department) -- Placing DKIM support at the points of
computationally expensive, the real impact of a mechanism, like DKIM, submission and delivery increases the deployment costs but still
is remarkably small. Direct impact on CPU-load has been measured to keeps control within the ADMD's operational staff. It avoids the
be 10-15%. Usually, email is i/o-intensive, with unused considerable, added costs of having to enhance all of the MUAs.
computational capacity. So, it is likely that no new hardware will This does not improve the lot of mobile users who submit from
be required. independent MSAs but does provide full protection within the ADMD.
3.3.2. Operations MUA -- Obviously this can provide the most complete protection, but
at the cost of considerable added administrative effort. Worse,
there is extensive evidence that email infrastructure services
often perform changes to message content that can break a message
signature. Examples include transformation by the MSA to ensure
that the message is in full conformance with Internet standards
and transformation by Boundary MTAs, to ensure conformance with
organizational policies about external communications.
Administrative cost to deploy, versus expected reduction in the cost In spite of these concerns, placing DKIM support into the MUA is
of administration for problem email. the only way to ensure that a highly mobile user retains its
benefits, in spite of having to send mail through independent
MSAs.
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
3.3.3. Users 5.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.
3.4. Migrating from DomainKeys 5.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 5.4.1. Signing
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 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.
Enforce signature policies and practises Boundary MTA: Enforce signature policies and practices
3.4.2. Verifying >
3.4.2.1. DNS Client 5.4.2. Verifying
3.4.2.2. Verifying module DNS Client: TBD
See "Signing Module". Verifying module: See "Signing Module".
3.4.2.3. Boundary MTA 5.4.3. Boundary MTA
Strip "local" signatures that are not local? Strip "local" signatures that are not local?
3.5. { Misc Text -- Should go elsewhere, if used at all } 6. DKIM Service Architecture
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 DKIM provides an end-to-end service for signing and verifying
messages that are in transit. It is divided into components that can messages that are in transit. It is divided into components that can
be performed using different, external services, such as for key be performed using different, external services, such as for key
retrieval, although the basic DKIM operation provides an initial set. retrieval, although the basic DKIM operation provides an initial set.
| |
| - RFC2822 Message | - RFC2822 Message
V V
+---------------------------------------------+ +---------------------------------------------+
+-----------+ | ORIGINATING OR RELAYING ADMD | +-----------+ | ORIGINATING OR RELAYING ADMD |
| | | ============================ | | | | ============================ |
| Signer | | | | Signer | | |
| Practises +......>| SIGN MESSAGE | | Practices +......>| SIGN MESSAGE |
| | | ...> ADD A SIGNATURE HEADER FIELD | | | | ...> ADD A SIGNATURE HEADER FIELD |
+-----+-----+ .....>| . GET (Domain, Selector, Priv-Key) | +-----+-----+ .....>| . GET (Domain, Selector, Priv-Key) |
. . | ... COMPUTE SIGNATURE | . . | ... COMPUTE SIGNATURE |
. V +----------------+----------------------------+ . V +----------------+----------------------------+
. +-------+ | - Message . +-------+ | - Message
. | | | 1*(Domain, Selector, . | | | 1*(Domain, Selector,
. | Key | | Sig) . | Key | | Sig)
. | Store | [Internet] . | Store | [Internet]
. | | | . | | |
. +---+---+ V . +---+---+ V
. . +---------------------------------------------+ . . +---------------------------------------------+
. . | RELAYING OR DELIVERING ADMD | . . | RELAYING OR DELIVERING ADMD |
. . | =========================== | . . | =========================== |
. . | | . . | |
. . | VERIFY MESSAGE (Verifier Practises) | . . | VERIFY MESSAGE (Verifier Practices) |
. . | ...> VERIFY A SIGNATURE HEADER FIELD | . . | ...> VERIFY A SIGNATURE HEADER FIELD |
. . | . GET A SIGNATURE | . . | . GET A SIGNATURE |
. .....>| . LOOKUP PUB-KEY (Domain, Selector) | . .....>| . LOOKUP PUB-KEY (Domain, Selector) |
. | . VERIFY SIGNATURE VALUE | . | . VERIFY SIGNATURE VALUE |
. | ... EVALUATE SIGNATURE CONSTRAINTS | . | ... EVALUATE SIGNATURE CONSTRAINTS |
. +-------------------+-------------------------+ . +-------------------+-------------------------+
. | - Verified Domain(s) . | - Verified Domain(s)
. V - [Report] . V - [Report]
. +---------------------------------------------+ . +---------------------------------------------+
. | | . | |
. | MESSAGE DISPOSITION | . | MESSAGE DISPOSITION |
.............>| SIGNER PRACTICES | .............>| SIGNER PRACTICES |
.............>| REPUTATION | .............>| REPUTATION |
. | | . | |
+-----+------+ +---------------------------------------------+ +-----+------+ +---------------------------------------------+
| | | |
| Reputation | | Reputation |
| | | |
+------------+> +------------+>
Figure 5: DKIM Service Architecture Figure 3: DKIM Service Architecture
Basic message process divides between signing the message, validating Basic message processing divides between signing the message,
the signature, and the performing further decision-making based upon validating the signature, and then performing further decision-making
the validated signature. The component doing the signing applies based upon the validated signature. The component doing the signing
whatever signing policies are in force, including ones that determine applies whatever signing policies are in force, including ones that
what private key to use. Validation may be performed by any determine what private key to use. Validation may be performed by
functional component along the relay and delivery path. The public any functional component along the relay and delivery path. The
key is retrieved, based upon the parameters strored in the message. public key is retrieved, based upon the parameters stored in the
The example shows use of the validated identity for assessing an message. The example shows use of the validated identity for
associated reputation. However it could be applied for other tasks, assessing an associated reputation. However it could be applied for
such as management tracking of mail. other tasks, such as management tracking of mail.
5. Relationship to previous Message Signature Technologies 7. Implementation Considerations
DKIM is the fifth IETF proposal for an email signature scheme. The 7.1. Development
first RFC describing Privacy Enhanced Mail (PEM) was published in
1987 [RFC0989]. The PEM scheme went through a number of revisions
and eventually transformed into MIME Object Security Services in 1995
[RFC1848].
Neither PEM nor MOSS ever achieved significant deployment. PEM 7.1.1. Coding Criteria for Cryptographic Applications
relied on the prior deployment of an extensive PKI predicated on a
rigid hierarchy of Certificate Authorities. By the time it was
understood that this infrastructure assumption was unrealistic the
opportunity to deploy PEM had closed.
Pretty Good Privacy (PGP) was developed by Phil Zimmerman and Correct implementation of a cryptographic algorithm is a necessary
released in 1991 and quickly established a significant support base but not a sufficient condition for coding of cryptographic
within the security community. This support base was driven by two applications. Coding of cryptographic libraries requires close
principal factors: superior ease of deployment and an aggressive attention to security considerations that are unique to cryptographic
marketing campaign assisted by the U.S. government. A working group applications.
was formed within the IETF to continue development of the PGP
protocol as OpenPGP beginning with publication of the original
protocol as an informational RFC in 1996 [RFC1991].
At the same time RSA Security, the holder of the patent rights to the In addition to the usual security coding considerations, such as
principle public key cryptography algorithm independently developed avoiding buffer or integer overflow and underflow, implementers
Secure MIME (S/MIME) which employed the recently developed MIME should pay close attention to management of cryptographic private
format to transport a PKCS #7 data object. S/MIME was particularly keys and session keys, ensuring that these are correctly initialized
attractive for software developers who had already implemented SSL as and disposed of.
much of the code required to support could be reused.
Development of S/MIME and OpenPGP has continued in the IETF since. Operating system mechanisms that permit the confidentiality of
While both have achieved a significant user base neither has achieved private keys to be protected against other processes SHOULD be used
ubiquity. In particular it is notable that only a small percentage when available. In particular, great care MUST be taken when
of messages on the IETF mailing lists concerned with security are releasing memory pages to the operating system to ensure that private
signed. key information is not disclosed to other processes.
5.1. Transparent Signature On multiple processor and dual core architectures, certain
implementations of public key algorithms such as RSA may be
vulnerable to a timing analysis attack.
The core goals of DKIM require that use of message signatures becomes Support for cryptographic hardware providing key management
ubiquitous. For this to be possible it must be possible to apply a capabilities is strongly encouraged. In addition to offering
signature to any message in any circumstance with a negligible chance performance benefits, many cryptographic hardware devices provide
of causing a negative user experience for any recipient regardless of robust and verifiable management of private keys.
the legacy email client used.
Experiences from S/MIME and PGP deployment strongly indicate that Fortunately appropriately designed and coded cryptographic libraries
this usability goal can only be met if the addition of the signature are available for most operating system platforms under license terms
leaves the message body unchanged. compatible with commercial, open source and free software license
terms. Use of standard cryptographic libraries is strongly
encouraged. These have been extensively tested, reduce development
time and support a wide range of cryptographic hardware.
S/MIME and PGP are both designed to achieve the highest level of 7.1.1.1. Signer
security possible. The sender of a message is assured that the
confidentiality and/or integrity of the message are protected from
the originating end point machine to the destination end point.
Achieving this level of security naturally places requirements on Signer implementations SHOULD provide a convenient means of
both the sender and the receiver. Support for both signature and generating DNS key records corresponding to the signer configuration.
encryption causes a subtle but important architectural assumption to Support for automatic insertion of key records into the DNS is also
be introduced. Although signature and encryption are complimentary highly desirable. If supported however such mechanism(s) MUST be
from a cryptographic point of view their effect is entirely different properly authenticated.
from a messaging protocol point of view. A digital signature is
meta-data providing information about the message contents.
Encryption is a transformation of the message content (and possibly
related meta-data).
The recipient of an encrypted email message must as a matter of Means of verifying that the signer configuration is compatible with
course have a specially adapted email client capable of decrypting the signature policy is also highly desirable.
the message. Adding a signature to the message does not in principle
create a requirement for the recipient to have a specially adapted
client provided the signature is added in a manner that is ignored by
legacy clients.
In the case of an S/MIME signature the recipient is at a minimum Disclosure of a private signature key component to a third party
expected to have a client capable of decoding the MIME multipart/ allows that third party to impersonate the sender. Protection of
security format. In practice this means that the recipient must private signature key data is therefore a critical concern. Signers
support S/MIME. OpenPGP allows the use of a signature encapsulation SHOULD support use of cryptographic hardware providing key management
that is not MIME based. This has the advantage that the message can features.
be read using a standard email client. The disadvantage with this
approach is that the application of the signature is visible to the
user and thus intrusive.
5.2. Treat verification failure as if unsigned. The import and export of private keys, and the ability to generate a
CSR for certificate registration are highly desirable.
PGP and S/MIME were both designed to meet a high standard of 7.1.1.2. Verifier
cryptographic excellence. At the time the protocols were designed it
was generally considered that the correct thing for an application to
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
application went even further 'warning' the user whenever a signed
message was received.
This type of user experience has since been severely deprecated. A Verifiers SHOULD treat the result of the verification step as an
user who is constantly bombarded with warning messages is much less input to the message evaluation process rather than as providing a
likely to respond appropriately when an important warning message is final decision. The knowledge that a message is authentically sent
received. by a domain does not say much about the legitimacy of the message
unless the characteristics of the domain claiming responsibility are
known.
While modern messaging infrastructure is considerably friendlier to In particular, verifiers SHOULD NOT automatically assume that a email
the use of digital signatures than in the past even a residual message that does not contain a signature or which contains a
failure rate of 1% results in unacceptably high support costs when signature that does not validate is forged. Verifiers should treat a
signatures are used ubiquitously. signature that fails to validate as if no signature was present.
It is now generally accepted that the correct semantics for an email 7.1.2. Email Handlers
signature verifier to adopt are to treat messages with signatures
that fail as if they are unsigned.
It is highly unlikely that an attacker is going to add a digital 7.1.2.1. Mail User Agent
signature to a message unless doing so causes the message to be
treated more favorably than an unsigned one. Any messages that carry
signatures that fail verification are thus much more likely to be a
genuine message that has been damaged in transit than an attempted
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
probability that a forgery would be attempted.
5.3. Legacy Client Semantics DKIM is designed to support deployment and use in email components
other than an MUA. However an MUA may also however implement DKIM
features directly.
The deployed base of S/MIME is both a benefit and a burden. While Outbound: If an MUA is configured to send email directly, rather
the S/MIME protocol is in principle capable of extension to support than relayed through an outbound MTA, the MUA SHOULD be considered
many of the features of DKIM, the same is not true of the deployed as if it were an outbound MTA for the purposes of DKIM. An MUA
S/MIME base. MAY support signing even if mail is to be relayed through an
outbound MTA. In this case the signature applied by the MUA may
be in addition to or in place of the MTA signature.
While the S/MIME protocol can in principle support semantics such as Inbound: An MUA MAY rely on a report of a DKIM signature
domain level signatures or make use of keys stored in the DNS the verification that took place at some point in the inbound MTA
legacy deployed base does not. The behavior of legacy clients path. An MUA MAY perform DKIM signature verification directly.
receiving an S/MIME message dependent on the novel semantics is Such an MUA SHOULD allow for the case where mail is modified in
likely to result in a negative user experience in a significant the inbound MTA path.
number of cases.
5.4. Key Centric PKI 7.1.3. Mail Transfer Agent
Unlike all four previous IETF email security initiatives, DKIM It is expected that the most common venue for a DKIM implementation
employs a key centric, directory based PKI as opposed to a with be a department or a boundary MTA.
certificate based PKI in the style of Kohnfelder (X.509) or Zimmerman
(web of trust).
While message syntax and PKI are orthogonal in principle, Outbound: An Outbound MTA should allow for automatic verification
implementation practice means that most S/MIME clients only support of the MTA configuration such that the MTA can generate an
use of keys contained in X.509/PKIX digital certificates. operator alert if it determines that it is (1) an edge MTA, (2)
configured to send email messages that do not comply with the
published DKIM sending policy.
Although PGP is sometimes held up as an alternative to a certificate An outbound MTA should be aware that users may employ MUAs that
based PKI a PGP key signing is in essence a digital certificate by add their own signatures and be prepared to take steps necessary
another name. There has since been considerable conversion as X.509 to ensure that the message sent is in compliance with the
has adopted the web of trust principle under the term cross- advertised email sending policy.
certification. The chief distinction between the PGP and PKIX models
is that in the PGP model every user is also (potentially) a trust
provider. In PKIX trust providers are distinct from end-entities.
The Kohnfelder architecture was originally designed to allow use of Inbound: An inbound that does not support DKIM, it should avoid
public key cryptography before the ubiquitous availability of modifying messages in ways that prevent verification by other
networking. A particular benefit of the Kohnfelder architecture is MTAs, or MUAs to which the message may be forwarded.
that Alice can send an encrypted message to Bob when the only
transport available is sending floppy disks through the postal
system. Another benefit of the Kohnfelder architecture is that a
signed message supported by a digital certificate is self supporting
and may be verified years after the fact provided only that the CA
signing key does not become compromised.
The principle weakness in PKIs based on the Kohnfelder architecture Intermediaries: An email intermediary is both an inbound and
is the difficulty of locating the correct digital key in the absence outbound MTA. Each of the requirements outlined in the sections
of a directory infrastructure. This led Brian LaMacchia, then at MIT relating to MTAs apply. If the intermediary modifies a message in
to develop the MIT PGP key server, in effect returning to the a way that breaks the signature the intermediary it SHOULD
original public key directory model proposed by Whitt Diffe and Marty
Hellman.
XML Key Management Service (XKMS) realizes the key centric PKI model * deploy abuse filtering measures on the inbound mail
as a SOAP based Web Service. In the XKMS model the PKI client makes
a request of the form 'provide me with the signing key that Alice
uses with the PGP protocol'.
Although DKIM follows the same architectural model as XKMS, DNS is * remove all signatures that will be broken
used as the transport layer in place of SOAP over HTTP.
The use of DNS significantly reduces the infrastructure requirements In addition the intermediary MAY:
for DKIM as existing DNS servers are used for key distribution. This
approach also has significant performance advantages as DNS is layers
on UDP and key retrieval is typically achieved in a single round
trip. XKMS requires a TCP session to be established and the request
and response messages are significantly larger.
The principle disadvantage of using DNS over XKMS is that the DNS is * Verify the message signature prior to modification
a network administration resource designed to answer questions about
current network configuration. While it is quite possible to re-use
the DNS infrastructure to support queries about past and even future
network configurations this is not the core objective of the
infrastructure. The DNS is thus unsuited to supporting any use of
digital signatures in which long term archival is desirable or the
possibility of repudiation is undesirable.
5.5. Domain Level Assurance * Incorporate an Authentication-Results header to report the
verification result.
As previously mentioned PGP and S/MIME were designed in the heyday of * Sign the modified message including the Authentication-Results
the security end-to-end principle. It has since been realized that header
the end points with respect to trust are not the same as the end
points with respect to the communication protocol.
When Alice sends a personal message to Bob it is Alice the person, 7.2. Filtering
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
is her employer.
The objective of DKIM is to allow parties to accept responsibility Developers of filtering schemes designed to accept DKIM
for messages by signing them. While accepting responsibility at the authentication results as input should be aware that their
personal level may be desirable in some circumstances the Internet implementations will be subject to counter-attack by email abusers.
now has a billion users. Attempting to achieve accountability in a The efficacy of a filtering scheme cannot therefore be determined by
population of a billion users is impractical, particularly when the reference to static test vectors alone; resistance to counter attack
owner of the domain example.com has the ability to create a must also be considered.
practically unlimited number of accounts within that domain at will.
The logical unit of accountability for DKIM is therefore the DNS Naive learning algorithms that only consider the presence or absence
domain name to which the signing key record is bound and not the of a valid DKIM signature are vulnerable to an attack in which a
individual email user. spammer or other malefactor signs all their mail, thus creating a
large negative value for presence of a DKIM signature in the hope of
discouraging widespread use.
5.6. Security Policy If heuristic algorithms are employed they should be trained on
feature sets that sufficiently reveal the internal structure of the
DKIM responses. In particular the algorithm should consider the
domains purporting to claim responsibility for the signature rather
than the existence of a signature or not.
The innovation in DKIM that has no precedent in the previous email Unless a scheme can correlate the DKIM signature with accreditation
security standards is the publication of a security policy. The or reputation data, the presence of a DKIM signature SHOULD be
purpose of DKIM is to allow a party to accept responsibility for an ignored.
email message by signing it. A message with a signature is treated
as if it is unsigned. For a recipient to interpret an unsigned
message it is necessary to know whether it should expect a message
from that source to be signed and if so the signature characteristics
to expect.
The introduction of security policy allows unsigned messages and 7.3. DNS Server
messages that fail signature validation to be subjected to a higher
level of anti-spam filtering or rejected out of hand in circumstances
where the owner of the purported originating domain suggests. For
example a bank concerned at the possibility of phishing attack might
publish a policy stating that all legitimate messages from the domain
are signed.
While the Sender-ID/SPF security policy format allows application to TBD
existing formats including PGP and S/MIME the advantages to
developing the protocol and security policy in tandem are
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
of the 512 byte response message size imposed on the legacy DNS.
6. Implementation Considerations 7.4. Accreditation service
6.1. Development TBD
What software has to change, to use DKIM? 8. Deployment
6.1.1. Signer This section describes the basic steps for introducing DKIM into an
organization's email service operation. The considerations are
divided between an organization's generating DKIM signatures
(Signing) and an organization's processing of messages that contain a
DKIM signature (Verifying).
The signer needs to add code in the appropriate agent, to perform 8.1. Signing
signing, and they need to modify their DNS administrative tools to
permit creation of DKIM key records.
6.1.2. Validator Creating messages that have DKIM signatures requires modification of
only two portions of the email service:
A validator needs to add code to the appropriate agent and then feed o Addition of relevant DNS information.
the result into the portion of their system needing it, such as a
filtering engine.
The mere existence of a valid signature does not imply that the mail o Addition of the signature by a trusted module within the
is acceptable, such as for delivery. Acceptability requires an organization's email handling service.
assessment phase. Hence the result of signature validation must be
fed into a vetting mechanism that is part of the validator's filter.
6.1.3. Outbound mail user agent The signing module uses the appropriate private key, for creating a
signature. The means by which the signing module obtains this key is
not specified by DKIM. Given that DKIM is intended for use during
email transit, rather than for long-term storage, it is expected that
keys will be changed regularly. Clearly this means that key
information should not be hard-coded into software.
TBD 8.1.1. DNS Records
6.1.4. Outbound mail transport agent A receiver attempting to validate a DKIM signature must obtain the
public key that is associated with the signature for that message.
The DKIM-Signature header in the message will specify the basic
domain name doing the signing and the selector to be used for the
specific public key. Hence, the relevant
<selector>._domainkeys.<domain-name> DNS record needs to contain a
DKIM-related RR that provides the public key information.
TBD The administrator of the zone containing the relevant domain name
adds this information. DNS administrative software varies
considerably in its abilities to add new (types of) DNS records.
Initial DKIM DNS information is contained within TXT RRs.
6.1.5. DNS Server 8.1.2. Signing Module
TBD The module doing signing can be placed anywhere within an
organization's trusted Administrative Management Domain (ADMD).
Common choices are expected to be department-level posting and
delivering agents, as well as boundary MTAs to the open Internet.
However, note that it is entirely acceptable to have signing and
validation be done by MUAs. Hence the choice among the modules
depends upon software development and administrative overhead
tradeoffs. One perspective that helps resolve this choice is the
difference between the flexibility of use by systems at, or close to,
the MUA, versus the centralized control that is more easily obtained
by implementing the mechanism "deeper" into the organization's email
infrastructure, such as at its boundary MTA.
6.1.6. Mailing list manager 8.1.3. Signing Policies and Practices
TBD Every organization (ADMD) will have its own policies and practices
for deciding when to sign messages and with what domain name and key
(selector). Examples include signing all mail, signing mail from
particular email addresses, or signing mail from particular sub-
domains. Given this variability, and the likelihood that signing
practices will change over time, it will useful to have these
decisions represented in some sort of configuration information,
rather than being more deeply coded into the signing software.
6.1.7. Inbound mail transport agent 8.2. Verifying
TBD Verification is performed within an ADMD that wishes to make
assessments based upon the domain name used for a DKIM signature.
Any component within the ADMD that handles messages, whether in
transit or being delivered, can be appropriate to do the verifying.
It must communicate the results of verification to another component
within the ADMD that performs the desired assessments. Verification
and assessment might occur within the same software mechanism, such
as a Boundary MTA, or an MDA. Or they may be separated, such as
having verification performed by the Boundary MTA and assessment
performed by the MDA.
6.1.8. Inbound mail user agent As with the signing process, choice of service venues for
verification and assessment -- such as filtering or presentation to
the recipient user -- depend on trade-offs for flexibility, control,
and operational ease. An added concern is that the linkage between
verification and assessment entails essential trust: The assessment
module must have a strong basis for believing that the verification
information is correct.
TBD 8.2.1. DNS Client
6.1.9. Accreditation service The primary means of publishing DKIM key information, initially, is
through DNS TXT records. Some DNS client software might have
problems obtaining these records. As DNS client software improves
this will not be an concern.
TBD 8.2.2. Boundary Enforcement
6.2. Deployment In order for an assessment module to trust the information it
receives about verification, it is essential to eliminate
verification information originating from outside the ADMD in which
the assessment mechanism operates. As a matter of friendly practice,
it is equally important to make sure that verification information,
from within the ADMD, not escape out side of it.
6.2.1. Signing In most environments, the easiest way to enforce this stripping of
verification information is to place modules in the receiving and
sending Boundary MTA(s). For incoming mail, check for known means of
communicating verification information and remove it. The same
applies for outgoing mail.
6.2.1.1. DNS Records 8.3. Transition strategy
add sig key info Deployment of a new signature algorithm without a 'flag day' requires
a transition strategy such that signers and verifiers can phase in
support for the new algorithm independently and if necessary phase
out support for the old algorithm independently.
6.2.1.2. Signing Module DKIM achieves these requirements through two features. First a
signed message may contain multiple signatures created by the same
signer. Secondly the security policy layer allows the signing
algorithms in use to be advertised, thus preventing a downgrade
attack.
Delete old signs with same key; add new sig 8.3.1. Signer transition strategy
6.2.1.3. Boundary MTA 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
algorithm without disruption of service to legacy verifiers is as
follows:
Enforce signature policies and practises 1. Signer signs with algorithm A
6.2.2. Verifying A. Signer advertises that it signs with algorithm A
6.2.2.1. DNS Client 2. Signer signs messages twice, first with algorithm A and algorithm
B
Ensure able to obtain DKIM key sig records A. The signer tests new signing configuration
6.2.2.2. Verifying module B. Signer advertises that it signs with algorithm A and
algorithm B
Validate sig; channel info to filtering engine. Maybe provide user- 3. Signer determines that support for Algorithm A is no longer
visible info. necessary
6.2.2.3. Boundary MTA 4. Signer determines that support for algorithm A it to be withdrawn
Strip "local" signatures that are not local? A. Signer removes advertisement for Algorithm A
6.3. Operations B. Signer waits for cached copies of earlier signature policy to
expire
6.3.1. DNS Signature Record Deployment Considerations C. Signer stops signing with Algorithm A
TBD 8.3.2. Verifier transition strategy
6.3.2. Thoughts on Expiring Signatures The actions of the verifier are independent of the signer's actions
and do not need to be performed in a particular sequence. The
verifier may make a decision to cease accepting algorithm A without
first deploying support for algorithm B. Similarly a verifier may be
upgraded to support algorithm B without requiring algorithm B to be
withdrawn. The decisions of the verifier must make are therefore:
TBD o The verifier MAY change the degree of confidence associated with
any signature at any time, including determining that a given
signature algorithm provides a limited assurance of authenticity
at a given key strength.
6.3.3. DNS Policy Record Deployment Considerations * A verifier MAY chose to evaluate signature records in any order
it chooses, including making use of the signature algorithm for
this purpose.
TBD o The verifier MAY make a determination that Algorithm A does not
offer a useful level of security, that the cost of verifying the
signature is less than the value of doing so.
6.3.4. Subdomain Considerations * In this case the verifier ignores signatures created using the
algorithm A and references to algorithm A in policy records are
treated as if the algorithm is not implemented.
o The verifier MAY decide to add support for additional signature
algorithms at any time.
* The verified MAY add support for algorithm B at any time.
9. Operations
This section describes the basic steps for the continued operation of
email systems that use DKIM. This section discusses keeping DKIM
going, as opposed to getting DKIM started. The primary
considerations are: the upkeep of the selector files, and the
security of the private keys.
9.1. DNS Signature Record Deployment Considerations
The key point to remember is that the DNS DKIM selectors WILL and
SHOULD be changed over time. Some reasons for changing DKIM
selectors are well understood; others are still theoretical. There
are several schemes that may be used to determine the policies for
changing DKIM selectors:
o time based
o associations with clusters of servers
o the use of third party signers
o security considerations
9.1.1. Time Basis and Security Considerations
The reason for changing the selector periodically is usually related
to the security exposure of a system. When the potential exposure of
the private keys associated with the DKIM selector have reached
sufficient levels, the selector should be changed. (It is unclear
currently what kinds of metrics can be used to aid in deciding when
the exposure has reached sufficient levels to warrant changing the
selector.)
For example,
o Selectors should be changed more frequently on systems that are
widely exposed, than on systems that are less widely exposed. For
example, a gateway system that has numerous externally-accessible
services running on it, is more widely exposed than one that ONLY
runs a mail server.
o Selectors should be changed more frequently on operating systems
that are under wide attack.
o While the use of DKIM information is transient, keys with
sufficient exposure do become stale and should be changed.
o Whenever you make a substantial system change, such as bringing up
a new server, or making a major operating system change, you
should consider changing the selector.
o Whenever there is either suspicion or evidence of the compromise
of the system or the private keys, you should change the selector.
9.1.2. Server Clusters
TBD TBD
6.3.5. Third party Signature Delegations 9.1.3. Deploying New Selectors
A primary consideration in changing the selector is remembering to
change it. It needs to be a standard part of the operational staff
Methods and Procedures for your systems.
When deploying a selector, it needs to be phased in:
1. generate the new public / private key pair and create a selector
record with the public key in it
2. add the new selector record to your DNS
3. turn on signing with the new private key
4. optionally back up the old private key in a secure location
5. remove the old private key from your servers
6. after a period of time, remove the old selector
The time an unused selector should be kept in the DNS system is
dependent on the reason it's being changed. If the private key has
definitely been exposed, the corresponding selector should be removed
immediately. Otherwise, longer periods are allowable.
9.1.4. Subdomain Considerations
TBD TBD
7. Outline Future Extensions 9.1.5. Third party Signature Delegations
Allowing third parties to sign email from your domain opens your
system security to include the security of the third party's systems.
At a minimum, you should not allow the third parties to use the same
selector and private key as your main mail system. It is recommended
that each third party be given their own private key and selector.
This limits the exposure for any given private key, and minimizes the
impact if any given private key were exposed.
9.1.6. Mailing List Management
[ Note: this section may be controversial. ]
A mailing list often provides facilities to its administrator to
manipulate parts of the mail messages that are flowing through. The
desired goal is that messages flowing through the mailing list will
be verifiable by the recipient, which means that either the mailing
list (or its MSA) must sign the message, or the mailing list must not
perform actions on the messages that will break existing DKIM
signatures. To avoid breaking existing signatures, a mailing list
system has these choices:
o A mailing list may add its own DKIM signature. If it does this,
it must make sure that it adds its signature after it performs any
content transformations to the message, such as adding a footer to
the body, adding a prefix to the body, modifying the subject
header, etc.
o If a mailing list does not add its own DKIM signature, it must not
modify any existing headers that are listed in an h= parameter of
any existing DKIM-Signature headers, nor may it add any footer
content to the body if there is no l= in any existing DKIM-
Signature headers.
o If a mailing list cannot add its own DKIM signature, and must
modify the headers or body in a way that will break verification
of existing DKIM-Signature headers, it should remove any existing
DKIM-Signature headers.
10. 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
the approach 'if in doubt leave it out'. taken 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
develop similar capabilities within the DKIM framework at a future develop similar capabilities within the DKIM framework at a future
date. date.
DKIM is an example of 'Design for Deployment'. The need to support DKIM is an example of 'Design for Deployment'. The need to support
rapid deployment is the overriding priority. It has traditionally rapid deployment has been the overriding priority. It has
been asserted that deployment of a flawed cryptographic protocol is traditionally been asserted that deployment of a flawed cryptographic
an almost unacceptable risk, that bad security is worse than no protocol is an almost unacceptable risk, and that bad security is
security. Experience demonstrates otherwise. Informing users that worse than no security. Experience demonstrates otherwise.
email is insecure does not cause them to modify their behavior to Informing users that email is insecure does not cause them to modify
avoid dependence thereupon. Deployment of flawed cryptographic their behavior to avoid dependence thereupon. Deployment of flawed
security systems such as SSL and WEP has been rectified far more cryptographic security systems such as SSL and WEP has been rectified
quickly than deployment of protocols such as IPSEC or DNSSEC where far more quickly than deployment of protocols such as IPSEC or DNSSEC
caution has prevailed. where caution has prevailed.
One possible future for DKIM is that it becomes the starting point One possible future for DKIM is that it becomes the starting point
for a new cryptographic infrastructure that eventually replaces for a new cryptographic infrastructure that eventually replaces
legacy systems including S/MIME and PGP. While this future is legacy systems including S/MIME and PGP. While this future is
certainly preferable to never achieving ubiquitous deployment of certainly preferable to never achieving ubiquitous deployment of
strong cryptographic security in the Internet it would certainly take strong cryptographic security in the Internet, it would certainly
a long time to re-invent this particular wheel. Moreover the take a long time to re-invent this particular wheel. Moreover the
deployment of the proposed DKIM enhancements would face political deployment of the proposed DKIM enhancements would face political
opposition from the adherents to existing formats to be rendered opposition from the adherents to existing formats to be rendered
historical. A likely outcome of such a strategy is that the existing historical. A likely outcome of such a strategy is that the existing
two way standards stalemate between S/MIME and PGP would become a two way standards stalemate between S/MIME and PGP would become a
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 the 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.
7.1. Introducing a new signing algorithm 10.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.
The choice of cryptographic algorithm affects the DKIM algorithm in The choice of cryptographic algorithm affects the DKIM algorithm in
skipping to change at page 31, line 39 skipping to change at page 32, line 44
signatures. signatures.
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 since the signature must be Base 64
encoded.
7.2. Possible future signature algorithm choices 10.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 has been found that is consistent with the position on
property adopted by the DKIM working group has been found. intellectual property adopted by the DKIM working group.
The DSA signature algorithm based on the discrete log problem faces The DSA signature algorithm based on the discrete log problem faces
the same key size limitations as RSA. Importantly for the design of the same key size limitations as RSA. Importantly for the design of
DKIM and DNSSEC however the signature size is much smaller, the same DKIM and DNSSEC however, the signature size is much smaller, the same
size as for ECC algorithms. size as for ECC algorithms.
It is likely that DSA would have received greater attention during It is likely that DSA would have received greater attention during
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 the use of stronger hash functions (including SHA-256 and SHA 512).
the advantages offered by DSA are not sufficient to warrant an While 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.
7.3. Transition strategy 10.3. Linkage to Other PKIs
Deployment of a new signature algorithm without a 'flag day' requires
a transition strategy such that signers and verifiers can phase in
support for the new algorithm independently and if necessary phase
out support for the old algorithm independently.
DKIM achieves these requirements through two features. First a
signed message may contain multiple signatures created by the same
signer. Secondly the security policy layer allows the signing
algorithms in use to be advertised, thus preventing a downgrade
attack.
7.3.1. Signer transition strategy
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
algorithm without disruption of service to legacy verifiers is as
follows:
1. Signer signs with algorithm A
A. Signer advertises that it signs with algorithm A
2. Signer signs messages twice, first with algorithm A and algorithm
B
A. The signer tests new signing configuration
B. Signer advertises that it signs with algorithm A and
algorithm B
3. Signer determines that support for Algorithm A is no longer
necessary
4. Signer determines that support for algorithm A it to be withdrawn
A. Signer removes advertisement for Algorithm A
B. Signer waits for cached copies of earlier signature policy to
expire
C. Signer stops signing with Algorithm A
7.3.2. Verifier transition strategy
The actions of the verifier are independent of the signer's actions
and do not need to be performed in a particular sequence. The
verifier may make a decision to cease accepting algorithm A without
first deploying support for algorithm B. Similarly a verifier may be
upgraded to support algorithm B without requiring algorithm B to be
withdrawn. The decisions of the verifier must make are therefore:
The verifier MAY change the degree of confidence associated with
any signature at any time, including determining that a given
signature algorithm provides a limited assurance of authenticity
at a given key strength.
A. A verifier MAY chose to evaluate signature records in any
order it chooses, including making use of the signature
algorithm for this purpose.
The verifier MAY make a determination that Algorithm A does not
offer a useful level of security, that the cost of verifying the
signature is less than the value of doing so.
A. In this case the verifier ignores signatures created using the
algorithm A and references to algorithm A in policy records
are treated as if the algorithm is not implemented.
The verifier MAY decide to add support for additional signature
algorithms at any time.
A. The verified MAY add support for algorithm B at any time.
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 necessarily 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.
7.5. Trusted Third Party Assertions 10.4. 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
are likely to need to acquire reputation data from a third party. In are likely to need to acquire reputation data from a third party. In
either case the use of reputation data is intrinsically limited to either case the use of reputation data is intrinsically limited to
email sender which have established a prior history of sending email senders that have established a prior history of sending
messages. messages.
Another commonly used technique for evaluating email senders is Another commonly used technique for evaluating email senders is
accreditation. Most spam sent today is sent by criminals to further accreditation. Most spam sent today is sent by criminals to further
a scheme that is unambiguously illegal. Spam demonstrates an a scheme that is unambiguously illegal. Spam demonstrates an
Internet equivalent of Gresham's law: the bad spam drives out the Internet equivalent of Gresham's law: the bad spam drives out the
merely irritating, the outright criminal drives out the bad. A merely irritating, the outright criminal drives out the bad. A
message is highly unlikely to be spam if the email sender that can message is highly unlikely to be spam if: the email sender can
demonstrate that it is a legitimate business and that it has provided demonstrate that it is a legitimate business, and that it has
a legitimate address where legal process can be served. In addition provided a legitimate address where legal process can be served. In
the accredited email sender may accept a legally binding undertaking addition the accredited email sender may accept a legally binding
not to send spam and possibly post a performance bond that is subject undertaking not to send spam and possibly post a performance bond
to forfeiture in case of default. that is subject to forfeiture in case of default.
As with reputation data a high volume email recipient may be in a As with reputation data, a high volume email recipient may be in a
position to establish bilateral agreements with high volume senders. position to establish bilateral agreements with high volume senders.
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]
7.6. Linkage to X.509 Certificates 10.5. 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 35, line 49 skipping to change at page 35, line 27
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]
7.7. XKMS 10.6. 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 36, line 31 skipping to change at page 36, line 10
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
set out in the XKMS specification. set out in the XKMS specification.
7.8. Verification in the Client 10.7. 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 that 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 not result in a less than satisfactory
user experience than leaving the message unsigned. user experience compared to leaving the message unsigned.
7.9. Per user signature 10.8. Per user signature
Although DKIM is designed to support domain level signatures the DKIM Although DKIM is designed to support domain level signatures, the
core design neither supports nor prohibits use of per user DKIM 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 that this feature is intended to support, is to allow a
to delegate signing authority for bulk marketing communications company to delegate the signing authority for bulk marketing
without the risk of effectively delegating the authority to sign communications without the risk of effectively delegating the
contracts on behalf of the CEO. authority to sign contracts on behalf of the CEO.
For per user signing keys to provide value beyond this limited use For per user signing keys to provide value beyond this limited use
scenario it is likely that additional requirements are necessary such scenario, it is likely that additional requirements will be
as the ability to perform long term validation of the key. Linkage necessary, such as the ability to perform long term validation of the
to some form of PKI is likely to be necessary. key. Linkage 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. At a minimum, a key registration protocol must be defined.
7.10. Encryption 10.9. 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
message content. The message encryption formats of PGP and S/MIME message content. The message encryption formats of PGP and S/MIME
both solve the problem of message encryption perfectly adequately and both solve the problem of message encryption perfectly adequately;
there is no reason to believe that a new effort in this space would there is no reason to believe that a new effort in this space would
improve matters. improve matters.
An architecture of this form would require development of an email An architecture of this form would require development of an email
receiver security policy that allows a recipient to state that receiver security policy that allows a recipient to state that
encrypted email messages are acceptable and to specify key encrypted email messages are acceptable and to specify the 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 and key distribution are conflated, an approach that 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.
7.11. Reuse of Key Record 10.10. Reuse of Key Record
A number of proposals have been made which attempt to reuse the DKIM A number of proposals have been made that 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.
DKIM is designed to meet the security needs of an application where DKIM is designed to meet the security needs of an application where
the cost of individual failures is insignificant or small. A single the cost of individual failures is insignificant or small. A single
spam in an email inbox is not a disaster, indeed it is no longer even spam in an email inbox is not a disaster, indeed it is no longer even
an irritation. For the long time spam sufferer who has seen their an irritation. For the long time spam sufferer who has seen their
inbox filled with hundreds or even thousands of spams an occasional inbox filled with hundreds or even thousands of spams, an occasional
failure may even be cause for satisfaction, a reminder of a failure may even be cause for satisfaction as a reminder of a
successfully vanquished foe. successfully vanquished foe.
One of the chief limitations of using DNS based key records is that One of the chief limitations of using DNS based key records is that
maintenance of DNS records is typically a network operations concern. maintenance of DNS records is typically a network operations concern.
If the entity to which the public key corresponds is a network object If the entity to which the public key corresponds is a network object
(e.g. a mail server) the use of DNS based key management is likely to (e.g. a mail server), the use of DNS based key management is likely
be satisfactory. If the entity is not a network related object (e.g. to be satisfactory. If the entity is not a network related object
an end user) a significant degree of pushback from network (e.g. an end user) a significant degree of pushback from network
administrators should be anticipated. administrators should be anticipated.
The design of DKIM is designed for rapid deployment in response to an The design of DKIM is designed for rapid deployment in response to an
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 were 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.
7.12. Use of Policy Record 10.11. 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.
8. What Needs To Be Moved Here From the Base Doc? 11. Acknowledgements
TBD
12. { 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".
12.1. What Needs To Be Moved Here From the Base Doc?
MUA considerations MUA considerations
key delegation/ 3rd party key delegation/ 3rd party
9. Acknowledgements 13. References
TBD
10. Informative References 13.1. References -- Normative
[I-D.ietf-dkim-base] [I-D.ietf-dkim-base]
Allman, E., "DomainKeys Identified Mail Signatures Allman, E., "DomainKeys Identified Mail (DKIM)
(DKIM)", draft-ietf-dkim-base-02 (work in progress), Signatures", draft-ietf-dkim-base-05 (work in progress),
May 2006. August 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.
[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
RFC 821, August 1982. April 2001.
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet 13.2. Informative References
text messages", STD 11, RFC 822, August 1982.
[RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement
for Internet electronic mail: Part I: Message encipherment for Internet electronic mail: Part I: Message encipherment
and authentication procedures", RFC 989, February 1987. and authentication procedures", RFC 989, February 1987.
[RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME [RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME
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, [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
Authors' Addresses Authors' Addresses
Tony Hansen 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.
Sunnyvale, CA 94086 Sunnyvale, CA 94086
USA USA
Email: dcrocker@bbiw.net Email: dcrocker@bbiw.net
Phillip Hallam-Baker Phillip Hallam-Baker
VeriSign Inc. VeriSign Inc.
USA
Email: pbaker@verisign.com Email: pbaker@verisign.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 42, line 29 skipping to change at page 41, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 223 change blocks. 
1003 lines changed or deleted 988 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/